REST vs GraphQL: the real cost of each
· 7 min
The REST vs GraphQL debate usually revolves around developer ergonomics, but the performance trade-offs on both sides are concrete and often underestimated.
The problem GraphQL actually solves
REST suffers from over-fetching and under-fetching: fixed response shapes per endpoint force clients to either receive fields they don't need, or make several round trips to assemble what they do. GraphQL fixes exactly that, letting the client pick the fields per request.
The price: client-controlled N+1
A GraphQL query can request nested relations to any depth, and unless the server's resolvers are batched (with something like DataLoader), each nested field can trigger its own query per item from the level above, the same N+1 problem ORMs already have, except now the shape of the query (and therefore which fanout it triggers) is decided by the client on every request, which is much harder to predict and cache on the server.
HTTP caching gets harder
REST leans on HTTP-level caching (GET plus the URL as the cache key, CDN-friendly), which doesn't translate directly to GraphQL, since most GraphQL traffic is POST with a query body. Caching requires either persisted queries or an application-level cache keyed by the resolved query plus its variables.
How to balance it in practice
GraphQL's cost is manageable with resolver batching, query depth/complexity limits to stop pathological nested queries, and persisted queries to regain cacheability, but none of that is free, it's engineering work REST doesn't require by default.