The dilemma at the start of every new project
Every time we kick off a project with an API, the same question comes up: REST or GraphQL? And every time, the honest answer is the same: it depends — but it depends on very specific things you can analyze before writing a single line of code.
The problem is that the debate is usually contaminated by fashion. GraphQL sounds modern, REST sounds boring, and decisions get made by gut feeling instead of by requirements. Let's bring some order to it.
What each one is really good at
REST: simplicity that scales organizationally
REST shines when resources are clear and stable: users, orders, invoices. Its greatest strength isn't technical, it's organizational: any developer understands a REST endpoint in seconds, HTTP caching works out of the box, monitoring and debugging tools are mature, and public documentation is almost self-explanatory.
Plus, if your API is public or consumed by third parties, REST remains the least-friction option: nobody needs to learn your schema to make the first call.
GraphQL: flexibility for complex clients
GraphQL earns its keep when clients need very different views of the same data. The classic case: a mobile app that wants three fields and a web dashboard that wants forty, both about the same entity. With REST you end up with either fat endpoints or endless requests; with GraphQL, each client asks for exactly what it needs.
It also shines when the frontend team iterates fast and doesn't want to wait for a new endpoint for every screen change.
The myths that distort the decision
"GraphQL replaces REST." No. It solves a different problem: query flexibility, not resource modeling. Many projects use GraphQL for the frontend gateway and REST underneath between services.
"REST is always simpler." Only at the beginning. With clients that need composite data, REST degenerates into ad-hoc endpoints (/users/with-orders-and-invoices) that are far worse than a well-designed schema.
"GraphQL is faster." It can reduce round trips, but it moves the complexity to the server: the N+1 problem, query cost control, and per-field caching require deliberate work. A poorly built GraphQL is slower than a mediocre REST.
How we decide on real projects
- Public API or third-party integrations → REST. Interoperability and predictability win.
- Multiple clients with divergent needs (mobile + web + partners) → GraphQL as the consumption layer.
- Small team, well-defined domain → REST. Less machinery, more product.
- Fast-moving frontend backed by a stable data model → GraphQL decouples the two teams' paces.
- Microservices communicating with each other → REST (or gRPC, or events). GraphQL between services is rarely worth the cost.
The uncomfortable truth
Most projects that "need GraphQL" actually need better-designed REST. And most projects that suffer with GraphQL chose it without the clients to justify it. The API is a contract with your own team and with your consumers: choose the contract you can honor for years, not the one that looks best in a talk.
Not sure which way to go with your API?
We've designed and audited APIs of both kinds — public, internal, and hybrid. If you're starting a project or your current API has become a bottleneck, let's talk: in one session we can map your real cases to the decision that will save you the most pain down the road.