GraphQL vs REST: What Changed My Mind After Real Client Projects

GraphQL's whiteboard pitch — one endpoint, ask for exactly the fields you need, no over-fetching — is genuinely compelling, and I went into early projects expecting it to be a clear upgrade over REST everywhere. Real client work narrowed that belief considerably.

• Multiple frontends (web, mobile, partner integrations) with genuinely different data needs → GraphQL earns its complexity here.
• One frontend, one backend, predictable data shapes → REST is simpler to cache, simpler to debug, simpler to secure.
• N+1 query problems don't disappear with GraphQL — they move into resolvers, and DataLoader-style batching becomes mandatory, not optional.
• Caching a GraphQL response at the CDN layer is genuinely harder than caching a REST endpoint by URL.

The projects where GraphQL paid off had multiple real consumers with different needs. The projects where it added ceremony had one frontend and would have shipped faster, with simpler caching, on plain REST.

GraphQL solves a fan-out problem. If you don't have multiple different consumers, you don't have that problem yet.