Why GraphQL?

A free video tutorial from Andrew Mead
A Full-stack Developer & Teacher
Rating: 4.6 out of 1Instructor rating
4 courses
397,294 students
Why GraphQL?

Learn more from the full course

The Modern GraphQL Bootcamp (with Node.js and Apollo)

Learn how to build GraphQL applications using Node.js. Includes Prisma v1, authentication, Apollo Client, and more!

23:24:42 of on-demand video • Updated November 2020

Learn and master GraphQL by building real-world Node applications.
Use Prisma v1 to store and access data from a production database.
Use Apollo Client to communicate with GraphQL from your web app.
Learn how to deploy and test your GraphQL applications.
Test your skills and gain confidence by completing more than 80 coding challenges.
Get access to a free 110-page PDF guide with lecture notes, code samples, and documentation links.
English [Auto]
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 Grauwe Keywell, 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 GraphicLy fits into our applications. We'll explore some of the benefits of using graphics. Well, and lastly, we'll talk about why it's become such a popular tool. I want to kick things off by talking about where graphics QOL 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 HTP 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 no Jast with the Mongo database. Maybe we're using Python with the PostgreSQL database, or maybe we're using Java with my. Well, 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 or rest API might have a dozen or so different URLs, different end points 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 well, 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 J.S. All we're going to do is replace our rest API with many endpoints, with a graphical API that has just a single endpoint exposed graphical 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 graph API from another server. That's perfectly fine as well. Graphical is super flexible and we're going to see this throughout the course. So next up, I want to quickly go over why graph cual is something that you should consider using. First up, graphical 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 graphical 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 U. RL forward slash posts, forward slash one to three where one, two, three is that posted. The server is going to pass this you URL. It's going to find the correct data and it's going to send it back likely in the form of Jason. 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, what they're 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 posts here. I'm using a query string to filter by post author. I want to find only posts with the following author ID three, four, two, one, 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 pass 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 needed is 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. That request to forward posts forward one to three, the Post posted forward comments, so we're getting all comments for that post. This is a pretty standard rest API you URL structure. Once again, the server goes off, it passes 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 to page, but using a graphical API. So we still want to post details like the title and body. I still want other posts by that author and I still want to post comments right here. We have a client, we have a server. This time, though, graphical is the glue between the two. And remember, graphical 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 graphical exposes just a single end point. 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 graphical, 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 graph. You'll query a graph, you'll 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, any post comments, all with a single graphical request. Now, the magic behind all of this is that graph 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 will be getting to it very soon. For now, all we need to know about the graphical 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 graphic you well, 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 graft, well, it's definitely not the biggest advantage in my opinion. The biggest advantage is the flexibility of graphical. So at 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 and points 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 in the body. We get the comments for the post and we get other posts by the 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 the solution is that we now have this one end point, which is making way more database requests than it was before. It's getting big and slow in waiting for maybe making one database request to making at least three requests in order to get all 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 you 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 Jenky and they're likely to uninstall. This is actually the original reason Graphical was created. Facebook had the same problem that a desktop version of the application, that 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 Cellcom. With a 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 graphical API on the desktop. We make a graphical 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 end point with a different graphical query. In this case, we say maybe we just need to 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 arrest API. We didn't have that same flexibility. We got the same response with both with graphical. 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 end point. 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 post by that author. But at that point, you're getting dangerously close to just recreating what graphical already offers. That's why huge companies like Facebook and GitHub are using graphical in production today. It provides the speed and flexibility needed for real world applications. So we saw that graph. Q l was fast and flexible graph. Google is also easy to use and simple to maintain with the rest API. If the client needs different data, it typically requires us to add a new endpoint or change an existing one using a graph dual API, though the client just needs to change its query, making graphical 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 graphical query is or how are we going to set any of this up. And that is OK 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 graph. Graphical creates fast and flexible APIs, giving clients complete control to ask for just the data they need. This result in fewer HTTP requests, flexible data querying and in general, less code to manage. We can 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.