GraphQL vs REST: who picks the shape of the data?

REST models your API as a set of resources, each at its own URL (/users/42, /users/42/posts), and the server decides what fields each endpoint returns. GraphQL exposes a single endpoint (/graphql) and a type schema, and the client writes a query saying exactly which fields of which resources it wants — the server assembles precisely that shape in one response.

These aren't mutually exclusive. A very common production shape is REST (or gRPC) between internal services — where simple, cacheable, independently-deployed endpoints shine — with a GraphQL gateway in front, aggregating those services into one client-facing schema so the web and mobile apps get exactly-shaped data in a single round trip. The clients get GraphQL's ergonomics; the backend keeps REST's simplicity and caching. You don't have to pick one for the whole system.

GraphQL's flexibility has two costs the tutorials skip. First, caching: REST rides on HTTP, so a GET /users/42 is cached for free by the browser, the CDN and any proxy in between. GraphQL sends every query as a POST to one URL, so that entire layer of free caching evaporates — you rebuild it in the application with persisted queries, a normalized client cache (Apollo, urql), and server-side response caching keyed on the query, not the URL.

Second, the N+1 problem: a query for 50 posts, each with its author, can trigger a naive resolver to run 1 query for the posts and then 50 more for the authors — 51 database hits for one request. The fix is DataLoader, which batches every author lookup in a single tick into one IN (...) query and caches results per request. It's a solved problem — but it's a problem you have to know exists, whereas REST's fixed endpoints rarely surprise you this way.

A public weather API — GET /forecast?city=London — is a textbook REST case: the resource is simple, the response shape is stable, thousands of clients want the same data, and CDN caching a popular city's forecast for a few minutes is a massive, free win. Wrapping that in GraphQL would add a schema, resolvers and a caching headache to solve a problem REST already handles perfectly.

A social app's home feed is the opposite. One screen needs the current user, their feed of posts, each post's author, like count, top comments and each commenter's avatar — five or six related resources, nested, and the iOS app wants slightly different fields than the web app. In REST that's a waterfall of calls or a bespoke /feed endpoint you re-cut every time the design changes. In GraphQL it's one query per client, each asking for exactly its fields — with DataLoader batching the author and comment lookups so "one query" doesn't quietly become N+1 behind the scenes.