sdlc.dev

GraphQL path · At scale · Topic 12 of 12

GraphQL, REST or gRPC?

Not started

GraphQL, REST and gRPC answer the same question, how one program asks another for data, with different trade-offs. REST models the API as resources at URLs and leans on HTTP for methods, status codes and caching. GraphQL exposes one typed graph at one endpoint and lets each client write the exact shape of the response it wants. gRPC defines remote procedures in Protocol Buffers and calls them with compact binary messages over HTTP/2. None of them is better in general; they suit different callers, and large systems often use all three.

Why it matters: Each style moves cost to a different place: REST to the number of round trips, GraphQL to the server's execution and limits, gRPC to tooling and browser support. Picking one is picking which problems you want.

  1. 1REST is resources and HTTP

    One URL per resource, HTTP methods and status codes, and caching by URL that browsers and CDNs already understand.

  2. 2GraphQL lets the client shape the response

    One endpoint, one typed schema; each screen asks for exactly what it needs in one round trip. The server must control cost and cache below the HTTP layer.

  3. 3gRPC is typed calls between services

    Methods defined in Protocol Buffers, compact binary messages over HTTP/2, generated clients and streaming. Browsers need a proxy to use it.

  4. 4Often all three

    gRPC between services, GraphQL as a backend for frontends, REST for public, cache-heavy or webhook-style APIs.

1

How it works

The explanation, with examples you can run.

Side by side

RESTGraphQLgRPC
ContractOptional (OpenAPI)Required schema, introspectableRequired .proto files
Who shapes the responseServer, per endpointClient, per queryServer, per method
Round trips for related dataOften severalUsually oneOne per call; you design the methods
HTTP cachingNatural, by URLNeeds GET plus persisted queriesNot used
ErrorsHTTP status codeserrors array, often with HTTP 200Status codes in the gRPC protocol
StreamingSSE, WebSocket alongsideSubscriptionsBuilt in, both directions
Browser supportNativeNative (it is HTTP plus JSON)Needs gRPC-Web or a proxy
Server-side riskEndpoint does known workClient chooses the work: needs cost limitsMethod does known work
EvolutionVersions or careful additionsAdd fields, deprecate, measure usageAdd fields by number, never reuse numbers

When each fits

REST is a good default for public APIs, simple CRUD, file uploads and downloads, webhooks, and anything that benefits from CDN caching. Every tool, proxy and developer understands it.

GraphQL pays off when many different clients (web, iOS, Android, partners) need different views of the same connected data, when screens combine many resources, and when the frontend changes faster than the backend. It costs you a query engine to secure: cost limits, field-level authorisation, batching to avoid N+1, and caching that lives in clients and data loaders rather than URLs.

gRPC suits internal service-to-service calls: low latency, high volume, strict typed contracts with generated clients in many languages, and streaming both ways. It is awkward for browsers and for ad hoc exploration with everyday tools.

Combining them

A common shape: services talk gRPC (or REST) to each other; a GraphQL layer, a single server or a federated graph, sits in front of them as the backend for frontends; and a small REST surface handles public, cacheable or callback endpoints. The GraphQL resolvers become thin adapters calling the services underneath, which is also where DataLoader batching turns a graph of field requests into a few efficient service calls.

2

Check yourself

3 questions. Get them all right to finish this topic.

  1. 1.A public API serves the same product catalogue to thousands of anonymous clients and must be cached at a CDN. Which style fits most easily?
  2. 2.A mobile screen needs a user, their last five orders and each order's items. Which style avoids several round trips without adding a custom endpoint?
  3. 3.Two backend services exchange millions of small messages per second inside a data centre. Which style is the usual choice?

0 of 3 right so far. Get all three to finish this topic.

Go deeper