GraphQL solves REST's over-fetching problem by introducing a different set of trade-offs around caching, complexity, and security. Here's how to decide which fits your actual product.
The pitch for GraphQL is almost always the same: a mobile app team was tired of REST endpoints returning either too much data or not enough, so they wanted a single query language that lets the client ask for exactly the fields it needs. That's a real, well-founded problem, and GraphQL solves it well. What the pitch usually leaves out is that GraphQL trades over-fetching for a different set of problems — caching gets harder, the server has to defend against clients constructing arbitrarily expensive queries, and the tooling investment to do it properly is real. Neither architecture is universally better; they optimize for different things.
We build both REST and GraphQL APIs depending on what a project actually needs. Here's the practical version of the trade-off, not the conference-talk version. If you're weighing a few architecture decisions at once, our comparisons hub rounds up the rest of these trade-off breakdowns in one place.
The Core Difference in One Paragraph
REST exposes a fixed set of endpoints, each returning a predetermined shape of data — GET /users/123 returns whatever fields the server decided that endpoint returns, every time. GraphQL exposes a single endpoint with a schema describing every type and field available, and the client sends a query specifying exactly which fields it wants back, potentially traversing relationships in one request (a user, their orders, and each order's line items, all in a single round trip).
That single distinction — fixed response shape versus client-specified response shape — is the root of almost every other trade-off between the two.
Over-Fetching and Under-Fetching: GraphQL's Strongest Case
This is the problem GraphQL was built to solve, and it solves it well. A REST endpoint designed for a web dashboard that needs twelve fields from a user object will send all twelve fields to a mobile app that only needs three, wasting bandwidth on every request — over-fetching. Conversely, a mobile screen that needs data from three different REST resources (a user, their recent orders, and a notification count) either makes three separate round trips or waits for the backend team to build a bespoke aggregation endpoint just for that screen — under-fetching, solved with custom endpoint sprawl.
GraphQL removes both problems at the protocol level: the client asks for exactly the fields and nested relationships it needs, in one request, regardless of how many underlying data sources or services are involved on the server side. For products with several different client types (web, iOS, Android) with genuinely different data needs per screen, this is a substantial, measurable improvement in both bandwidth efficiency and how many bespoke backend endpoints a team has to maintain.
Caching: REST's Strongest Case
REST's fixed endpoints map directly onto HTTP caching — a GET request to a specific URL can be cached by browsers, CDNs, and reverse proxies using standard HTTP cache headers, with no special client-side logic required. This is a genuinely mature, well-understood, infrastructure-level caching story that works the same way it has for two decades.
GraphQL's single endpoint (almost always a POST request, since queries can be large and complex) breaks this model. HTTP-level caching doesn't apply the same way, since the same URL now serves every possible query. GraphQL clients (Apollo Client, Relay, urql) solve this with normalized client-side caches that track individual entities and their fields, which is powerful but is a different, more complex caching model to reason about — and CDN-level caching for GraphQL requires deliberate additional infrastructure (persisted queries, GraphQL-aware CDN configuration) that REST gets for free from any standard HTTP cache.
For a content-heavy application where CDN caching is doing most of the performance work — a marketing site, a blog, a product catalog with infrequent changes — REST's caching story is simpler to reason about and cheaper to operate.
Versioning and Evolution
REST APIs typically version through the URL (/v1/users, /v2/users) or headers, which means maintaining multiple parallel versions of an endpoint as a product evolves, with real overhead in keeping old versions correct while building new ones. GraphQL's schema is designed to evolve without versioning in the traditional sense: new fields get added to a type without breaking existing queries that don't ask for them, and fields intended for removal are marked @deprecated and monitored for usage before actually removing them.
This is a genuine advantage for a product with many client versions in the wild simultaneously — mobile apps especially, where you can't force every user to update immediately. A GraphQL schema can add capability for new client versions while old client versions keep working against the same schema, unaware of the new fields they're not asking for.
Where GraphQL's Flexibility Becomes a Security Problem
REST's fixed endpoints are naturally bounded — an endpoint does a known, fixed amount of work, and rate limiting or load estimation is straightforward because the cost of any given request is predictable. GraphQL's client-specified queries remove that boundary: a client (malicious or just badly written) can construct a deeply nested query that fans out into an enormous number of underlying database calls, or request the same expensive field a hundred times in aliased forms in one request.
This is a real, well-documented class of problem — sometimes called query complexity or depth-based denial of service — and a production GraphQL API needs deliberate defenses that a REST API gets for less effort: query depth limiting, query cost analysis (assigning a "cost" to each field and rejecting queries above a budget), and persisted queries (restricting production traffic to a pre-approved allowlist of queries rather than accepting arbitrary ones from any client). Skipping these defenses because a GraphQL tutorial didn't mention them is one of the more common ways a GraphQL API ships with a real vulnerability that a REST API of equivalent scope wouldn't have had by default.
The N+1 Problem Doesn't Disappear, It Moves
GraphQL's flexible querying introduces a specific, well-known performance trap on the server side: a query asking for a list of users and each user's orders looks simple from the client, but a naive resolver implementation fetches the list of users with one database call, then fetches each user's orders with a separate call per user — the same N+1 query problem that plagues poorly-written REST endpoints or ORMs, just relocated into GraphQL's resolver layer where it's easier to introduce accidentally, because each field's resolver is often written in isolation without visibility into how many times it will be called in a given request.
The standard fix is a batching and caching layer — DataLoader being the most widely used implementation — that collects all the individual lookups requested during a single GraphQL query execution and issues one batched database call instead of many, then caches results within that request so the same entity isn't fetched twice. Skipping this isn't a small oversight; it's the difference between a GraphQL API that scales and one that silently multiplies database load as query complexity grows, and it's exactly the kind of problem that doesn't show up in development with a small seed dataset but becomes a real production incident under load.
Real-Time Data: Subscriptions, Webhooks, and Polling
Neither REST nor GraphQL is inherently real-time, but each has developed a different common answer for it. GraphQL has a first-class subscriptions concept — a client opens a persistent connection (typically over WebSockets) and receives pushed updates whenever specified data changes, using the same schema and type system as regular queries. REST has no equivalent built into the architectural style itself; real-time REST-based systems typically layer on webhooks (the server pushes an HTTP request to a client-registered URL when something changes) or fall back to polling (the client just asks again on an interval).
For applications with genuine real-time requirements — live chat, collaborative editing indicators, live order status — GraphQL subscriptions offer a more integrated developer experience since they reuse the same schema and client tooling as everything else in the API. That said, subscriptions add real operational complexity of their own (maintaining persistent connections at scale, handling reconnection logic), and plenty of "real-time-ish" needs are served perfectly well by simple polling on a REST endpoint every few seconds, which is far simpler to operate and debug. It's worth sizing the actual freshness requirement honestly before reaching for the more complex option.
Tooling and Developer Experience
GraphQL's schema is strongly typed and self-documenting — tools like GraphiQL or Apollo Studio let any developer explore the entire API's shape interactively, and code generation tools can produce fully typed client code directly from the schema, which is a genuine productivity win for teams building against a GraphQL API in TypeScript. REST's documentation quality varies entirely by how much discipline the team maintaining it has put into keeping an OpenAPI/Swagger spec current — when that discipline exists, the experience is comparable; when it doesn't, REST API consumers are often reading source code or guessing at response shapes.
The flip side is initial setup cost: a basic REST endpoint is genuinely simple to stand up — a route, a handler, a response. A properly built GraphQL API needs schema design, resolver architecture, and (for anything beyond a toy project) the security defenses described above, all before the first real feature ships. For a small API with a handful of endpoints and one client, that upfront investment often isn't worth it.
A Practical Decision Framework
- Choose REST for simple CRUD-shaped APIs with one or a small number of client types, when HTTP-level caching is doing real performance work (public content, catalogs), or when the team's expertise and existing tooling already lean REST and the API's shape isn't complex enough to justify a schema investment.
- Choose GraphQL when you have multiple client types (web, iOS, Android) with meaningfully different data needs per screen, when your data model has deep, variable relationships that different screens traverse differently, or when reducing backend endpoint sprawl (one aggregation endpoint per screen) is a real, recurring pain point.
- A hybrid approach is common and legitimate — a public-facing REST API for simple, cacheable, third-party-consumed resources, alongside an internal GraphQL layer serving the product's own web and mobile clients where flexible querying pays off. There's no rule requiring an entire backend to commit to one paradigm.
The Practical Takeaway
GraphQL isn't a strictly better replacement for REST — it's a different set of trade-offs that happens to solve over-fetching and multi-client data needs very well, at the cost of a harder caching story and a real security surface that needs deliberate attention. REST remains the simpler, more battle-tested default for straightforward APIs with predictable access patterns. The teams that regret their choice are usually the ones that picked GraphQL because it was the more interesting technology to learn, not because their product had multiple client types with genuinely different data needs — or the ones that stuck rigidly to REST while building a bespoke aggregation endpoint for every new mobile screen, reinventing GraphQL's core use case one endpoint at a time.
