GraphQL

Almost every app fetches its content from a foreign computer on the internet, the server. To do so, it has to tell the server which data it wants. GraphQL is a defined language for exactly this kind of request. The app sends a sort of order slip listing the desired fields, for example name, profile picture, and the last five posts. The server responds with exactly these fields, in the same structure. The method was developed at Facebook in 2012, and since 2015 anyone has been free to use it.

Why fetching data is otherwise so cumbersome

Before GraphQL came along, REST was the usual way. There, every kind of information has its own address. One address delivers user data, another the posts, a third the comments. The server decides what goes into the response. The app has to take whatever comes.

This creates two typical problems. In the first, the app gets too much: it only needs the name but receives the entire profile with fifty fields. In the second, it gets too little and has to make several requests one after another. For an overview page, ten requests can quickly become necessary.

On a mobile network, this is noticeable. Every additional request costs waiting time, and superfluous data costs data volume and battery life. This was exactly the problem Facebook had with its mobile app when GraphQL was created. A single, precise request is there considerably faster than many imprecise ones.

Schema, query, and resolver

The foundation is the schema. It specifies bindingly which data types exist and which fields belong to them. A type “User” has, for example, the fields name, email, and posts. The schema is at the same time the documentation of the interface. Development tools read it and suggest matching fields while typing.

The actual query looks like a scaffold of curly braces without content. You write into it which fields you want, and you may nest them: for the user, their posts, and for each post, its comments. The server returns the answer in exactly the same form. This makes the result nicely predictable for developers.

On the server side, behind every field sits a small piece of code, the resolver. It knows where the value comes from — from a database, from another service, or from a computation. One advantage: the network address always stays the same, usually ending in /graphql. One drawback: a deeply nested query can put heavy strain on the server, which is why operators limit the allowed nesting depth.

Where GraphQL shows up on the web and in AI products

The technology is rarely visible, yet it is used constantly. GitHub, Shopify, and the developer interfaces of many large platforms offer GraphQL. Anyone who opens an online shop page often triggers exactly such queries in the background. Streaming services and social networks also rely on it, because their interfaces show many different pieces of data at once.

The term has also become interesting in the AI space of late. Language models are increasingly meant to fetch data themselves rather than merely answering from memory. A schema that clearly names every available field helps a model formulate a correct query. Some companies therefore deliberately set up GraphQL interfaces before letting AI assistants loose on their data.

A common misconception: that GraphQL is a database. That is not true. It is merely the language between app and server; the data still resides in perfectly ordinary databases. And GraphQL does not replace REST everywhere — for simple interfaces with few fields, the older approach often remains the leaner choice.