Skip to main content
REST vs GraphQL vs gRPClesson 4 of 4 · 2 min read

Choosing Per Boundary

Choose per boundary, not per company

Do not pick a company-wide winner. Look at each boundary and ask who is calling across it, because these three styles are tuned for three different callers.

Give strangers REST. Third-party developers turn up with an HTTP client and your docs and nothing else, and REST asks nothing more of them. Responses cache in CDNs, curl works for debugging, and decades of shared understanding sit behind it.

The companies whose entire product is an API stay on REST even with the resources to build anything they like.

Give your own frontends GraphQL, once it earns its complexity. That happens when several client teams need different slices of the same data and you are tired of shipping a bespoke endpoint per screen.

Skip it if you have one web app and three screens, where a few well-shaped REST endpoints are simply less machinery. Watch for the organisational signal instead of a technical one: your frontend teams are blocked on your backend teams for every field they want.

Give your internal services gRPC. Both ends are yours, so being human-readable and universally reachable stops mattering, and the cost of each call starts compounding. Typed contracts catch integration bugs at compile time, and streaming and deadlines are built in rather than bolted on.

They compose

Compose them rather than choosing once. A common production shape is REST or GraphQL at the edge with gRPC behind it, where the gateway answers a query by making internal calls.

Name the boundary before you name the protocol in an interview. That is the whole difference between a memorised answer and a design decision.

the shape of it
Partner devsOwn frontendsREST APIpublic edgeGraphQL gatewayfrontend edgePayments svcLedger svcRisk svcHTTPS + JSONone querygRPCgRPCgRPCgRPC
step 1 of 4
A layered setup: REST for strangers, GraphQL for your own frontends, gRPC between internal services.

Worked example

Priya is the architect at a 60-engineer fintech planning their API strategy. The debate has run for weeks as a personality contest, so she reframes it as three separate decisions. The partner-facing API that banks integrate with becomes REST, because bank IT departments integrate with curl and PDFs of documentation, and the existing v1 stays frozen for them. The mobile and web apps get a GraphQL gateway, ending the backlog of 40 screen-specific endpoint tickets. The 12 internal services, which exchange 20,000 calls per second, migrate pairwise to gRPC, starting with the two chattiest ones, where protobuf cuts inter-service bandwidth 70 percent. Nobody won the argument, which Priya considers the sign it was decided correctly: each boundary got the protocol its caller needed.

REST vs GraphQL vs gRPC: wrapping up

In the real world

  • 01GitHub kept its v3 REST API and launched its v4 API as GraphQL, publicly citing that integrators often needed two or three REST calls to assemble one view.
  • 02gRPC descends from Stubby, the RPC framework nearly all of Google's internal services have used for years, and was open-sourced in 2015 with Protocol Buffers as its contract language.
  • 03Shopify's Storefront API is GraphQL because merchant storefronts render wildly different data shapes, and its admin API rate limits by query cost rather than request count.
  • 04Netflix runs a federated GraphQL gateway for its consumer apps while backend services communicate over gRPC, exactly the layered edge-versus-interior split.
  • 05Stripe has kept its public API on REST since 2011, versioned by date-stamped releases, betting that predictability and curl-ability matter more to integrators than payload efficiency.

Questions people ask

Is GraphQL a replacement for REST?

No. GraphQL replaces the pile of screen-specific REST endpoints teams build for their own frontends, and it is strongest when several client teams need different data shapes. For public APIs consumed by third parties, REST's cacheability, simplicity, and universal tooling usually still win. Many companies run both, each at the boundary it fits.

Why not use gRPC everywhere if it is faster?

Because its costs land exactly where external callers live. Browsers need a grpc-web proxy, payloads are not debuggable with curl, and every consumer must hold your .proto files and regenerate code on changes. Inside your own fleet those costs are fine and the efficiency compounds; across a public boundary they are friction that loses you integrators.

What is the N+1 problem in GraphQL?

A query asking for a list plus a nested field, like 50 orders each with a restaurant name, naively runs one query for the list and then one per item for the nested field, 51 in total. The fix is a batching layer such as DataLoader, which collects the 50 IDs during one request and fetches them in a single query.

Quick review

REST:
resource URLs (/users/:id), HTTP verbs for semantics. Stateless, cacheable, universally supported. Best for public APIs
REST over/under-fetching:
GET /users returns all fields even if client only needs name + email. Multiple roundtrips for related data
GraphQL:
single /graphql endpoint. Client declares exact fields needed in query. Eliminates over/under-fetching
GraphQL trade-offs:
N+1 query problem (use DataLoader), complex caching (no GET requests), schema versioning overhead
gRPC:
uses Protocol Buffers (binary, ~5× smaller than JSON). HTTP/2 transport. Bidirectional streaming. Strongly typed, code generated
gRPC trade-offs:
browser support limited without grpc-web proxy. Not human-readable. Schema changes require coordination
SOAP:
XML, WSDL contracts, enterprise/banking legacy. Verbose but strict. WS-Security for enterprise auth
Decision:
REST for public APIs, GraphQL for complex multi-model frontends, gRPC for high-performance internal microservices
the trade-off

REST is the cheap default: cacheable by HTTP, debuggable with curl, understood everywhere, at the cost of over-fetching and extra round trips. GraphQL moves that cost onto the server, where you now own N+1 queries, depth limits, and the caching HTTP used to do for you. gRPC is the fastest and the least observable: binary frames, no native browser support, and a proxy in front of web clients.

in the room

REST: public-facing APIs. GraphQL: mobile apps needing bandwidth efficiency. gRPC: internal services with high RPC volume.