A free video tutorial from Andrew Mead
A Full-stack Developer & Teacher
4.7 instructor rating • 4 courses • 329,664 students
Learn more from the full courseThe 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 graph. Q Well 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 graft fits into our applications. We'll explore some of the benefits of using graphs. 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 graft well 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 or 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 J.S. with the Mongo D-B database maybe we're using Python with the post gresse database or maybe we're using Java with my ask you owl. 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 HTP requests typically represented as some sort of rest API or rest. API might have a dozen or so different you are Elle's 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 graft. 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 --. All we're going to do is replace our rest API with many endpoints with a Graph API that has just a single end point exposed graph. L stands for the graph query language and this is something that also operates over HTP which means that we can use any back end 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. Graph L is super flexible and we're going to see this throughout the course. So next step I want to quickly go over why graphical is something that you should consider using burst up graph. Well 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 AAPI 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 HTP 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 HTP request that might look a little bit like this. We make a get request to the following You are L.. Forward slash posts forward slash 1 to 3 where 1 to 3 is that post ID. The server is going to parse this you Arel 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 do 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 for it here. I can make a second HTP 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 3 4 to 1. 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 is just one more thing we need to get needed. Comments made for this post so we can show those at the bottom as well. For here we're going to make our third and final h t t p request for another resource. Here we're still making get request to forward slash posts forward slash 2:59 the post ID forward slash comments. So we're getting all comments for that post. This is a pretty standard arrest API you RL 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 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 the post comments right here. We have a client we have a server. This time though graft well as the glue between the two. And remember graphs you all can operate over HTP. So in the end of the day we're still just making HTP 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 graphed QOL 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 happened to call it graft well 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 he will query a graph you will 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 graft will request now the magic behind all of this is that graph. Well queery 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 graph you will query is that it lets the client determine what data it gets back as opposed to a traditional arrest API endpoint where the server determines what data comes back from an endpoint. Now clearly three requests is more than one request. So Grath 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 HTP request now Rod Speed alone is not enough to make a tool useful. And while that is an advantage of graft Well its definitely not the biggest advantage in my opinion. The biggest advantage is the flexibility of graft well. 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 its 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 HTP request here I'm just using that first end point 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 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 HTP request. And the problem with this 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. It went in 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 HTP request to that you are l 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 Genki and they're likely to uninstall. This is actually the original reason graft well 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 comment 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 graft UL API on the desktop. We make a graphics UL query specifying we need all of that information. We need the post itself when you add the comments in other posts by the author and on our mobile device. What do we do. We make an HTP request to the same endpoint 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 1 database request necessary to get the post title and the Post body with the rest API we didn't have that same flexibility. We've got the same response with both with graphs. Well 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 graft you all already offers. That's why huge companies like Facebook and get hub are using graphical in production today. It provides the speed and flexibility needed for real world applications. So we saw that graph well was fast and flexible graph 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. Well API though. The client just needs to change its query. Making graphical API is 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 we're 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. Well creates fast and flexible API eyes giving clients complete control to ask for just the data they need. This results in fewer HTP 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.