Why People Like GraphQL
February 15, 2019
People like GraphQL, but I’m unconvinced it’s primarily for technical reasons. I think it’s something more human-related. People choose tools because they resolve some underlying frustration, and the current implementations of GraphQL solve some of the bigger frustrations people feel working with APIs.
The beginning of the web
Tim Berners-Lee provides an answer to the question “What made you think of the WWW?”:
Well, I found it frustrating that in those days, there was different information on different computers, but you had to log on to different computers to get at it. Also, sometimes you had to learn a different program on each computer. So finding out how things worked was really difficult. Often it was just easier to go and ask people when they were having coffee.
It’s interesting—though not surprising—the web was born out of frustration. Berners-Lee was tired of writing software to interact with so many different systems. “Can’t we convert every information system so that it looks like part of some imaginary information system which everyone can read?” he asked. He says this is how the web came to be.
GitHub’s reason for GraphQL
There have been lots of writing about technical reasons to choose it, but I believe those are secondary to the frustrations people feel working with APIs. Look at why GitHub moved to GraphQL.
[We] heard from integrators that our REST API also wasn’t very flexible. It sometimes required two or three separate calls to assemble a complete view of a resource. It seemed like our responses simultaneously sent too much data and didn’t include data that consumers needed.
The technical issue described here is what’s called “overfetching” or “underfetching.” But if you read into the quote, you can almost hear their customers saying, “I know what I want. Why do I have to do all this work to get it?” Or better yet, “Can’t you convert all of your API resources so that they look like part of some imaginary information system which everyone can read?”
Each web API today feels different. They all have their own SDK, their own client, their own generated tools, and their own nuances for exposing data over HTTP. Even within them, it can feel repetitive requesting a list of resources to solve common goals. GraphQL tries to resolve this, and GitHub saw that.
GraphQL unifies a fragmented world
GraphQL lets people think about data and how it’s related. It saves developers from piecing together a list of resources to understand how to get related data. It allows consumers to forget about the nuances of HTTP methods. People ask for what they want and that’s what they get. This comes with the cost of losing out on some of HTTP’s time-tested superpowers, but for most people, it’s worth the cost.
The next generation of web APIs
I hope the next step for web APIs will be to follow these steps and solve some of these frustrations. I think that step will be more pragmatic and more human-centered than it will be technically superior.