🧠Knowledge Series #15: What is GraphQL?
The differences between GraphQL, SQL and REST explained
🔒The Knowledge Series is a series of easy to read guides designed to help you plug the gaps in your tech knowledge so that you feel more confident when chatting to colleagues. Clearly explained in plain English. One topic at a time.
If you’re a free subscriber and you’d like to upgrade to unlock them you can do so below. Or you can find out more about paid access here.
Hi product people 👋,
GraphQL is officially boring. Or at least that’s what some commentators think.
And the reason for this isn’t because the technology itself is boring, but rather that, as with all new technologies and frameworks, once the hype cycle dies down a bit, so does the excitement of adopting the new technology.
In this edition of the Knowledge Series we’ll delve into GraphQL from a non-engineer’s perspective so that the next time the engineering team in your company is deciding whether or not to adopt it, you’ll be equipped with the Knowledge to understand both what the technology is and the trade offs involved in using it.
Coming up:
What is GraphQL?
Who is using it and why? A closer look at how PayPal, Netflix and Shopify are using GraphQL
GraphQL vs SQL: what’s the difference?
The future of GraphQL and its downsides
What is GraphQL?
Before we delve too deeply into GraphQL, we need to understand the context of where GraphQL fits into the wider picture.
How the web works: a quick recapÂ
A web app is typically comprised of:
Front end components
A backend (database, programming languages)
APIs and endpoints which interface between the front end and the backend to grab the data required to populate a front end
In order to render elements onto a web page, requests need to be made to APIs via endpoints but these requests can often contain both the bits you want and unnecessary bits you don’t want.
Using GraphQL though, you can be smarter about it and only request the bits you want.
GraphQL explained
GraphQL, like React, started life at Facebook as an open sourced technology. Launching in 2012, it quickly gained a reputation as a modern way to query and retrieve information. Its primary purpose was to reduce the inefficiencies associated with traditional REST APIs.
As we’ve previously said in the Knowledge Series on APIs, APIs are resource-based, which means when you’re making a request to an API you’re requesting the resource. In the case of the Spotify API, a resource could be an album, for example.Â
But what if you don’t want an album, but instead you want a song from an album, the artwork and the track length - all in one go?Â
Using traditional APIs, you’d have to make several separate requests. Using GraphQL you can construct a smarter query to only get the bits you need.
If this doesn’t quite make sense, here’s an analogy using my favorite topic (food) which should hopefully help.
Let’s imagine you’ve decided to order takeaway and you’re in the mood for a low carb dinner. You’d like to order some chicken breast, cheese and salad.
One of the most inefficient ways to order this would be to order 3 separate meals:
Chicken nuggets
A Big Mac with cheese
Side salad
It’s possible to get everything you need from these 3 meals. How?
Firstly you’d peel off the batter from the nuggets, next you’d remove the burger and the bun to get a cheese slice and finally you’d open up your side salad. You’ve now got all the ingredients you wanted to create your chicken breast, cheese and salad dinner. It’s edible but you’ve created a whole bunch of inefficient waste in the process.
What if, instead of ordering multiple meals, you could customise your order at the checkout and pick out exactly what you want from the menu instead? In that case, you’d order some chicken breast pieces, a slice of cheese and a side salad - and you’d be delivered exactly what you wanted. No waste.
This is how GraphQL was designed to work.