The API design conversation has stopped being “REST vs. GraphQL” as if you have to pick one for your whole system, and that’s a genuine improvement - the honest answer for most real applications now involves multiple API styles, each doing the specific job it’s good at, rather than one paradigm forced onto every use case.
What each one is actually good at, specifically
REST remains the right default for straightforward resource-based APIs - public APIs consumed by many different, unpredictable clients, simple CRUD operations, anything where caching at the HTTP layer (a genuine REST strength) matters. Its simplicity and universal tooling support are real advantages that shouldn’t be dismissed just because newer options exist.
GraphQL earns its complexity specifically when clients have genuinely varied data needs - a mobile app and a web dashboard needing different shapes of the same underlying data, or a frontend team that needs to iterate on data requirements without waiting on backend endpoint changes for every new field they need. Its single-endpoint, client-specified-query model solves real over-fetching and under-fetching problems that plague REST APIs serving multiple diverse clients.
gRPC is the right tool when you need genuinely high-performance, low-latency communication - service-to-service calls within your own infrastructure, particularly at high volume, where its binary protocol and strict typing meaningfully outperform JSON-over-HTTP. It’s a poor fit for public-facing APIs or browser clients, where its tooling and compatibility story is weaker.
Where we actually see teams get this wrong
The most common mistake: adopting GraphQL for a public API with simple, uniform client needs, purely because it’s the more discussed, “modern” option - and inheriting real complexity (query complexity limits, N+1 query problems, more complex caching) without a corresponding benefit, because the actual problem GraphQL solves (varied client data needs) was never present. The second most common: using gRPC for a public-facing API and fighting its weaker browser support and less mature public tooling, when REST would have been simpler and served the actual use case just as well.
The pattern we actually build most often
For a typical modern application: REST or GraphQL for the client-facing API (chosen based on how varied client data needs actually are, not by default), and gRPC specifically for internal, high-volume service-to-service communication where its performance characteristics genuinely matter. Treating this as one architecture-wide choice rather than a per-boundary decision is the root of most of the “which one should we use” debates that don’t actually have a single right answer.
What we actually ask before recommending an API style
- Who consumes this API, and how varied are their data needs? Uniform needs favor REST; genuinely varied needs favor GraphQL.
- Is this internal service-to-service traffic where raw performance matters, or public/browser-facing traffic where broad compatibility matters? The former favors gRPC; the latter rules it out.
- What does your team already know well? Adopting a new API paradigm has a real learning curve cost that should be weighed against the specific technical benefit it provides for your actual use case.
We architect API layers as part of our API development work, matching the style to the actual client and performance requirements rather than a default preference. Talk to us about your specific API needs before committing to one paradigm system-wide.