What is GraphQL and why you should care?

Hello dear reader!

First of all I would like to apologise for not having been able to post in the last few weeks, I have been swamped with work. Before continuing, I’d like to wish you all a very happy new year (better late than never), and I couldn’t think of a better post for the start of this year than this one.

As you all know, most Apps depend on a backend system. This backend is responsible for communicating and serving data among the different users.This involves having an API (Application Programming Interface) to access the data. Most APIs are REST (Representational State Transfer) APIs. However, good old Facebook started to see some limitations and thought they could come up with a better and more efficient system. In this post we will do a bird’s eye of how it works and what advantages it brings to the table.

In a nutshell, GraphQL is a syntax that describes how to ask for data, and is generally used to load data from a server to a client. GraphQL has three main characteristics:

• It lets the client specify exactly what data it needs.
• It makes it easier to aggregate data from multiple sources.
• It uses a type system to describe data.

So how did this come to be?

For example, imagine you need to display a list of posts, and under each post a list of likes, including user names and avatars. So, you tweak you like array to contain avatars. Such as shown below.

But now, it’s time to work on your mobile app, and it turns out loading all that extra data is slowing things down. This translates in the fact that you need two endpoints, one with the likes and one without them.

Furthermoire, imagine if the “likes” and the “avatar” where to be stored on different storage types (MySQL for Avatar and MongoDB for likes for instance). Well now, we are in a bit of a mess. Extrapolate this scenario to however many data sources and API clients Facebook has to manage, and you can imagine why good old REST APIs were starting to show their limits.

The Solution

The solution Facebook came up with is conceptually very simple: instead of having multiple “dumb” endpoints, have a single “smart” endpoint that can take in complex queries, and then massage the data output into whatever shape the client requires.

What this means, is that there is a layer between the client and multiple data sources that is in charge of receiving requests and deciding how to serve them. Let’s have a quick metaphor example: The old REST model is like ordering pizza, then getting groceries delivered, then calling your dry cleaner to get your clothes. Three shops, three phone calls.

GraphQL on the other hand is like having a personal assistant: once you’ve given them the addresses to all three places, you can simply ask for what you want (“get me my dry cleaning, a large pizza, and two dozen eggs”) and wait for them to return.

In other words, GraphQL establishes a standard language for talking to this magical personal assistant. Why Facebook decided not to call it Siri is beyond me ;).

The best way to understand more about GraphQL and its possibilities is by practical examples. Let me know if you are interested and what you would like to see in the next post.

Thanks for reading!

Until next time!