GraphQL

Precise data fetching through a single typed endpoint

GraphQL is an open query language and runtime for application programming interfaces that lets a client request exactly the data it needs in a single request, described by a typed schema.

A classic REST interface offers many fixed addresses, and each returns a fixed slice. Anyone who wants to assemble data from several of those addresses makes several requests, and often receives more fields than needed. GraphQL inverts that relationship: it exposes a single endpoint, and the client describes the exact shape of the response in its request. The server returns precisely that shape, no more and no less. This page describes what GraphQL is, what it is good for, and where its limits lie.

One language, one schema, one endpoint

GraphQL was developed internally at Facebook from 2012 and released in 2015 as an open specification with a reference implementation. Since 2018 the specification has been maintained not by a single company but by the GraphQL Foundation under the umbrella of the Linux Foundation. The specification itself describes GraphQL as a query language and execution engine for describing and performing the capabilities and requirements of data models in client-server applications. The distinction matters: GraphQL is not a programming language for arbitrary computation and not a database, but a language for querying application servers, regardless of what stores sit behind them.

At the centre stands the schema. The provider of a GraphQL service defines types with their fields and attaches to each field a resolver that fetches the matching value. The schema is therefore a binding contract between server and client: it sets out which data is queryable and what shape it has. From that contract follow GraphQL's three operation types: queries read data, mutations write or change it, and subscriptions deliver ongoing updates. This strict typing places GraphQL close to the idea of API-First development, where the interface precedes the implementation.

What makes the approach strong

The most tangible gain is precise fetching. Because the client dictates the shape of the response, the typical too-much or too-little of data falls away: not one field too many, no second request for a missing field. Several related resources can be fetched in a single request instead of calling several addresses one after another.

The typed schema brings a second benefit. Because every request is validated against the schema, the server rejects invalid requests before executing them, and tooling can use the schema to offer auto-completion and documentation. On top of this comes introspection: a GraphQL service can describe its own schema, so that a client can learn at runtime which types and fields are available. This very property makes a GraphQL interface a natural point of integration: it is well suited to exposing data from one source in a bundled form and connecting it to bespoke frontends or downstream systems. A knowledge platform such as Wiki.js, for instance, exposes its content through a GraphQL interface, which makes it accessible for reuse in custom applications or in a knowledge-retrieval setting.

The flip side of flexibility

The same flexibility that makes GraphQL strong shifts some problems from the client to the server and creates new ones. Four points recur in practice.

Caching is harder than with REST. A REST address is a globally unique identifier on which the usual HTTP caching mechanisms can hook. GraphQL has no such address-based key, because all requests run through the same endpoint. As a countermeasure it is advisable to give each object a globally unique field as a key, on which client-side caches can build.
The N-plus-1 problem on the server. A naively written resolver can trigger a separate database query per item in a list: one request for the list, then a further one for each item. A single request thus becomes many. The usual countermeasure is to batch such queries over short time windows with a tool like DataLoader.
Cost and complexity of a query. Because the client freely chooses the shape of the request, a single, deeply nested query can place heavy load on the server. The server cannot always know in advance how expensive a request will be. Common protective measures are limiting the nesting depth, estimating cost via weights per field, and limiting the request rate.
A learning curve. Schema design, resolvers, batching and cost control are topics in their own right. A team coming from REST has to build up these concepts first, before the gain in precision outweighs the initial extra effort.

These points are not grounds for exclusion but the price of the flexibility. Notably, on several of these operational questions, such as caching and cost control, the specification is deliberately silent and leaves them to implementations.

Where it sits

GraphQL is one way to build an interface, not the only one. It does not compete with the database behind it but sits in front of it and bundles its data into a graph that the client queries. Where a REST interface offers many fixed slices over many addresses, GraphQL offers a flexible view over one endpoint. Both approaches solve the question of how systems exchange data, and so they stand alongside other integration patterns such as the Model Context Protocol, which connects AI models to data sources at runtime. GraphQL answers the question of how a client receives exactly the data it requests.

References

GraphQL Foundation GraphQL Specification. The language specification; current stable edition of October 2021, covering the type system, query language, validation, execution and introspection. (October 2021). spec.graphql.org/October2021/
GraphQL Foundation Best Practices and Performance. Official guidance on caching, the N-plus-1 problem and batching queries with DataLoader. (2026). graphql.org/learn/performance/
GraphQL Foundation Security. Protection against expensive operations by limiting depth, complexity and request rate. (2026). graphql.org/learn/security/
Wikipedia GraphQL. Overview of its origin at Facebook from 2012, its 2015 release and the 2018 transition to the GraphQL Foundation. (2026). en.wikipedia.org/wiki/GraphQL

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.