REST is great, but there are some problems when you start working with large amounts of data and relationships. GraphQL can offer some great alternative solutions.
- [Instructor] In this section, we're going to be looking at GraphQL as an alternative API. This section will be comprised of four videos. We'll be just getting an introduction to GraphQL, learning how it works, and comparing it to the REST framework a little bit. And learn about all the internals of GraphQL and the different pieces that make it function. We'll be learning how to use Graphene, Django's GraphQL library, to build custom objects. We'll be looking at authentication libraries for Graphene. We'll be just getting an introduction to GraphQL.
In this video, we're going to try to understand how GrapQL work. We'll learn a little bit about the Python/Django libraries to build GraphQL's API, called Graphene. And we're going to look at some of the advantages GraphQL has over the REST API. So what is GraphQL? GraphQL is a web query language. It provides an API interface that users can use to submit queries, kind of like SQL, and receive data from.
So what exactly does it look like? So let's take a look at GraphQL and Django's GraphiQL interface. Graphene, the Django library, provides a GraphiQL interface that will be available through your API's end-point whenever you set it up. We'll learn how to do that in the next video though. For now, let's just look at the syntax for GraphQL. To make a query, we can use this box. To start off a query, all you have to use is the keyword query, and then curly braces.
From here, it's kind of like writing json. First you need to provide a named function in Graphene. These are also called resolvers. For the resolvers that I provided with this example, we have allQuestions. This is the resolver name. We'll also learn about that in the next video. Once you have the named function, or resolver, you use another set of curly braces to denote that you want it to specify which fields are returned.
Then you just list out the fields of the type being returned and GraphQL will return the specific fields relating to that. GraphiQL also provides hinting for the fields that are available. Once you type out the fields that you want returned, you can just hit the play button. As you can see, GraphQL has provided a json array that has data. And then the function name, or the resolver name, and then a list with the data that matched the query inside of it.
So that's the basic structure of a GraphQL query. You provide the keyword, either query or mutation, which we'll learn a little about later, then you provide the resolver name and a list of fields you want back from that resolver. GraphQL in return gives you a json array with a data attribute. It has a nested resolver name that then provides a list of all the data that matched your query.
So now let's have a quick comparison of GraphQL versus REST API. One noticeable difference is GraphQL uses a single API end-point. Whereas REST usually has multiple API end-points. In the last section, whenever we built our polls application, we had a polls and a choices end-point. We also created a third, custom end-point to provide specific data for what we were looking for. GraphQL does not have multiple end-points. As you can see with our example here, whenever we're running this query, we're still only going to GraphQL.
We then provide get parameters for all the other information. GraphQl also doesn't suffer from the same over fetching and under fetching issues that REST sometimes does. Whenever you make a REST request, you either get all of the data or you don't get any of it. Let's take this API as an example. It's an API for a simple blog system using a user ID to reference a user, an ID for the post ID, a title for the post, and a body for the post.
Assuming we only want the title and the user ID, we don't really care about the ID and the body. With REST, this might be a little difficult to get around. We may just have to request all of the information. With GraphQL, this isn't a problem. Using our polls example, if we don't care about the pub date, we just remove it from the fields to be returned. And now we don't get it back any more. This might not seem like a big issue with these small examples that we're using, but, if there were a lot more fields like there are with some other APIs like Twitter or Facebook, this quickly comes in handy, especially on mobile devices where maybe your internet connectivity is limited.
In any case, you always want to request as little information as you can get away with. Especially if you're not going to use it. Then you don't really need to request it. Another commonly brought up point for GraphQL is that you can automatically cascade relationships. REST usually can't do this and has to resort to an idea called REST-includes that involves using get parameters to tell the REST API to cascade certain relationships. Let's look at an example API for a blogging system that shows the includes issue in real time.
This blogging system simply provides a title, a body, a post ID, and a user ID. The issue with this is, if we wanted more information about the author, we would have to use the user ID to make another http request for more information. This can be okay, but it does increase network latency and the amount of time it takes for your page to load. GraphQL doesn't have this problem. As you can see with our polls example, we simply provide another choice set option and tell it what fields we want, choice text and votes.
Then, on the allQuestions return data, we have another list of choice sets with an array for each different choice with the choice text in vote. So, with the examples provided, you can see that GraphQL provides a much more flexible API than REST can. With cascading relationships, the removal of under and over fetching issues, and a single API end-point coupled with the fact that GraphQL isn't just an API, it's also a query language, GraphQL is easily more flexible than REST API can be.
The one downside that GraphQL does have is that GraphQL isn't as well known right now. It was only released in 2013 while REST's been around for a significantly longer time. Due to this, REST is much more well known and GraphQL may not have been heard of by developers that you have to work with. That is one thing to consider when choosing between the two frameworks. So, in the next video, we're going to learn how to build a basic schema with GraphQL. And we're going to look at all the different components that make up Graphene and Python and Django.
See you then.
- Extending class-based views
- Building a REST API
- Working with GraphQL
- Building a basic schema
- Optimizing your environment
- Working with Pipenv
- How Django handles testing
- Securing the Django admin