The REST-vs-GraphQL debate has matured. After a decade of production rollouts — and a handful of high-profile rollbacks — the choice is no longer about which protocol is "better". It is about the shape of your data, the size of your client surface, and the team that has to live with the result.
Where REST still wins
REST is the right default for most internal services and a great deal of public APIs. It is cacheable at the HTTP layer for free, observable with off-the-shelf tools, and trivially throttled at the edge. When your endpoints map cleanly to resources and your clients want predictable payloads, REST keeps the operational story simple.
We reach for REST when the data graph is shallow, when machine-to-machine consumers dominate, or when a CDN sits between your service and the world.
Where GraphQL earns its keep
GraphQL pays for its added complexity when you have many different clients reading overlapping slices of a deep data graph. A native app, a marketing site, and a partner integration can each request exactly the fields they need without us shipping a bespoke endpoint for every combination.
The schema-first contract is the second draw. Code generation across the stack — typed clients, mock servers, fixtures — collapses an entire class of integration bugs.
The hybrid pattern that has quietly taken over
Most of our recent engagements ship both. A GraphQL gateway aggregates read-heavy product surfaces from a handful of REST microservices. Writes go directly to the REST services that own the data. Cache invalidation, throttling, and authentication stay at the REST layer where the operational tooling is mature.
This pattern keeps team boundaries clean: domain teams own REST services with their own SLAs, while a small platform team owns the gateway schema.
A short decision checklist
- One internal client and a shallow graph? Use REST.
- Public API with high read fan-out? REST with sensible JSON:API conventions.
- Many clients, deep relationships, frequent UI iteration? GraphQL.
- Heterogeneous backend with a unified product surface? A GraphQL gateway over REST services.
The wrong question is "which one". The right question is "where does each one earn its complexity tax?" Answer that, and the architecture follows.