GraphQL vs. REST vs. gRPC in 2025: An Engineer's Honest Assessment

Every few months, a blog post claims that GraphQL killed REST, or that gRPC is the future of all APIs, or that REST's simplicity makes everything else overengineered. These posts are advocacy, not engineering. Each of these protocols exists because it solves a specific class of problem better than the others. The engineering question is: which class of problem are you solving?

REST: The Correct Default

REST is not boring — it is appropriate. For the majority of API use cases, REST is the right choice not despite its constraints but because of them.

HTTP's caching semantics are REST's underappreciated superpower. A GET /products/123 response with Cache-Control: public, max-age=3600 is served by a CDN for an hour, generating zero load on your origin server for that resource. This is not possible with GraphQL's default POST-based transport, and it is irrelevant to gRPC (which operates outside the browser's native HTTP cache).

REST's stateless, resource-oriented design also maps cleanly to standard infrastructure tooling: load balancers, API gateways, rate limiters, logging systems — all operate on HTTP requests natively. Adding a Nginx proxy, Kong plugin, or Cloudflare rule in front of a REST API requires no special configuration.

Where REST genuinely struggles:

Over-fetching and under-fetching. A mobile client that needs only {id, name, thumbnail} from a /users/{id} endpoint that returns 40 fields is wasting bandwidth. A client that needs user, posts, and comments must make three sequential requests (or requires a non-standard include parameter mechanism). This is the real problem GraphQL solves.

Fan-out N+1 queries from the client. A product listing page that needs to show each product's inventory status, price override, and review count requires either a bespoke /products/summary endpoint (tight coupling between frontend needs and API design) or multiple parallel requests (latency and complexity on the client side).

GraphQL: Solving the Right Problem Badly

GraphQL solves the over-fetching and under-fetching problem elegantly. A single query can fetch precisely the fields needed across multiple related entities, with the server handling the join logic. This is genuinely valuable in two scenarios:

BFF pattern (Backend for Frontend). When you have multiple clients (web, iOS, Android, partner integrations) with divergent data requirements, a GraphQL layer in front of your services lets each client retrieve exactly what it needs without requiring separate endpoint versions. The BFF GraphQL layer aggregates from internal REST or gRPC services.

Rapid product iteration. When frontend teams are iterating quickly on data requirements and you want to avoid the coordination overhead of defining new REST endpoints for every UI change, GraphQL gives frontend teams autonomous control over their data requirements within the defined schema.

Where GraphQL creates problems:

HTTP caching becomes your problem. The canonical GraphQL transport sends queries as HTTP POST requests, which are not cacheable by standard HTTP infrastructure. You must implement application-layer caching (persisted queries + CDN rules, Apollo Server's response caching, or DataLoader for query-level memoization). This is solvable but requires deliberate engineering that REST gets for free.

N+1 database queries at the server. The canonical failure mode: a GraphQL query for a list of posts with each post's author results in 1 query for posts + N queries for authors (one per post). DataLoader (or its equivalents) solves this with batching and per-request memoization, but it requires explicit implementation for every relationship resolver.

Authorization complexity. REST authorization is typically coarse-grained at the route level (this endpoint requires admin role). GraphQL field-level authorization requires implementing authorization logic in every resolver — or using a policy engine (OPA, or library-based field directives) that makes authorization declarative but adds significant configuration overhead.

Operational overhead. GraphQL servers are stateful in a way REST servers are not. Query depth limiting, complexity analysis, persisted query allowlists, and schema change management are all operational concerns with no REST equivalent. For small teams and simple schemas, this overhead is disproportionate.

1# The pattern that makes GraphQL worth it — one request, precise data
2query DashboardData($userId: ID!) {
3  user(id: $userId) {
4    name
5    email
6    recentOrders(limit: 5) {
7      id
8      total
9      status
10      items {
11        productName
12        quantity
13      }
14    }
15    recommendations(limit: 3) {
16      product { id name thumbnailUrl price }
17    }
18  }
19}

This query — and the REST alternative (5+ requests or a bespoke aggregate endpoint) — is the argument for GraphQL in one concrete example. Whether that argument applies to your system depends on how often this pattern occurs.

gRPC: Internal Services, Not External APIs

gRPC is not competing with REST for external API use cases. It is optimized for a fundamentally different context: internal service-to-service communication in a polyglot microservices environment.

Protobuf binary serialization produces payloads 5–10× smaller than equivalent JSON and serializes/deserializes 6–10× faster. At high throughput (thousands of RPC calls per second between services), this difference is material to both latency and infrastructure cost.

HTTP/2 multiplexing eliminates head-of-line blocking. Multiple gRPC streams share a single connection, each independently flow-controlled. In a service mesh with thousands of concurrent inter-service calls, the connection efficiency advantage over HTTP/1.1 REST is significant.

Strongly typed code generation from .proto IDL files means client and server stubs are always in sync. Adding a field to a proto is backward-compatible; removing a field can be done safely following the deprecation rules. Breaking changes fail at compile time.

1syntax = "proto3";
2
3service OrderService {
4  rpc CreateOrder (CreateOrderRequest) returns (Order);
5  rpc StreamOrderUpdates (OrderFilter) returns (stream OrderUpdate);
6  rpc BatchGetOrders (BatchGetOrdersRequest) returns (BatchGetOrdersResponse);
7}
8
9message Order {
10  string id = 1;
11  string user_id = 2;
12  int64 total_cents = 3;
13  OrderStatus status = 4;
14  repeated OrderItem items = 5;
15}

Bidirectional streaming is gRPC's unique capability. A single long-lived stream can carry messages in both directions simultaneously, making it the natural fit for real-time telemetry, ML inference streaming, and live dashboard data — use cases that would require WebSockets or SSE with REST/GraphQL.

The limitations of gRPC for external APIs:

• Browsers cannot make gRPC calls directly without a proxy (grpc-web adds overhead and loses some streaming semantics)
• Debug tooling requires protobuf awareness — you cannot curl a gRPC endpoint and read the response
• Partner and third-party integrations expect REST or GraphQL; gRPC creates an integration burden on external consumers
• Managed API gateway products have more mature REST/GraphQL support

The Production Pattern

The most defensible architecture for a system with both external users and internal services:

External boundary: REST with OpenAPI for public/partner APIs. GraphQL for customer-facing frontends where client flexibility justifies the overhead (or REST with BFF endpoints if the team is small and GraphQL complexity is not worth it).

Internal boundary: gRPC for service-to-service calls that are performance-sensitive, high-throughput, or where streaming semantics are needed. REST for low-throughput internal calls where simplicity and debuggability outweigh performance.

Gateway: A single API gateway (Kong, AWS API Gateway, Nginx) translates between external protocol expectations and internal transport. External REST or GraphQL → internal gRPC transcoding is a solved problem with gRPC-gateway and Apollo Federation.

The decision is not philosophical. It follows from the constraints of your consumers (can they use gRPC?), the nature of your data (does it benefit from flexible querying?), and your caching requirements (does HTTP-native caching provide value?). Answer those questions and the protocol choice follows.