How REST makes GraphQL look so simple
API. We hear that acronym thrown around a lot. What is it? It stands for Application Program Interface. 😕. Ok, so what does it mean? Well it is supposed to provide developers with [some] programmatic access to a proprietary software application
Whether you are a front end developer creating the next best thing or you are a back end developer being harassed by the former to add some support or make changes to an existing version or even a technical writer documenting stuff for third-party consumers, API’s are referenced a lot in the tech sector.
As everyday consumers, we all use it; If you are checking the scores of your favorite team, watching cat videos or swiping right on Tinder, you are probably interfacing with some API. I remember seeing the infographic below on what happens in an internet minute and I was blown away by the numbers if indeed accurate. Most of them (if not all) make use of an API in one form or the other
In the last decade, there have primarily been two main ways of interacting with APIs - SOAP and REST. I won’t get into the nitty-gritty of the differences but just know I simply shudder at the thought of using one of them (cough cough SOAP) in the present day. It’s safe to say that REST has captured the market in terms of adoption and it’s been the go-to way of fetching data for a while. Well, things seem to be shaking up in that space and the “new” kid on the block is known as GraphQL.
With REST, when we need to fetch data for our app we will do something like so:
… And then get a whole bunch of data.
We parse this data and take what we need from it and just ignore the rest of it.
Sometimes, we may need even more data based on what we had just collected. In this case, say we wanted to get more info from the author, what do we do? All we have is the id 1. Ding ding ding. We need to make another call!
By now, hopefully, you get the pattern. We will get a whole bunch of data about the author than we probably will need and may need to filter it some more to get what we want. There are too much of two things.
- Data coming back
- Calls being made to the server
This could go downhill really fast, even when you explore the idea of query params or designing tailored endpoints.
So here is where the new kid GraphQL, shines. Let’s go back and try and redo what we did above with REST
That’s it! Seriously, it’s that simple. Think of all the bandwidth saved from the back and forth and in turn benefit from the quick response time.
There’s more to GraphQL and you should start reading about it here: https://graphql.org/
If you want to read more about GraphQL and some adoption stories from companies, check out some slides I did for one of my talks.
https://slides.com/elomt/graphql/fullscreen
The last page contains links to some exciting reference material as well.