GraphQL vs REST is no longer the religious war it was in 2018. Both approaches have matured, the trade-offs are well-understood, and most experienced teams reach for whichever fits the specific problem rather than committing dogmatically to one. The question is not which is better; it is which is better for this specific API serving these specific clients. Here is the decision framework that holds up in production.
Table of Contents
REST Wins for Public APIs
Public APIs benefit from REST’s universal tooling, predictable caching, and simpler authentication patterns. Every HTTP client speaks REST natively. CDNs cache GET requests for free. OpenAPI tooling generates SDKs in dozens of languages.
GraphQL public APIs exist (GitHub, Shopify) but require client developers to learn GraphQL and your specific schema. For most public APIs, REST + OpenAPI gets you broader adoption with less developer onboarding friction. The OpenAPI specification documentation is the canonical reference.
GraphQL Wins for Mobile Clients
Mobile apps care about payload size and request count. GraphQL lets the client request exactly what it needs in one round-trip, even if the data spans multiple backend services. REST typically requires multiple requests or always-large responses.
Apps like Facebook (where GraphQL was born), Twitter, Airbnb use GraphQL for mobile precisely because of this fit. For a mobile-heavy product, GraphQL’s over-fetching prevention is genuinely valuable. See our API design best practices for related patterns that apply to both.
REST Caching Is Free; GraphQL Caching Is Work
GET requests cache trivially in browsers, CDNs, and reverse proxies based on URL. GraphQL queries are POST requests by default with the query in the body — none of that caching machinery works.
GraphQL caching requires either persisted queries (preregister query hashes), automatic persisted queries (APQ), or specialized caching layers (Apollo Server caching, GraphCDN). All work but add operational complexity. For read-heavy public-facing APIs, this is a meaningful cost.
tRPC Is the Third Option
For internal APIs where client and server share a TypeScript codebase, tRPC eliminates both REST schema files and GraphQL schemas. You define functions on the server, call them from the client with full type inference. No code generation step.
This is the right answer for many internal apps that would have used GraphQL purely for the type safety. tRPC has limits (TypeScript-only, less suitable for public APIs) but within them it is dramatically simpler. Combine with React Server Components patterns for the modern type-safe full-stack TypeScript story.
REST Is Easier to Operate
Logging, monitoring, rate limiting, and debugging are all easier with REST. A 500 error from `/api/users/123` is immediately diagnosable. A GraphQL POST to `/graphql` requires inspecting the operation name and query body before you know what happened.
GraphQL needs better tooling investment (Apollo Studio, Hasura monitoring, Datadog GraphQL integrations) to match REST’s operational simplicity. The Apollo GraphQL observability writeup covers the patterns. Budget time for it if you go GraphQL.
Wrap Up
GraphQL vs REST is a choice to make per API based on clients, scale, and team. REST for public APIs and read-heavy workloads where caching matters. GraphQL for mobile and internal product APIs where flexibility matters more. tRPC for internal TypeScript-everywhere stacks. Most large companies use multiple approaches rather than picking one. The teams making the worst decisions are the ones following dogma rather than analysis. Combine your choice with observability practices appropriate to that protocol.
Frequently Asked Questions
Can I use GraphQL on top of REST APIs?
Yes — schema stitching or GraphQL gateways (Apollo Federation, GraphQL Mesh) compose multiple REST/GraphQL services into a single GraphQL schema. Useful for migrations or BFF patterns.
Does GraphQL have N+1 query problems?
Yes, by default. DataLoader (the Facebook-originated batching library) is the standard solution. Every GraphQL backend should use it for resolvers that hit databases.
What about gRPC?
gRPC for internal service-to-service with strong typing, low latency, and streaming. Not great for browser clients (gRPC-Web exists but is awkward). REST/GraphQL for client-facing, gRPC for backend-to-backend is a common pattern.
Should new APIs always use OpenAPI?
Yes for any REST API. OpenAPI 3.1+ enables SDK generation, contract testing, and documentation from a single source. The marginal cost is small; the benefits compound.
Is REST actually RESTful in most APIs?
Almost no real-world REST API is fully RESTful (HATEOAS, hypermedia). Most are HTTP-JSON APIs with REST conventions. That is fine — the strict definition is rarely worth the complexity.
