When to Use GraphQL

Good fits and poor fits

GraphQL shines for client-driven applications with many screens and devices that need different slices of related data, for aggregating several backend services behind one API (a backend-for-frontend), and where a strongly typed contract between teams helps. Trade-offs: HTTP caching is harder than with resource URLs, arbitrary queries need cost controls, file uploads and streaming need extra conventions, and simple CRUD services or public APIs consumed by many unknown clients may be easier with REST or gRPC.

Choosing an API style

Rules of thumb.

many client screens, nested related data, fast UI iteration   -> GraphQL
simple resource CRUD, heavy HTTP/CDN caching, public API       -> REST
high-performance service-to-service calls, streaming           -> gRPC
events between services                                        -> messaging (Kafka, queues)

GraphQL can sit in front of REST

Resolvers can call existing REST services, so adopting GraphQL does not require rewriting backends.

Quick check: Which is a common trade-off of GraphQL?

• It only works with SQL databases
• It cannot return nested data
• It has no type system
• HTTP caching is harder than with resource-oriented URLs