I’ve heard all the hype with GraphQL and couldn’t wait to see what the fuss was all about. I wondered if this would even be worth my time learning considering it’s relatively new and the industry standard is REST (another way of querying data, but we’ll talk about that later in this blog). Plus, let’s be honest, there’s always a new language, framework, etc. released that’s supposed to make developers lives’ easier. Some of them are pretty cool (see Flutter), but others are underwhelming at best. So, let’s dive right in, and I’ll show you what I’ve learned so far and why it may be a good option.
What is GraphQL?
To keep it simple, GraphQL is a query language for APIs and a system that describes how to ask for data from a server to a client. It also allows you, on the client side, to specifically get the data you want to return and nothing more. Pretty neat, right? For example, let’s say we have a database with a list of movies, and we want to return or show a particular movie that displays title, genre, description, and director on a website’s page. Not only that, but we want to get back all of the movies that the director has directed and some other data. Below is an example of this.
Look confusing? Don’t worry, here’s a quick example to help clarify: Here we are querying a specific movie by its ID, and we want to return only the data we need. GraphQL allows us to nest (see example above) and have access to all of the relational data associated with the movie. So we have the movie ID and are returning the title, genre, and description. Next, we go deeper into the database and return the director’s name and the name of all the director’s movies.
Why is this awesome and important? Because we returned all of that data with just one query! Awesome! Now, remember earlier when I briefly talked about REST as one of the ways of querying data? Let’s show the sample example but this time we’ll do it the RESTful way.
The RESTful approach
To retrieve the same data from a RESTful approach, we start by creating two separate endpoints. The first query would be to retrieve a specific movie by its ID and all of the information related to the movie.
If we wanted to get all the movies or any other data associated with the director we would need to create another endpoint.
As you can see, we’ve already made two requests to display just the movie and director information. Imagine the queries if we wanted to get information for each of the movies the director has made! We would have to make multiple endpoints to retrieve all of that data, which as you can see already, is starting to be very inefficient. As your application grows, the client could possibly have a miserable bad user experience because you have to make so many requests that your app feels slow.
In addition to that, the RESTful method returns a lot of data we may not need, and if it’s a big project… Yikes. GraphQL eliminates this problem by only requesting what we actually need.
Final conclusion
So what is my opinion on GraphQL? GraphQL solves over-fetching by allowing the client side to only request what is needed. There’s a little bit of a learning curve, but in the end, it’s worth learning.
If you’re building an application and you want to be explicit in the data you want to return or you’re dealing with data that deals with multiple relationships, you should try GraphQL. Don’t worry, though, the RESTful approach isn’t going anywhere. Plus, there are some things REST does better, like caching, but that’s for another blog.