GraphQL vs REST: When Each Makes Sense

The GraphQL vs REST debate generates more heat than light. Both are tools with tradeoffs, and the right choice depends on your specific context. Here's what I've learned from building production APIs with both.

REST's greatest strength is simplicity. A GET to /api/articles returns articles. A POST to /api/articles creates one. The HTTP semantics (methods, status codes, caching headers) are well-understood by every developer and every piece of infrastructure. Load balancers, CDNs, and API gateways all understand REST natively.

GraphQL's greatest strength is query flexibility. The client specifies exactly what data it needs. A mobile app fetching a user profile might request name, avatar, and recent posts in a single query. A web dashboard might request name, email, role, permissions, and activity log. Same schema, different queries, no endpoint proliferation.

The N+1 problem exists in both, but manifests differently. In REST, the N+1 problem is the client making N+1 API calls (fetch articles, then fetch author for each). In GraphQL, the N+1 problem is the server making N+1 database queries (resolve articles, then resolve author for each). DataLoader solves this in GraphQL by batching and caching database queries within a single request.

Caching is where REST has a clear advantage. HTTP caching headers (Cache-Control, ETag) work out of the box. CDNs cache REST responses transparently. GraphQL responses are POST requests to a single endpoint, which HTTP caches can't meaningfully cache. Client-side caching in GraphQL (Apollo Client, urql) is powerful but requires more setup.

Schema design in GraphQL requires discipline. The flexibility that makes GraphQL powerful also makes it easy to create expensive queries. A malicious or naive client could request deeply nested data that generates hundreds of database queries. Rate limiting, query complexity analysis, and depth limiting are essential safeguards.

For backend-for-frontend patterns, where your API serves a specific frontend you control. REST is usually simpler. You know exactly what data each page needs. Custom endpoints that return exactly that data are straightforward to build and cache. GraphQL's flexibility is less valuable when you control both sides.

Where GraphQL shines: public APIs consumed by diverse clients, applications with complex data relationships, and teams where frontend and backend iterate independently. GitHub's API v4 is GraphQL because their API serves thousands of different applications, each needing different data shapes.

My default: REST for most applications, especially those serving a single frontend. GraphQL when the client diversity or data complexity justifies the additional tooling and operational overhead. And increasingly, tRPC for TypeScript full-stack applications where end-to-end type safety eliminates the need for a formal API layer entirely.