GraphQL was pitched as a REST replacement, but the honest picture is more nuanced — each has real, situational advantages, and picking based on genuine trade-offs beats picking based on hype.
Where GraphQL Genuinely Wins
# One request gets EXACTLY the fields needed, from multiple related resources
query {
order(id: 123) {
total
customer { name email }
items { product { name } quantity }
}
}
- Eliminates over-fetching (getting fields you don’t need) and under-fetching (needing multiple round-trips to assemble related data)
- A single, strongly-typed schema serves as genuinely accurate, self-documenting API documentation
- Especially valuable for mobile clients on constrained networks, where minimizing round-trips and payload size matters a lot
Where REST Still Genuinely Wins
- HTTP caching works naturally and simply with REST’s resource-based URLs — GraphQL’s single endpoint makes standard HTTP caching much harder to leverage
- Simpler to reason about, debug, and monitor — every request maps predictably to a specific resource and method
- File uploads and simple CRUD APIs are genuinely more awkward to express well in GraphQL than in REST
A pragmatic reality: many teams that adopted GraphQL for genuinely complex, nested data needs (a client aggregating data from many services) still use plain REST for simpler internal services — treating it as a tool with real trade-offs rather than a strict upgrade path from REST.