GraphQL vs REST API's

Xavier Decuyper
A free video tutorial from Xavier Decuyper
Full-stack developer & passionate about technology
4.6 instructor rating • 3 courses • 25,446 students

Lecture description

REST API's are very popular still today. So why would you start using GraphQL instead?

In this video we'll explore the big differences between GraphQL and REST. I'll also talk about why GraphQL is a better choice and how much more efficient it is.

Learn more from the full course

Complete guide to building a GraphQL API

Everything you need to know to build your own GraphQL API

01:45:28 of on-demand video • Updated October 2017

  • Understand how GraphQL works
  • Build your own GraphQL API with JavaScript
  • Learn how to install and use Graphiql
English [Auto] Hi everyone my name asks of you. And in this video we'll be taking a look at the differences between you graphical and the bias. Now I came up with a practical example for comparing the two. Let's assume that we have an API for a blog or blog is rather simple and it contains three types of objects. Block posts authors and comments. The relationship between these are fairly obvious. Blog posts are written by a single author and blog post might have one or more comments. Now let's take a look at how we can build an API for this using the rest. Principle you would start by creating a single endpoint per entity. Want to get the details about a block post and this would contain the title and the contents of the post. Another one to get the details of a comment and this would include the name of the poster and of course the content of the comment itself will also add one to get the details of an author which will return the name and an email address for example. And you should also be able to list all the block posts on the website and so you add a fourth and point that returns a list of block posts. Now this architecture seems fine but lets actually use it. I want to render a list of block posts where we show the title of each post and the name of the author. So I'll start by making a request for the latest block posts and the API will answer with an airy containing the references to some of these posts. After that I need to make one request per block post to get the title and the contents of each. But this response contains yet another reference this time a post references an author. So in order to know who wrote the post I need to make another set of requests to get the name of each of the authors. And this is what the API would return. Now this example is a bit exaggerated but it demonstrates the pain points of rest the API as in real life applications. You'll definitely come across situations where you have to make multiple requests to the server to get all the data that you need. This can be painfully slow because each trip to the server adds a lot of latency and that is not great for mobile connections for example. Now you might want to be tempted to add a few endpoints to solve this problem. You could add a posts with authors and point to return a list of posts together with the details about the author and then you can add another one to return comment counts as well. But this is not a very scalable solution. This will cause an explosion of endpoints that will be hard to maintain and hard for new people to learn how to use. So let's now take a look at how graphical solves these issues with graphics. Well you can make a single request and ask for all the resources that you want. So here I can say I want the latest post with the name of the authors. The graphical server will then look up the block post for you. It will follow the relationships to author and it will fetch all the information about the author and it will turn everything to you in a single request. Now I'd like to point out here that the response of a graphical query has the exact same shape of your query. This is very useful because you will know in advance how the API is going to respond and with the rest API. That's just not the case. So here we can see on the left that equerry for posts and on the right. We receive a object from GraphicLy well which contains a post area containing objects with all of the attributes that we want. That's title content and then an author object with a name property. So to summarize with graphically Well you can get multiple resources in a single request. The structure of your query defines the structure of the response graph. I'll also understands the relationship between your objects and it can look them up if it's needed. And finally you always get the data that you need. Never too much and never too will. So that was it for this lesson in the upcoming videos. I will explain the main concepts of graphics. Well thank you very much for watching and I'll see you in the next video.