Why GraphQL?

In this video. I want to take a few minutes to explore an important question, Arguably the most important question we have right now, which is why GraphQL? We're about to spend a lot of time together learning this new tool. So we want to make sure it's going to be time well spent. In this video, we'll be talking about where GraphQL fits into our applications. We'll explore some of the benefits of using GraphQL. And lastly, we'll talk about why it's become such a popular tool. I want to kick things off by talking about where GraphQL fits into our application. Now, if you're like most people, your current application likely uses some form of a rest API where you're making Http calls between your client and the server to send and receive data. Your application likely has at least one client. I'm going to go ahead and say that for our fictitious example, we have a few different clients. Let's say that we have a web application where users can log in to manage their data and let's say that we also give them a mobile application. One for iOS and one for Android that they can take with them on the go. Now our clients, these three represent just part of our entire application stack. We also have our server and our database at a minimum. So let's represent those over here as well. Maybe we're using Node.js with the MongoDB database, maybe we're using Python with the Postgres database, or maybe we're using Java with MySQL. It doesn't matter. Any number of clients, phones, TVs, laptops can communicate with any number of servers because the glue between the two has always been standard Http requests, typically represented as some sort of rest API. Our rest API might have a dozen or so different URLs, different endpoints that can be used to communicate with the server. Maybe we have one for signing up, another for logging in. And let's say we're creating a blogging application so we have one for creating a new post and we have one for reading all of the available posts in the database. This is a pretty typical setup. When we introduce GraphQL, not a whole lot is going to change. We're still going to be able to use any client and we're still going to be able to use any server, although in this course we're going to be focusing on Node.js. All we're going to do is replace our Rest API with many endpoints with a GraphQL API that has just a single endpoint exposed. GraphQL stands for the graph query language, and this is something that also operates over Http, which means that we can use any backend language we want with any database we want and we can use any client we want. Maybe we have a web and mobile app. Maybe we also need to communicate with this GraphQL API from another server. That's perfectly fine as well. GraphQL is super flexible and we're going to see this throughout the course. So next up, I want to quickly go over why GraphQL is something that you should consider using. First up, GraphQL is fast, and to explore this, I want to go through a typical example of what it might look like to load the data necessary for a page with a rest API and then with a GraphQL API. So let's say that we start with the rest API example. We still have some sort of client, let's just say it's a browser and we have our server. The glue between the two is that standard rest API where we have a dozen or so different endpoints for managing our application data. Let's go ahead and make some Http requests to render a page. And let's say this page is a page for reading a blog post, so we need the title of the post and we need the post body. How do we get those? We make an Http request that might look a little bit like this. We make a get request to the following URL forward slash posts. Forward slash one two, three. Where 123. Is that post id, the server is going to parse this URL, it's going to find the correct data and it's going to send it back likely in the form of Json. So the server responds saying something like Here are the post details. Now maybe we get those post details rendered to the page and we realize we want a bit more information. I also want to show at the end of the post other posts by that author because I want to keep people on the site. I want to give them something to read when they're done with their currently reading. If I need more data, I make another request right here. I can make a second Http request to something like get forward slash posts here. I'm using a query string to filter by the post author. I want to find only posts with the following author. ID 3421. Just a made up id. Let's assume this is the author ID of the post that we fetched. The server once again is going to parse all of this. It's going to try to find other posts by that author and it is going to send them back so we can correctly render some of them at the bottom of the post page. Now let's say there's just one more thing we need to get. We need the comments made for this post so we can show those at the bottom as well. Right here, we're going to make our third and final Http request for another resource here. We're still making a get. Request to forward slash posts. Forward slash. One, two, three. The post ID forward slash comments. So we're getting all comments for that post. This is a pretty standard rest API URL structure. Once again, the server goes off, it parses this and it sends back the data. And finally we have everything we need. We can get everything rendered to the screen, giving the user the best experience possible. Now let's see how we might fetch the exact same data to render our blog post page, but using a GraphQL API. So we still want the post details like the title and body. I still want other posts by that author and I still want the post comments. Right here we have a client, We have a server. This time though, GraphQL is the glue between the two. And remember GraphQL can operate over Http. So in the end of the day we're still just making Http requests. Let's go ahead and make our first one getting the data needed for this page. Now the request we're going to make is going to be a post request, and GraphQL exposes just a single endpoint. That's a very important piece to the puzzle. Now, you could have called this whatever you liked. For this example, I happen to call it GraphQL, but we'll see how to rename that throughout the course. Now, here's the catch. With our request, we're going to be sending along a GraphQL query. A GraphQL query lets the client describe exactly what data it needs from the server. The server then gets all of that data ready and it sends it back so the client can describe exactly what it needs and it gets that data nothing more and nothing less. This is a very powerful piece to the puzzle. Instead of the server determining what data gets sent back, it's up to the client to request all of the data it needs. So in this case, I can actually request the post details other posts by that author and the post comments all with a single GraphQL request. Now the magic behind all of this is that GraphQL query. But that's actually not something we're going to talk about in this video, though it is a major topic of the course and we'll be getting to it very soon. For now, all we need to know about the GraphQL query is that it lets the client determine what data it gets back as opposed to a traditional rest API endpoint where the server determines what data comes back from an endpoint. Now, clearly three requests is more than one request. So GraphQL in the end of the day is going to be faster. It's going to allow us to get all of the data we need with one Http request. Now, raw speed alone is not enough to make a tool useful, and while that is an advantage of GraphQL, it's definitely not the biggest advantage. In my opinion. The biggest advantage is the flexibility of GraphQL. So with that last example, you could have easily argued that the rest API portion of the example was completely contrived. I intentionally chose to make it three requests instead of one. Clearly three is bigger than one, so obviously it's going to be a bit slower. But I made that choice to prove this point. We could absolutely cram all three of those endpoints into one. So let's revisit our Rest API example right here. We have our client, Our server Rest API is the glue. We make our single Http request here. I'm just using that first endpoint we had. We get the post by ID and what do we get back? We get back everything. We get our post details, which is the title and the body. We get the comments for the post and we get other posts by that author. This would be a perfectly fine approach. It would give the client everything it needs to render that page with just a single Http request. And the problem with this solution is that we now have this one endpoint which is making way more database requests than it was before. It's getting big and slow. It went from maybe making one database request to making at least three requests in order to get all of the data necessary. Now, for the desktop version of our app, that might be fine. Maybe we're going to use all of the data right away, so let's just get it. But what if we want a mobile version of our application to use the same back end? We make the Http request to that URL. And the problem is that the mobile application can't change the data. It gets back on mobile devices. We have a whole different set of considerations. We have less screen real estate. We have battery life to worry about. We have slow and expensive data. We want to make sure that we're not abusing the device. Otherwise people are going to get a poor user experience. The app is going to feel janky and they're likely to uninstall. This is actually the original reason GraphQL was created. Facebook had the same problem. They had a desktop version of the application. They had a mobile version of the application and they didn't always need the same data for both. They wanted a flexible way for the individual clients to request exactly the data they were going to use, nothing more and nothing less. So maybe on the mobile device we don't want to load the comments until someone clicks a button at the bottom of the post like show comments. With this solution, it doesn't really matter because the comments have already been loaded. It would be nicer if we could fetch the comments later when necessary. So the desktop and mobile devices both have different needs. This is not an issue we're going to run into with the GraphQL API on the desktop, we make a GraphQL query specifying we need all of that information. We need the post itself, we need the comments and other posts by the author and on our mobile device, what do we do? We make an Http request to the same endpoint with a different GraphQL query. In this case we say maybe we just need the post details so we get back just the post details. So with the website version of our application where the query asks for a lot of data, the server is going to have to do a lot of work making those three or so database requests necessary to get everything. The nice thing though, is that on the mobile version of the application where the query asks for less data, the server does less work. In this case, making the one database request necessary to get the post title and the post body with the rest API. We didn't have that same flexibility. We got the same response with both with GraphQL. It is the individual client that determines what data it gets back from the server. With a rest API, it is the server that determines what data gets sent back to what endpoint. And that's a huge difference. Now, yes, in the end of the day you could go ahead and try to customize your rest API, maybe adding on query strings to determine whether or not you want the comments and whether or not you want the other posts by that author. But at that point you're getting dangerously close to just recreating what GraphQL already offers. That's why huge companies like Facebook and GitHub are using GraphQL in production today. It provides the speed and flexibility needed for real world applications. So we saw that GraphQL was fast and flexible. GraphQL is also easy to use and simple to maintain with a rest API. If the client needs different data, it typically requires us to add a new endpoint or change an existing one using a GraphQL API, though, the client just needs to change its query, making GraphQL APIs much simpler to maintain in my own personal opinion and experience. So that's it. At this point, we've definitely asked more questions than we have answers to. For example, we have no idea what a GraphQL query is or how we're going to set any of this up, and that is okay. For the moment, we're going to dive into all of that in detail as always, a bit later in the class. For now, the only thing you really need to take away from this video is the following GraphQL creates fast and flexible APIs giving clients complete control to ask for just the data they need. This results in fewer Http requests, flexible data querying, and in general, less code to manage. We get all of the same advantages with this increased speed and flexibility. I am super excited to dive into the rest of the course and actually put all of this into practice with a real world production ready application. So let's go ahead and jump right in to the next video.