GraphQL for React Developers

Thanks everyone for joining this workshop. So today's workshop will be graphql for frontend developers. So what we'll be doing today is you will learn what graphql is and how to use it in your project. And also, most of the time we will be spending inside a project. So we're building a frontend project that is using graphql as its api. My name is Roy. I am, well, most of all, my software developer. I've been developing code for for a long, long time, even before I actually started working already. I was developing code at home when I was in high school. Currently, I work for Stepsen, which is a graphql as a service company. So with Stepsen, you can easily set up graphql APIs. I also give workshops and trainings to my own company, Hackteam. And you might know me as the author of several programming books. And besides this, I also run a small YouTube channel on which I do live coding sessions and also post videos about technologies I'm using. You can also find me on Twitter with the handle at GetHackteam. So if you are on Twitter, I'd be happy to connect there so you can get any information about the things I'm working on and maybe ask questions there as well later on after the workshop. And you're trying fiddling with graphql and maybe you'd like to learn more about all the graphql technologies out there. So that's about me. Back to today's topics. What are we going to be handling today? It is graphql. You can only use graphql if you also have a graphql backend. So part of what you ever do with graphql also depends on the backend that you're using. But today, I already created an api for you that you can use. So you don't have to worry about creating the backend at all. Although if we have time and if you have questions about how to build a graphql backend, of course, we can. I can tailor the workshop better to your needs and answer any questions that you might have. But today's focus will be mostly on the frontend part. So the right side of this diagram. So the backend is already there. You don't have to worry about it. And what we will be building is the frontend part. So the interaction with the graphql api, how to get data out of there, how to use graphql clients. Maybe if we have time, also some typescript as well. That might be cool. And for this, I've set up a repo that contains all the materials of today. So if you would go to the repo, you can scan the QR code if you're on a computer anyways. Let me try and copy the link in the chat for you. That's probably easiest. And in this repo, you can find all the materials we have for today. So once we start working on the exercises later on, we will be working through the repo and see how it's set up. And do all the exercise from there as well. And most of all, you need to go inside the introduction directory. So I just sent you the link in the chat, so everyone should have it now. In this repo, you can find all the materials. You can also find solution branches that contain the solutions to the exercises we'll be doing today. And this is for yours to keep. You can bookmark it somewhere and always go back to the materials later on in case you might want to retry some of those or in case you need to leave early because of work or family obligations. The links here on the screen, it's also on the chat. So go to the chat, please, and there you can copy it and open it in your browser. You don't have to do anything in the repo just yet. We'll be going over that together later on. But first, before going into the details, before starting coding, let me give you some basic introduction about graphql. What it is, how to use it, and most of all, how it compares to REST APIs. Because people actually like to say graphql is a replacement for REST. I don't really think it is a replacement for REST. It can actually play together well with REST APIs. Typically, I like to say it's a better version of REST, but you can still use REST that will better fit your project or maybe your team that you're working with because most of all technology is being built by people. And well, if you prefer REST APIs, that's probably fine. In this workshop, I'll be showing you why graphql might be a better alternative to you and how you could use it inside your projects. So to do this, let's have a look at a REST api first. So one common trait of REST APIs is that they have multiple endpoints. Typically, when you interact with a REST api, you don't interact with a single endpoint. You maybe have one, two, three, five, or maybe tens of different endpoints. If you're building something prediction-grade with REST APIs, you might even have like a hundred endpoints or more. So suppose you're working on this great project. And I always like to start off with an example. Suppose you start working on the e-commerce platform of the future. So maybe you get proposed, you get this proposal by a recruiter or maybe your manager comes to you and tells you we're going to be building the e-commerce platform of the future, of the feature. And this future e-commerce platform has the common as this stack. So you'll be having a database, you have a REST api, you have a react application, and that's also using javascript. And maybe there's already some logs being created for this project. As you see on the left, you will have a maybe a mobile page, which you can find this specific product. You can find its title, its thumbnail, its price, the categories, and also the rating. And if you ask me, it might not even be the e-commerce platform of the future, because there are some red flags to me if you're building something that should be future proof. So why is that? So I would say it isn't really a future proof stack that people are using for multiple reasons. Well, of course, the REST api, as today is a graphql workshop, of course, it will be weird not to have something against REST APIs. So I would be saying if you're building something that is future proof, REST api might not be the best choice for several reasons. But most of all, because maybe at some point you try to introduce more clients, maybe next to a mobile app, you also have a web app. You maybe have an admin panel that's using the same set of APIs. And REST just isn't tailored for these needs. And I will go into more detail later on. And then the second potential red flag I see is javascript. Although javascript is a great language, if you are starting to build something, something big, I would say always try and use typescript. Well, for many different reasons. And that's why I also will be introducing some typescript later on at the end of this workshop. So being the brave developer you are, you just are building with this REST api. And let me explain to you why the REST api might not be the best solution for this project. So with this REST api, you probably need different endpoints in order to fill the UI that you're seeing on the screen. So you would have general product information that maybe comes from a slash product slash endpoint page, page or endpoint, actually. So these endpoints will provide you basic details of the product, like a title, like a price, maybe also the thumbnails. Or maybe the price is even coming from a different endpoint. I mean, it's perfectly viable. Then you maybe also want to show like some bread scrums of the category this product is placed in. So you would have to add another endpoint that gets you the information about the category this product is placed in. And then maybe you also have a third endpoint that gives you information about the ratings for this endpoint, for this product. So that's already three endpoints that you might be needing and maybe even need more endpoints, right? Like I said, the price, maybe the price comes from a different endpoint as well. Or maybe your price also is impacted by the location of the person viewing this page. That's probably also need another api endpoint in order to calculate this. So typically with REST APIs, you have to call different REST api endpoints in order to fill one simple UI. And besides having to use multiple endpoints, which is the first trait of REST APIs, REST APIs also will return fixed data structures. So it's a second trait of REST APIs. You don't only have a single, have multiple endpoints, you also have fixed data structures. So what does this mean? If you have a REST api, it's typically directly linked to a database. So if you have a product's endpoint, there probably is a product's table in your database that you're using to get this data. Similar for the categories for a product, you probably have some table in your database that links a product to a category. So this relational table will probably have its own endpoint and then return you all the different tables this product is placed in. And then the ratings for this product will probably also be in a different, different table there. So you would have a table that consists of all the different reviews of this product. So REST APIs, they have these fixed data structures and these multiple endpoints because they're directly linked to an entity in your database. At least that's how it typically works. And that's how REST api started anyways. So if you would look at this example, it is still the three different REST api endpoints. And in here, you can see the fixed data structures. So you can see these REST api endpoints will typically return all the fields that are available in the database table for products, for product categories, and also product ratings. Well, maybe in your UI, you're only using a set of fields. You're not using all the fields. You're only using a small percentage of all the fields that are in the database table. And of course, there are things you can do to optimize this. But in the end, your database should consist of all the data related to all these specific things. So maybe you don't want to solve this in the api lane. So having these multiple endpoints and these multiple, or actually these fixed data structures, will lead for your front end UI that you have to make different requests to REST api endpoints. And then you also get tons of results for these different endpoints. And you need to filter out the fields that you want to use, because maybe also you're only showing the title and the price, while the product's endpoint returns way more data. Same can be said for the categories. Maybe they have descriptions of the categories. Maybe they have ratings for categories, images for categories. They have way more information about categories, probably. And the same can be said for ratings. Whenever you load your first screen, you maybe only want to show the average rating and number of ratings. Well, maybe if you go to the reviews page for this product, you want to show all the reviews one by one. So this is a lot of data and a lot of requests that you need to do. And this is still simplified because probably there are way more endpoints that are in there. So endpoints for stock, maybe a specific endpoint for pricing, endpoints that show maybe sales or discounts, endpoints that will get like maybe different offers. So maybe you're building a marketplace and you have multiple companies offering the same product. So there's tons of things you maybe want to show on this page. So graphql solves this problem that we have with the multiple endpoints and also the fixed data structures, which is a common trait of REST APIs that you can work around, of course. But if you are working around it, you will get something they call a REST-ish api. So it's a REST api, but it's more like a REST-ish api because it's not REST-full. So if you have a REST-full api, you would have these different endpoints and you would have these fixed data structures. Sometimes developers work around this and use parameters to limit the scope of an endpoint. I would say it's something you shouldn't be doing because, well, you never know what will happen. So graphql solves this by not having multiple endpoints, but instead having a single endpoint. And then instead of having fixed data structures, graphql's flexible data structures, meaning that you as a developer have control around the data that's being returned. So how does this work? Before I'll go into details, let me show you a graphql request. So a request to a graphql api is very similar to doing a curl request to a REST api. It's still layered over HTTP. So graphql is transfer layer agnostic, but typically people are implementing graphql over HTTP, meaning that you can still do a curl request. It will always be a POST, and I will explain to you why it's always a POST request. Because with graphql, as we have the single endpoint, you need to let graphql know what data should be returned for this endpoint. And therefore you need to append a body that contains a graphql document. And in this document, you will describe the operation type. And there are multiple operations. The most used one is a query, which is very similar to a GET request for REST APIs. So with queries, you can retrieve data in a read-only way. And then you also have mutations. These are used to mutate data. So let's say you want to mutate data, let's say you want to change the information you have for a product, you would use a mutation. And with one mutation, you can add new data. So it's quite similar to a POST. You can make changes to existing data. So this will be PUT or PATCH, but you can also delete data. So this will be similar to a delete method. So graphql actually simplified all these different ways of mutating data that you might be used to for other HTTP formats. And then there is also a third graphql operation, which is called subscriptions. And these are used for live data or real-time data. So if you're building a JET application or maybe like a stock tracker, you want to be using subscriptions. We won't be using subscriptions today, as they are a bit more advanced and we just don't have the time for it. And in most use cases, you probably aren't working with real-time data anyways. But it's good to know that they exist. And I'll be happy to answer any questions that you might have around subscriptions at the end of this workshop. So what does graphql looks like or actually how do we get to the single endpoint and the flexible data structures? It all starts with a graphql schema. So whenever you're designing a graphql api or interacting with a graphql api, this graphql api will have a schema. And you as a developer that is consuming this api will also have access to the schema. Maybe not a complete schema, but at least a subset of the schema in case anything is hidden by authentication. So on the left, you can see a graphql schema. In the schema, there are types defined and there is also operations defined. So this operation will have three different types, its products, review and offer, and it will have one query. So one operation which you can use to retrieve a single product based on its ID. In the schema, the data structure is described. So you can find all the information about the graphql api, about the schema, about all the possible operations and also all the return types or input types for these operations. You can find the possible queries in here and all the different types are set, like type products, type review, and you also have a relationship between types. And then to get the information of a graphql api based on its schema, you need to send a graphql document. And this document contains a operation like the query you're seeing here. So with this query, you are retrieving information about the product, you are giving it a parameter, which is number three. So this is number three product ID, and then you're defining all the fields that you'd like to see returned. So these are title, thumbnail, also some relational fields like the count of the number of reviews and also the average rating for all the reviews. Besides that, you can see we also are getting information about offers like a reseller and a price. So this will be a schema that will be fitting to maybe a marketplace like Amazon. So in here, you specify the data which you'd like to be returned, and this operation will be sent together with the request to the graphql api. And you also set dynamic parameters and all the data you'd like to be returned. And then the response of the graphql api will always be JSON. So it's important to remember the response is always JSON. And then you can also see the response has the same shape as the operation was sent to it. So you can see we have a query called product. We have a title, thumbnail, we have related data. So it's a predictable return result. That's the same shape and structure as the query that you send to the graphql api. So I hope this sounds very clear. If you have any questions about graphql, about graphql as a concept, we can have some time now to ask these questions. So feel free to unmute yourself or raise your hand or type a question in the chat if you have any graphql concept questions just yet. Just to make sure that everything is clear already before we dive into any examples later. So the implementation of today will be on this because this is already being done for you. Implementation will be on the front end side. For this, I would like you to go back to the GitHub repo. The link is still in the chat. Let me see if I can actually pin this in some way. I don't think I can. That's OK. So please go to this to this page. And here you can find all the exercise we'll be doing today and also some general setup instructions. We'll be going over this repo together as a group. If you would go to the GitHub repo, make sure to go to the introduction page. To the directory called introduction, because that's where we'll be starting today. And here you can find a simple project setup. We have a package JSON to set up the next.js. I think it's next.js. I guess it's just CreateDirect to set up the front end app. We also have a StepSend directory, and this is where the graphql api lives. And as I told you earlier, you don't have to make any changes to this graphql api at all. So this graphql api is just there to help you building the front end app and understanding all the concepts. So to get started, you have to get started by cloning this repo. And you can also fork it, of course, that way you are certain that you will have a copy of your own. So if I will be making any changes to this repo later on, you might lose the information in here. So make sure to fork it as well. That way you are certain that you will have this information for as long as you keep your GitHub profile open. So clone this repo, and then you can run npm install or yarn, depending on what you prefer, and move into directory introduction. So to clone this repo, you can just use... See, where is it? You go back to the previous page where you will have this code thingy. And if you would copy this, you can copy this one here. I guess you can also, well, take the URL from there. So you can copy this one. And then if you would be going to a terminal, I usually use VS Code. You can just type git clone, clone, and then append this address and it will clone the repo for you. I put this command in the chat for people that maybe aren't that familiar with using git clone. So if you are using git clone like this, you will get a local copy of the repo on your machine. And then you would have to cd into the introduction directory. So after cloning, let's assume you've done this. And what I'm going to be doing is I already have it cloned on my device. I would have this. So I would have two directories on my local machine. I would have the introduction and the advanced directory. And I would have to move into the introduction directory by using cd introduction. This will make the working directory of my terminal the introduction directory instead of the project root, which contains both the introduction and the advanced section of today's workshop. And you probably will be able to finish the introduction part, but we won't be able to finish the advanced section as well. But as you have to repo, make sure to clone it and fork it. And then you'll be able to fix this on your own time or maybe at the end of the workshop if we still have time. So make sure you are inside the introduction directory. And in here, you can use npm install like this, or you can use yarn in case you prefer to use yarn. I guess I'd say I'm old fashioned. I will be using npm install to install all the dependencies I need in order to run the frontend project for this workshop. While we're waiting for this to finish, let me know in the chat if things are going too fast. You might need some extra time. It's fine. We can always slow down a bit to make sure everyone is able to settle their project. So let's continue from this part on. Inside the introduction directory, you can also find a README. And what I would advise you to do is have your VS Code or your auto editor open at all times to run the project and then keep the browser tab open to find the introduction README. You go in here, I can find the README and the introduction directory, which includes the setup instructions, which I just walked through through. We can do npm install and then we do yarn. And then after the installation is completed, we can run the development server. Go back to VS Code. I can do npm start here. And this will start my react project. And this will show the application we will be working with today. So you would see this application. It is indeed a bit of Hacker News. So that's what we will continue building on today. For now, it's using a REST api. It is using the Practical Dev REST api. So it's not actual data from. It's not data from Hacker News, but it's data from Practical Dev, so dev.to. And as you can see, these are all the articles that will be posted maybe today and tomorrow. And what we'll be doing in this workshop is we will be using graphql instead of REST api, which we're doing here. We are implementing all cool stuff like viewing the detail page, like using filters. We'll be adding pagination. We also will be adding upvotes. You can upvote articles or posts in here, and you can also view the number of upvotes. And then we might also be able to convert this app to typescript. So that's in short what we'll be doing today. If I go back to the readme, you can see we have this set up. And then we can go to exercise number one. And we also need to install the Steps and CLI first, because now we have the application here, which I just showed you. So this is using REST. What we will be using is graphql instead. And if you look at here, we have a directory called Stepsend. This has a mock graphql api that is using the Practical Dev api. And it's also using a Firebase database in which we store the data. And it also has a mock authentication server. So this is a mock graphql api that you, well, it's not a mock api, but it's being set up for you. You don't have to make any changes to it. The only thing you need to do is run it. So as soon as you have this application running, you need to open a second terminal. You can either split it or open a new terminal window. Let me just quickly do this. So I will create a new terminal window. And in this new terminal window, I need to make sure that I am in the introduction directory. And in there, I just run npm install globally, Stepsend. So this will install Stepsend, which is a graphql service that allows you to create graphql APIs declaratively. And I already set up a graphql schema with Stepsend in here. So you don't need to make any changes to that. The only thing we need is installing the CLI so we're able to run the graphql api that we have in there. Because we'll be using this graphql api to use graphql in the front end app that is also inside this repo. So make sure to install it. The command to do so is also in the readme, of course. So to get a free graphql api, you can install this by running npm install globally. You get to install the CLI, which I've done now. And then after installing the CLI, you can optionally sign up for a free account. So if you would sign up for an account, you will get a secure api that also remains up for a longer time. You can also choose to not sign up, which is perfectly fine, of course. And then you can run with a public account. And it is one caveat, if you use a public account, your data will be deleted in like 14 or 30 days. So if you want to keep this application up, you probably have to sign up for an account. It's also a bit safer because that way you're sure no one is able to retrieve your public graphql api. But in case you don't want to do that, that's also perfectly fine. So let me see if I'm logged in. Yes, I am logged in. If you're not logged in, it's also fine. You will get a question to ask if you want to continue with a public account or you want to sign up for a free account. To run the graphql api, the only thing you need to do is run Steps and Starts. So this will take the graphql schema that is inside the Steps and Directory and deploy it on a graphql api for you. So if you are signed up, you will get a local host thingy with a graphical to help you use it. Or if you have signed up, you also have this production ready endpoint. If you use an anonymous account, your endpoint will start with a HTTPS and then public with some random string. And you can open that one in the browser as well. So if I would be opening this in the browser, I can see a graphical that looks something like this. So this is the old version of graphql. There also is a new version. See if I have it somewhere. So this is what you would be seeing if you are using a public account. You would be seeing the newest graphical. And for signed up accounts, we're in the process of making the latest graphical available for signed up accounts as well. So just to check in, is everyone able to see the graphql api in their browser? So either on a local host endpoint or on a public endpoint. And this is everything we need to set up for the graphql api. From this point onwards, we will be consuming this api only. So there's no more setup after making sure you have this thing running in the browser. So let's do a quick round of the check marks again to see if everyone is able to have a graphql api running. So we have seven check marks now. Let's go to ten again. So we're sure we have most people with us still. And it's important to have the graphql api running because you will be needing this to complete all the exercises. Because, of course, we need a graphql api in order to do the graphql workshop. So now you just need one more person to verify that they have the graphql api set up. And I'm going to be assuming a number of people to be following on. Maybe decrease a bit as people might have to tune out for work or family stuff. So I guess that's ten now. Great. So we can continue. So if you go back to your README, you have cloned the repo, you have installed all the dependencies. You have installed the StepSense CLI, which we need to run the graphql api. And now you've also run the graphql api itself, meaning that on the setup side, we have everything done. So we're now completely ready to start building and to start creating, start using graphql from that app. So for exercise number one, you need to have the graphql api set up, which we've just done. And here, the first exercise is run your first query. So what does the query look like? And we want to retrieve the fields ID, title and description. So to run your query, you can either run your query against the graphql api using curl or using postman. But for this, we'll be using GraphiQL. So GraphiQL is the explorer that you're seeing here whenever you open the endpoint that you see in your terminal, whenever you do run steps and start. So it's either the localhost one or it is the production ready endpoint, which either starts with your username or starts with public and then some random string. But for exploration, I would say open the localhost because it's made for exploration and you will get a GraphiQL. So it's either the old version of GraphiQL or the newer version of GraphiQL, which is this one. In both versions of GraphiQL, you can find the schema by clicking on docs. You click on docs, you can find all the available operations, the queries and mutations. And also in here, it's on the left side, you can open docs and you can find the queries and mutations. So once you press query, you can see a list of all the available queries. And the same if you click mutation, you can find a list of all the available mutations. So these are the queries and these are the mutations. But for this first exercise, I want you to retrieve the articles and then use and then take the fields ID, title and what else do we have here, ID, title and description of the articles. And this GraphiQL api is returning the same data as you're seeing here because what I've done using StepsN, I graphicalized the Practical Dev REST api. And this is quite cool because that way I can use GraphiQL for a REST api and for a product that doesn't have a REST api. And I can also combine it with data coming from different sources, such as Firebase, as we'll be seeing later on. And we implement the uploads. So to get the articles using GraphiQL, you can find out which queries are available by opening the docs, by clicking on query and then find the list of queries and then the same in the new version of GraphiQL. You can follow the same steps, go to query and then, I don't know, take any of these queries. Fact size number one, you can either try it yourself or we can just do it together as it's just the starter exercise. I propose just to do it together as a group. So what I will be doing here, whenever I want to do a operation, I just start typing the operation type before. So I will be typing query to let GraphiQL know that I want to send a operation that is a query. And then I open this query using curly brackets. And then here I need to define the operation name, so it's not the query, it's not the operation type, which is query, but the name of the operation. And in my docs tab here, I can see query and then I can find all the possible operations that are queries. So if I want to get a list of articles, I probably need to use the articles query. So see here, which I can just type like this. You can see there's also this nice auto completion coming from GraphiQL, which is really helpful. So I use the articles like this. I can also provide arguments. So these are page per page and text, but it's something I will be doing just now. So instead of providing arguments, I will be using a second curly bracket to list the fields I want to use. And to find all the available fields, you would click on the article because article is the response type. And if I want the ID, I see you can just type ID. I already see that ID is of type integer. Doesn't really matter right now, but it's useful to know later on. You can type ID. Again, you have the auto completion, which is quite nice. If we scroll down, we can also find the title probably. So the title is also type. It's of type string. Title here. And then the final field I want is description. And I can see description is also in here. It's also a string. Just start typing description. So this is my query. I can use it to retrieve the ID, title, and description of all the articles of Practical Dev, using this REST api that I'm running now through the repo we set up in the beginning. Once I press play here, I will get a list of all the articles. And as you can see, these are the same articles that I'm seeing here probably. We'll refresh. There might be some new ones. So you can see super useful css resources, meme Tuesday. You can see the same results there. I can also copy this and use it in the latest version of GraphiQL, which should give me the same results. This is basically everything you needed to do for exercise number one. So a quick check in. Is everyone OK right now? Did everyone understand what's going on? If not, please let me know. Use the chat, raise your hand, or unmute yourself to ask any question. I see some thumbs up. See some green check marks. So we're going to be assuming exercise number one was clear to everyone. So for exercise number two, and I want to take, let's say, five minutes for this, I want you to add another field or maybe more fields to this query. So if you go back to GraphiQL, I want you to get the username of the person that wrote the article as well. So for this, you need to make some changes to the query. And let's take five minutes for this. So for exercise number two. So let's take five minutes and then we'll do it all together so you can see the solution for it. And it might be that these first exercises are a bit slow to you, if you already are familiar with graphql, to make sure that everyone understands what's going on from different experience levels and different experiences with graphql. It might be starting off a bit slow. If you do generally feel everything is getting a bit slow, feel free to work ahead as all the exercises are in the repo and they are available to you. So for exercise number two, can you alter the query to also get the username of the user that wrote every article? And for this, I'll give a small hint. So think back to how you inspect a graphql api schema. And for this, let's go back to the graphql, in where you can see, once you click on Docs, you can find all the different queries. And then if we would go to our articles query and we go to the response type, which is article, it might make sense to look in here for user. Is there a way to get the user? You can see there is a field called user. But if you click on it, you see it has a response result type of its own. That is not a string. So it's a what we call a custom scholar or relationship. So it is a field on its own, and it also has different information. What we need to do is start typing user. And then again, we need to open the we need to use security brackets to get the sub selection of fields for user. And then here we can start typing username, and this should get us the username for this user. Then we can see whoever wrote these articles in Practical Dev. Which you also could have done, maybe if you're a bit smarter or a bit more hacky than I am, just start typing. Start typing user, try it out. And then you can see graphql did it for us. Yeah, I see Jago was smarter than me and actually followed this pattern. So that's also a nice way to do. And it's also a cool part about the graphical, because if we have this, we have to sell the completion. So it will help you do these kind of smart things. This is how you would use relational fields. And in this in the case of Practical Dev, this is all coming from one REST api. Maybe if you're working with a graphql api based on top of a database, these relational fields might be coming from different database tables. So that is something graphql can offer you as well. So if you have a articles table in your database, maybe also have a user table. So this data could be coming from different data entities. But for you as an end user, as a developer interacting with the graphql api, it doesn't really matter where the data is coming from, because you can easily use it like this. Circling back to the README and GitHub. We're going to the first a bit more complex use case. So for exercise number three, you can read that graphql APIs can be queried from a client application. So in this exercise, we'll be using the graphql api that we just used. So we used it inside the Exploration Tool Graphical. Now we will use it inside our application. So we have the graphql here. So we're going to be using this query inside our application instead. So what you would need to do, you would need to go back to your application is running. So for me, it's VS Code. It might be a different editor in case you're using maybe WebStorm or some IntelliJ things, or maybe maybe Adam could be anything. And maybe you're one of those FIM developers, which I always envy a bit, because I wouldn't be able to do it myself, but I always envy those people that are able to do anything in FIM or VMAX or whatever the cool terminal tools are called nowadays. But for me, the editor of my choice is VS Code. And in here, I would need to go to the source directory. And in here, I can find several components, and I would need to open the homepage components. In the homepage components, you can find a fetch function that is getting the information from the Practical Dev REST api. So the information you are seeing here, sorry, here, this information is all coming from this fetch request. But as you see here, it's coming from the REST api. What we want to do instead is we want this information to come from a graphql api. So what I need to be doing is I need to take my graphql api endpoint here and then we need to swap this out. A bit like this. Or if you're using a public endpoint, it should be something like this, public and add some random string. Usually it starts with like a number. So any of these two endpoints, either one that has your account name or the one that starts with public. What's important to know here, never use the localhost endpoint. Localhost endpoint. As it won't work. So you want to use the graphql endpoint instead. You probably also need to open some headers. And maybe also remember that you need to set the method to post. And then you need to set some headers, which I'll actually give you away just to make sure that we don't get confused about this. You always need to set the content type to JSON because graphql APIs only work with JSON. And then if you have signed up for a StepSend account, you also will need to add your authentication key here. So we need to type authorization. And then you would need to type api key. Your StepSend api key. And then if you have the issue, we need to go to here to get your api key. But it's optional. You don't have to do this, of course, if you didn't sign up. So this is the first part. And then comes the most tricky part is how to get the graphql query to this endpoint. And for this, I will leave it up to you to finish. Here are some pointers. What I want you to do now is to take 15 minutes. To hook up your graphql api in this fetch request, pass the api key to it optionally, pass the query to it. And also make sure that everything renders nicely. So maybe you need to destructure some data here. So what I want you to do is replace the REST api with the graphql api. So this is exercise number three. There are some hints in here. Make sure to add the authorization header in case you signed up. And also have a look at the network tab in graphql to get any pointers to how the HTTP request is actually being sent. Back a bit earlier, I see some interesting questions. Why everything is a post method is because we need to send a query. So if you have a GET, you cannot attach a body. So this is only if you set a post. So that's the reason why we need to use a post request, because we have a body that contains our query. And this query is something we can get from our graphql. Just take this query, go in here, and then you actually need to name it query. And this will be a string that contains this, but probably as I have a multi-line, I want to use this to make it a bit nicer looking. If I would format this, I would need my api key in case I have authentication here. Which I actually have. So I have the graphql api endpoint. I make sure to never use the localhost as it won't work. I've set my methods to post. I've set my headers, which are the authentication key in case you need one. And I also set the content type, the application JSON. And then in the body, I appended the query I want to use. I would save this and I would go back to my app. I would probably refresh this because the data format from the graphql api is a little bit different. It's back here. So request succeeds. I have a graphql request, returns my data. I can see the data is here. But as you can also see is the request from the api from the REST api was different. And our data is nested inside data.articles. A tiny bit bigger for people with bad eyes, including me. So what I would be doing here is my results. I should check, actually, if results has data and has articles, and then I should put data.articles here. If I would save this, my application works again because now I'm destructuring the data from where it should be destructured. So it is setting the api endpoint. It either has your username, for which you also need to set an api key, or it is a public one for which you don't have to set an api key. You always have to set the content type, location, JSON. You need to append a body, hence the post request, and the body includes the query. And the query is just the one that we use in graphql. And then make sure to destructure the articles from the results because they're nested inside result.data.articles. And also, if you go to the GitHub repo and you click show solution, you will find a solution branch. So this is a branch. Inside the repo and which you can find the solution. So in here, you can just go to the fetch function to find all the answers I just showed you. Let me open the chat again, see where it is. If they solve people's questions, I see a problem occurred while processing your imports. I'm not really sure if it's related because I wouldn't really know why you are doing Steps and Imports graphql because you don't have to do this at this point. So maybe just send me a personal message, Paolo, with whatever you're trying to do, because I don't think it's necessarily an exercise from this workshop. And then I see Guillermin is getting a 401, an authorized message. Can you confirm you still have the error? Sorry? It's fixed now. I was missing the api key part of the string. I was sending only the key, but not the api key for it. Thank you. Yeah, it happened to me a lot as well, so no problem there. So Paolo, if you want your question answered, please send me a personal message so we can continue with the workshop. Any other questions about this exercise number three? For this, you can use a chat again or mute yourself like Guillermo did and ask your question out loud. OK, I will take it that's a no then. In that, I will continue with the next exercise. So exercise number four. This one is quite similar to the exercise number three, except this time we want to get a single article from Practical Dev. So if you look here, so this data now is coming from graphql. But if I click on any of these details, it will still get the data from the REST api. And for this, of course, I also want to use graphql instead of using the REST api. So the steps I would do when I would try to fix this, I would first go to Graphical and figure out how to get a single article. For this, you can probably go back to the list of queries and use the query to get a single article. The logic to get the ID from the URL is already inside the application. So you don't need to have the specific knowledge to do this. It's already there. What I want to do for this exercise number four is to get a single article using graphql. And for this, you need to also make some changes in the code, of course, probably in this component where you need to change this fetch function to get a single article. And for this, again, we can take 15 minutes. If you are going faster, it's fine. You can already go forward to the next exercise. But in 15 minutes, we will do the solution for exercise number four. If you get a 401, make sure to look at this right here where you need to use your endpoint and then you also need to use the headers with the api key. Make sure to use these headers, which I sent in the chat to get with your request. And also make sure to never use the localhost endpoint as it won't work inside your code. If you want to explore the api itself, always use the localhost one. So it might be confusing. It's something we are changing on StepSend side. So for today, please bear with me while doing this. OK, so what we were doing was question number five, I guess. Yeah, question number five. So what I like to do is I would say just copy paste the whole block you had here. This part, so const fetch, blah, blah, blah, just copy paste it and move it over to the article side. Because what we want to do is for exercise number four, we want to query a specific article. I would place this with this thingy. I still have the same graphql api because the graphql api endpoint never changes. As we know, as opposed to REST, we always have one single endpoint. We have a post method. We optionally have an api key. The thing that does change is our query because we're getting a single article instead of a list of articles. So to get a single article, you would take the ID of one of the articles and then change it like this. Let's say ID and put it in here. You can see it's expecting a string. So if you would try an integer, you would get an error because it's expecting a string. So this is one of the cool things that the graphql type system is giving to us. So this is the query to get a single article. So what I would do, we just copy paste it. I will go back to my code and I will put it in here. And as I'm using template literals here, I could just take this value of ID and put it in there. Just like this. And then close it off. Save this. And then remember, like what we've done previously, we need to add a check here to make sure that we get the destructured influx. So we'll get a single article. So we do .data.article. And then in here, we also get .data inside the parenthesis, .data.article. Let's save this and I will go back to my react app. Not sure where I left off. I mean, you stopped hearing me. At least you saw the screen. Any questions about this exercise? Is there a way to get all the fields without writing it? Like to get the description, the ID, every field that is inside of the article? Yeah. Well, unfortunately, there isn't. I think there is a proposal for the graphql spec, the latest spec, to have like a select all. But currently it isn't because the main feature of graphql is to make sure you select your fields dynamically. So that's probably the reason I left it out. But for now, there isn't a way. What you could do is using fragments, which will make it easier for you to reuse a large set of fields. We will be handling fragments later on. So we will be continuing on to exercise number four. Number five. So the query we previously used as a query parameter, which can be handled from a named query. And for this, what I will be doing actually instead is I will just be doing this as a group, because it's probably easier. So for a named query, you can actually use the graphql first. So if you want to do a named query, the only thing you need to do is putting a name here. So you have the query. You have the operation type, which is query. You would use it as a keyword. And then you can just type your own query name. So you can, for example, call this get article by ID. This will be a nice query name. And actually, nothing changes because it's only for you, for the eye. But if you're using a graphql client, as we're seeing here, you're often used for caching purposes. So this will become important later on. But they're also useful for something else. Because if you look here, we have this parameter hard coded, which is maybe not the nicest, because maybe you have multiple parameters, maybe you have JSON strings, maybe you have arrays at some point. For this, we have the query variables tab right down here. And in here, you can actually use JSON to type down your query variables. I could take this part, bring it in here, and use it as JSON like this. The way to pass it to the query, to be able for the query to use it, we need to use a named query. Because when we use the name query, we can also define variables here. What we can do is say there's a variable called ID, which exists right down there. And it is of type string. And then this value is the input for this parameter. So it might seem like magic, but it already has changed here. What we have done, though, is to make it easier to structure our queries. So now we have a named query that is using variables as a parameter. And then down here, I'm not sure why we have this issue. It's probably some rendering issue in GraphiCo, but we're using a named query instead of a hard coded. So if we would take this query and we would bring it to our editor, we can actually replace this query here as a query. What we can also do is we can add a new field in a body that's called variables, which is then a string of five version of this. And it will pass the ID in the same way as we see here. So basically, it will do this. So this value will be transferred there, so you can actually use it inside your graphql query. And then if we would go to our react app, things should still be working. So we can add an error. Let me see why. Let's see what's going on there. We're passing in payload, we're passing in ID. Sorry? Yeah, it's query and then probably we need to omit the query within the payload. You see the query? It's query and then probably we need to omit the query within the payload. You see the beginning of the string? Yeah, I'm not sure, but we can try. No? So let me quickly see how they do it over here because probably I forgot something as I usually do. If I would press here, I see the same request. I can see I need to append an operation name. It's probably the thing I was missing. What does this look like? Let's see. This query. I maybe need to append an operation name here. I maybe need to append an operation name here. Let's see if that will fix my issue. Turning this operation name. This as a comma there and then save this again. Go back here, see if this resolves my issue. It looks like it didn't. So what else could I be forgetting? It's probably looks like the variables are being. Maybe this doesn't need a stringify at all. Could be. I guess that's the reason because I'm already using content application type JSON. I probably don't really have to use a stringify. Yeah, so it looks like it's already better. And then I should not forget to put the body html in there, which we've done in the previous. So now I'm using a named query, which you can see here. It's using a named query and we're passing the variables like this, which a bit nicer. But later on, when we start using a graphql client, it becomes more important. It becomes more important. See, Jago giving a nice tip. If you hover query in the network tab, you see all it takes without needing to scroll around. It's smart. Let me see. So we run this. You can do this. Well, never mind. So this was the exercise number five. Any questions about using named queries? Just a quick question. Are these queries stored anywhere for documentation? Just how can you check the name of the queries that you created? Well, you don't really create and use them at runtime. But later on, if we start using the graphql clients, they will be stored in your frontend app and then you will be able to use them later on. Oh, I see. OK, thanks. Cool. And then for exercise number six, we're going to be fixing an issue we had earlier on. Or actually a feature we had earlier on. So if you remember that, if we would go to the home page, we had this nice filter. But currently, the filter isn't doing anything. We still get the same results. So what I want you to do for exercise number six is to use a named query for getting all the articles. And then I want you to use the, if we go to docs, I want you to use the parameter tag here, parameter tag on articles to make the filters work again. You would go to the code, to the home. You can see the value for filters here. So you need to find a way to pass the filter to the graphql query and then use it in the query to get the articles for this filter instead of all the articles that are available at the latest time. So per request, we can take 10 minutes for it to make the fetch articles function in the home component, also named query, pass the tag to it so you can have some filters on the home page. So whenever you press the filters, the tag variable will be updated. So let's go back to the exercises. We were looking at exercise, exercise number six. So the fetch articles function in source components home can be changed to use a named query. So if we go back to the graphql, we can change this one to maybe get articles and then use the articles here. And I guess it takes a tag parameter. So you can say tag is, let me just change this to tag. Tag. If we run this, probably not much will happen. There probably isn't a tag called 123456. There probably is a tag called graphql. So as you can see, this gives some nice results. Probably also use typescript here to give us different results. Actually, a article from mine that it's kind of nice to see. So what I will be doing, I tested this now in graphql. So this is usually the way you go. You try it out in graphql, then you bring it to your code. I can just copy paste this and also make sure to change the name because if you have multiple queries with the same name, it seems to be giving issues. Going to my home components. I'm going to update this thing here to use my new query. Of course, I also need to set the variables. And for the tag, I will take the filter prop, which I have in my component somewhere. So I have a set filter probably here somewhere. So this gets a filter prop. And this time they'll be passed to my components. If I save this, I can go back to my application here. And I can actually see the tags are working. So I have some react articles, I have some graphql articles. I have some typescript articles, including one for myself, which in case you'd like to know, it's how to set up zero config typescript applications with next.js. So you can see how it works. We can use the different filters. You can still click on an article to get some more details and all the requests are coming through graphql. Then I see a question from Vladislav. For some reason, article type in graphql doesn't specify tag property. It has tags and tag list instead. Yeah, it could be because the parameter doesn't necessarily have to be a field on its own. I can call this basically anything I want. I can also call this input one or variable one, because this is defined in my graphql schema. And the text I use here doesn't necessarily have to be a field there. The graphql schema itself will be having slightly different. Actually go in there and show you. So I have my query called articles. And the REST api will take a parameter called tag, a bit like this. So the only thing the graphql api does is bring this over to the REST api. But StepSend automatically puts all the parameters as query parameters in there for you. So you don't have to do this manually. But this is what would happen under the hood. This one. So this was exercise number seven or six, six. Exercise number seven is something we're going to skip actually to make sure we have sufficient time to work on all the cool stuff. Because I can also imagine four hours might be too much for some people in here for multiple reasons. So we're going to be skipping exercise number seven. But feel free to work on this exercise at home or anytime you actually have the time for it. What we will be doing now is we're going to go forward to exercise number eight. And for this, I'm not sure if 10 minutes will be sufficient. So make sure to take 15 for it. For this, we're going to be using apollo Client as our graphql client. And there are multiple graphql clients. apollo Client is one of them. It is at the moment the most used one. They also have Relay, which is also a great one. But it's a bit harder to understand if you're new to graphql. So that's why we will be using apollo Client. What you need to do for this exercise is install apollo Client in graphql. So this is the graphql front-end library that will help you. That's actually a must-have dependency for apollo Client. So you can install it with npm or yarn. You will need to add some boilerplate code in the index.js file to create an apollo Client. And you will create a client and a provider. So it's pretty similar to as you have been using Redux maybe in the past. You need to create a provider that will wrap your component tree with the information of the client. And this is to set up the client. And then once you have the client set up from everywhere in your component tree, you will be able to use a use query hook. And for this, we actually will be going to the apollo docs. We go here. And more specifically, we go here. Put this link in the chat. So what I'd like you to do for exercise number seven, number eight, which we skipped seven, is install apollo Client in the graphql library. Add the apollo provider to the index.js file. Make sure to pass the header here as well with the authentication key. In case you have any, don't forget the api key in here. I will change it in a readme as well. And then use a use query hook for the home and article components. We're going to be replacing the fetch request with apollo use query hooks. And the docs are right here. For this, it's a bit more advanced. It's a bit more coding. That's why we really need the 15 minutes. So make sure to take the 15 minutes. If you are done a bit earlier, feel free to go to exercise number nine already. Because I really want to make sure we have enough time for the people that need a bit more time. Exercise number eight, 15 minutes. So feel free to continue finishing it while I'm running npm install. So I'm going to be stopping my react app. I can run npm install apollo Client in graphql. OK, so this is installed. And then I can do npm start to start my npm server again. So what I will be doing for starters, I will go back here. And I'll actually copy paste this code and bring it over to my source indexes file because I need to be creating a provider. Very similar to how we do this with Redux. Or there are actually more tools that use providers. If you use the react context api, you might also know how this is set up. Adding the imports here. I have a client. This would be my endpoints. My api key is something I can copy here. And paste it here. So I have my endpoints. I have my headers. You can see I don't need to set the content type header this time because apollo is a graphql client. So it already understands that graphql always needs JSON. So I don't need to set that one this time. So I have my client. And then what I need to do is I need to wrap my app components. So this doesn't do anything yet. The only thing I've done so far is create an apollo client. And then create a provider to which I pass the client. Any questions about this part? No? Okay. So then I will continue by going to the home component, maybe. And start putting in a apollo use query here. So what I can do, I can say const data is the data that I want to pass to the home component. So I will continue by going to the home component, maybe. And start putting in a apollo use query here. So what I can do, I can say const data is... I'm not sure, is it in a way? Use query. And then this is my query. Let me just start by doing this because I think it should work. Query. And then it will take some variables, which is this thing. And then I guess I can delete all of this. See, use query. I think there, closing. This. Sorry, it's getting a bit messy, but we'll fix it in a bit. Zoom out a bit a little bit more. Maybe just close this. So I'll do imports. Use query. Here. So it should be finding... So actually I also need to delete this part so I can actually move all this up top. And I can do this as well. So actually I can delete this whole use effect function. Make it a bit clearer what I'm doing here. What I will be doing is I will take this whole use effect function and I'll basically just delete it. Because we no longer need it. And we also no longer need to set the state because apollo does this for us as well. So we're going to be removing the article state. We're also going to be removing this use effect to reset articles when the filter changes. Instead, you're going to be using this use query hook that we need to import. So import. Use query. We have data here. We have a query here. We have a filter which is in the component. And then we have the data. And then as Vladislav said, it's a bit annoying that we need to do it like this. Because actually we need to destructure this because articles is inside. But it's just the way graphql works. And then this would already work. Although when our component first renders, we will get an issue here because articles isn't there yet. So what you can also get from the use query hook is a loading parameter. Loading return. We can say if loading returns something like this. If I save this, let me go to my here, see what it looks like. If it's done correctly all at once or that we need to make some more changes. We probably have to. Argument of query. So I also need to use the GQL function which I can get from here. GQL. And I could pause this like here. GQL. Or it doesn't go back. I should be getting data here now. But I'm known, cannot read properties of undefined. Let me just to be sure, do it like this. So now you can also quickly see the loading thingy there. Something you could make nicer, of course. But not the main purpose of today. Besides loading, you can also get error from here. Meaning that if the graphql api returns an error, you can use it somewhere else. So what I've done here is a bit messy. And it's something you can actually clean up. So instead of putting it like this, I can also turn this into a constant. I can create a constant here. Guts. Articles is this GQL. And then I could just take this, delete, comma, and put this thingy in here. Format. Then we should be right again. So this works. So this is how I would use a use query function. You can get an object in return with loading error data. You pass a query. It should be a valid graphql query, hence the GQL. Which is basically a function that helps you to transform the string into a graphql node. And then we pass the variables here, which is the second param. And I guess there is more params. Let's see. Variables. You can also pass any other options. Let me see if the text still works, actually. react. No. So what I probably need to do is I need to put like this and call this variables. See, it is better. So now it works. So that's how you do it for the getArticles. And then for the getting a single article, it's pretty much the same. We can delete this. We can delete all this. We can copy paste the code we had before. And then we're passing a param, which is ID. And this was params. ID. We're going to be taking this graphql query. And we're going to create a constant for it again. So new const. article by ID like this. Well, we already have this nice template. Literals. The one. This can also delete new states. It's not a setting state. I need to replace this with this. And then, of course, I also need to import these things. And then in here, I need to send data, not data. article. Also do is const. This is easier. And now if I would be clicking on an article, I should be getting the article again. So pretty similar. We're again using loading the data. We don't use the error just yet. If stuff is loading, just return loading. If stuff has finished loading. So this is all synchronous. We'll go from top to bottom. So we can destructure article from this thingy here and then get all these variables, see if they exist. And we got to delete quite some code. So actually could delete all the set state functions because this kind of state is being set by apollo. We don't need to set it by hand anymore, which is quite nice. You get quite some code for free, which is something I usually like. And as Vladislav said, it's a bit annoying that you have to destructure it like this. But I mean, we had to do the same thing previously already when we destructured the results from the REST api call. And we need to get the result from data JSON. And then we already had to get this data down the stream. So yeah, it's something you could use too. In the end, it's only one time destructuring while with REST you're maybe doing infinite amounts of destructuring. But yeah, that's using apollo clients. Any thoughts about using apollo clients? Do we like it? Do we dislike it? If you didn't have the time to form an opinion on it, that's also fine. I mean, it's maybe your first time interacting with it. And yeah, the nice thing is it will really abstract away those things that you would otherwise have to do imperatively by hand. So it's kind of nice. It does all these things for you. You probably also imagine that if your application grows, if your frontend project might be a bit confusing at some point or it's hard to tie all data together, use query might not be your best option. What you can also do instead is, and this probably will give you a bit more handles that you can poke yourself, is you can still use and use effects like this. And what you can do in here is you can still get a data variable. So what you can also do is constant data is client.query. For this you would need to import the clients from here. You need to export it. And in here you could import the client from there. And then you could query the client directly in the same manner. And if you do this, you don't have any state updates. So you need to make sure you do the updated dates yourself. You would need to put, like I said, something. You would need to put data in there. You would need to check for updates. So it may be the rams.id changes. So there's tons of things you use queries doing for you that you could also do manually by hand. But that's up to you as a developer, of course. I usually like to tell people how to use those query. You already know how to do the fetch request. So then you have different ways of approaching this. So this was exercise number eight. And then we have three more exercises to go. So we might be able to finish in time, which is nice. For exercise number nine, we're going to be looking at mutations. So we already learned that you can use graphql to query data. So what we will be learning now is how to use graphql to mutate data, meaning that you can update data instead of just reading it. And for this, we will be using mutations. Exercise number nine is a bit. It requires quite some react coding skills. So I would propose to just don't do this and instead go directly to exercise number 10. But first, we want to add the upvotes for every article to the screen. So our query here also has a value for upvotes that we also want to use here. So maybe we can do it in a similar fashion as we have here. What is the label style? We can do. So please go along. So inside home.js, you have your query for getting articles. And here you need to add a new field called upvotes. And then going down, whenever you destructure the articles, you need to destructure upvotes there as well. And then you can just put it in a span to display it. And saving this, I will be seeing upvotes here. Yes, these are my upvotes. You can see there are zero everywhere because we haven't uploaded any of these articles yet. So if we would go to our exercise number 10, we can add a button to upvote an article. For example, by using the mutation called upvote articles. We would go to the graphical. We can use this to get articles. All articles that we need to tag anymore. And we want to get the articles, we want to get the ID and the number of upvotes. So everything has an upvote called effort for the value zero. We want to use mutation to upvote an article based on their post ID. So next to the query, we can also add a mutation. We can name this upvote article. You can type mutation here. You can type upvote article. We need to set the post ID. And I'll just do it manually now as it doesn't really matter. So I'll type upvote article here like this. So this is my mutation to upvote an article. And then graphical will ask us which thing we want to use. Article. And as you can see, it gives me a return. So now we're going to get articles again. You can see the upvotes are there. And either it is duplicating or someone else is trying it as well. The same here. I can upvote a different article and then get the list of articles again. And I see the upvote of one there. So this is all being stored in a Firebase database. I told you before I used StepSend to get the practical dev api, but I also used it to connect the Firebase database. So what we'll be doing is we're going to use the Firebase database and what we'll be doing is we're storing a combination of post IDs and the number of upvotes in this Firebase database. For you it doesn't really matter as I already created this api for you. Let me retrieve this again. So yeah, please go to your graphical and try this out. Try out this upvote article. See if it works for you. And then you also get a feeling with mutations and see that they are very much the same as using queries. You can use the name setup similar as we saw before. So we can make this post ID should be a string. You can set a query variable here saying post ID is a string. It is specifically this string. And then here we would say this is post ID. And it would still work as expected. So yeah, any upvote anyone in this group is doing will also show up here. So if you see strange numbers, maybe something increases but more than you thought it would, it's probably someone else doing the same upvote because it's all being stored in the same database. So what are we going to be doing for the exercise we're at? Please go away with this zoom handlebar. Exercise number 10. We want to be using a use mutation hook from apollo to do this. And the use mutation hook is quite similar to the hook we saw before, which was the use query hook. Let me put this link in the chat as well. It is quite similar, so we have a use mutation hook here and we can use it whenever we click a button. So if we will be going back to our code, we can go to the home component, for example. We should be adding a use mutation hook here. So add use mutation here. As it also returns data, you might need to rename the returns and use mutation. Something else, so probably you would need to do like const, loading error data, use mutation, maybe something like this. Delete this, it's confusing. You probably need to be renaming these loading mutation, error mutation data. You probably need to be renaming those similar like this because we're going to be using two hooks in here. And then in here you would like to set a button to probably upload. So maybe add the upload button there. So there's a couple of things you need to do. You need to add a mutation. You need to get a response. You also need to add an upload button. And this will upload the articles whenever you click it by using whatever the annotation returns. Let me see if the uploads are working here just to be sure that we're not going crazy. Upload article shows there, get articles shows there. Okay, so api-wise it should work. Let me go to the code, see why it might not work. So for starters, we need to get a use mutation function here. First import it from apollo clients. Use mutation. And then the return of the use mutation is slightly different from what we saw before. So it actually returns an array with an update function. So this is update function. You can call it whatever you want because it's an array. And then the second part is the objects we saw before. Then suppose we write the use mutation. We'll also take a query and we'll actually only take this variable here. And of course we need to create our mutation here as well. I'm going to be going back to graphical. I'm going to be taking this one here. And what I can do is say const the photo article. This thingy. And then close with the template literal. That's the one. I use this thingy in there. It looks something like this. Hearing my app shouldn't break right now. Yeah. And then if I have this update function here. So let me create this button. Let's take like a title. And say click. Do some stuff on click. So we're going to be using this update function. And we're going to be passing the variables to it. My button is complaining because it's not being closed. Save this. I see a tiny little button. Close it like this. Yeah. So now I'm seeing an upload button. So let me see if we can find Vladislav's issue. I have the network tab. So I'm going to be clicking. Let me just scroll down. Music Monday. We have a post ID. I think I see the issue there. Refreshing this. We don't see it updated. I guess it is because, and it's weird because we should see an error for this. This is supposed to be a string. But somehow this still works. So that is super, super weird. Maybe we should do it like this. That is weird. Sorry for that. So what we need to do is we need to make sure this is actually a string. So how do we do this? This should be working better. That's possible as a string. And if I refresh the page, it is showing up a one. I'm happy to have solved that. I will look into the issue because it should, graphql should actually be finding this error and make us aware of it. Maybe it's because of how. Maybe this. Well, something to figure out later. So any questions about this? This exercise? Sorry, I'm bombarding with questions. But another one I would have. You can hear me, right? Yes, I can hear you. I was curious, for example, what would I do if I want to see uploads without refreshing the page? Yes, that's a good question. And I think it's the next exercise. Yes, the next exercise. So what we could do, actually, we can do this exercise 11 together. And then we would have some time for Q&A and round up. That's OK with everyone? It's cool. OK, good. So let's do that. So exercise number 11 is every time you upload an article, accounts should be updated. For this, we're going to be using the Refresh Queries option. This is an option. Using all the secret actually uses loading button here as well, by the way. What we do is. And then maybe say. OK, so what I want to be doing for this exercise is whenever you. Press any of these buttons. And it's not working perfectly, because what I actually wanted to do is change this into a separate component. So now it's showing loading everywhere. It's a bit annoying, but it's something you can easily fix by refactoring how components are structured. But I wanted to skip this for today to make it not too overwhelming. So this mutation here will take a. An object here which you can do a refresh queries. And in this refresh queries, you can actually pass the queries you want to refetch whenever you run the use mutation. So it will take the variable we created up here, which has our query. And I know we've saved it. So I would do this. We need to refresh the page. It's refreshing to see the value updates. There was a minor, minor lag and it's really. So maybe the test api I'm using is getting a bit overwhelmed. Or requests. Maybe we're just doing too many requests. There's a minor lag. You can see it going up now every time we press. And by using the refresh queries option, there are two ways to do it. You can do it this by defining an object with a query. And I'm guessing this way you can also pass variables to it in case you only want to get the subset of the articles. Or you can just reference the name of the query. Like this. To get articles is the name of this query. You can just reference it like this. Save it. Refresh just in case. And then it should be working as well. So yeah, that's how you would automatically get the new data whenever you change something. And I guess this was the final question we had for the introduction part. Usually I do this as like a full day workshop. And like I told you before, I'm also turning this into a course. So scroll down for the forum to drop your email address in case you want to. Learn more about the course later on. Here's the link again in case you want to be updated. Something else I wanted to show you is called graphql Code Generator. And this is part of the full day workshop actually that I do. And this is a cool library that helps you to generate typescript types based on your graphql schema. So if you would have graphql schema and a set of operations, which are the queries that we have in our app. And a plugin in which you define what you want to generate. You can generate all these graphql types based on your schema automatically on build type. It is kind of cool because if you're using typescript in your product. This way you don't have to type all the functions and variables every time you make a change. So this is the final thing I wanted to add to today's workshop. So thank you. And well, I hope to stay in touch and I hope you enjoy the conference as well. So bye bye.