Demystifying GraphQL

As GraphQL starts to get more and more attention, I found myself getting frustrated when reading comments about it. It seemed to click pretty quickly for me, but others seemed to approach it with a sense of confusion and uncertainty.

Why doesn’t everyone else get it?!

After giving it a bit thought, I think I may have figured it out. The name GraphQL is a combination of two buzzwords in the latest tech vernacular. No wonder people were getting confused — they’re probably trying to pattern match it and compare it to other new things they’ve heard of lately.

Of course, it’s not their fault. But I really like GraphQL, and I really want more people to start using it, so I feel like it’s partially my responsibility to try to clear up some of the confusion.

My suggestion is to mentally replace GraphQL in your mind with either ProductQL or BackendQL for a moment, and then read on.

• It‘s not a storage layer
• It’s not a query language (in the sense you’re probably thinking)
• It has little to do with graphs (in the sense that you’re probably thinking)
• It has no notion of fetching/sorting (as you might initially believe)

What is it? It’s a language for defining a strongly typed API/interface for your product or service. Backend developers write a thin, typed interface over your existing application layer and business logic, keeping in mind any performance or technical constraints (i.e. caching anything expensive or not exposing it at all).

This interface is accessed via a single HTTP endpoint by product developers, using string based queries that are closer to the actual mental model of a product than, for example, a REST API.

Simply put, GraphQL is a language that your server engineers use to expose a better API for your product developers to use in order to build nice things.