The honest comparison nobody asked for but everyone needs.
REST: The Default That's Fine
REST works. It's been working since 2000. Every developer knows it. Every tool supports it. Every proxy, cache, CDN, and load balancer understands HTTP verbs and status codes.
Choose REST when: Your API serves multiple clients with straightforward CRUD operations. Your team is small or mixed-experience. You need HTTP caching. You want the broadest tooling ecosystem.
REST hurts when: Mobile clients need 6 endpoints to render one screen (over-fetching). Different clients need different fields from the same resource (under-fetching/over-fetching). Your API surface is large and documentation gets stale.
GraphQL: The Flexible One
GraphQL lets clients ask for exactly the data they need in a single request. No more over-fetching. No more calling 6 endpoints to build a screen.
Choose GraphQL when: You have multiple client types (web, mobile, third-party) that need different data shapes. Frontend teams want to iterate without waiting for backend API changes. Your data model is a graph with complex relationships.
GraphQL hurts when: You underestimate the complexity. Query cost analysis (preventing clients from requesting deeply nested, expensive queries) is a whole discipline. Caching is harder because every query can be unique — no URL to cache against. N+1 query problems move from the client to the server-side resolver layer, and DataLoader only helps if you implement it correctly.
The security surface is also larger. A careless schema can let clients request your entire database through nested relationships. Rate limiting by query complexity (not just request count) is essential and non-trivial.
gRPC: The Fast One
gRPC uses Protocol Buffers (binary serialization) and HTTP/2 (multiplexed streams). It's faster than JSON over REST by a significant margin: smaller payloads, faster serialization, bidirectional streaming.
Choose gRPC when: Service-to-service communication where latency matters. Streaming use cases (real-time data feeds, long-running operations). You control both ends of the connection and can generate typed clients from proto files.
gRPC hurts when: You need browser support (gRPC-Web exists but adds complexity). Your clients are third-party developers who expect a REST API. Debugging is harder because binary payloads aren't human-readable. Load balancers need HTTP/2 support.
The Real Answer
Most teams should default to REST for external APIs and consider gRPC for internal service-to-service calls. GraphQL makes sense when your frontend team is spending more time waiting for API changes than building features.
The worst decision is choosing a technology because it's interesting. gRPC is fascinating. GraphQL is elegant. REST is boring. Boring wins when you're paged at 3 AM and need to debug a failed request by reading the URL.
Over to You
REST, GraphQL, or gRPC — what's your default choice in 2026 and why? Anyone running all three in the same platform?
If you enjoyed this, I write about production engineering, AI systems, and the messy reality of building software at scale.
Follow me:
This is part of the **Great Stack to Doesn't Work* series — a survival guide for when everything goes wrong in production. Follow the series to catch every episode.*
Top comments (0)