gRPC vs REST/JSON & GraphQL — When to Choose What
There is no universal winner. Choose gRPC for internal typed service meshes and streaming; REST/JSON for public, cacheable, browser-native HTTP; GraphQL when many clients need flexible graphs of data from a BFF. Honest senior answers include when REST wins — not only when binary RPC looks faster on a whiteboard.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
Who calls this API?
Prefer
Pick the surface the caller can actually use
Browser or public partners → REST/JSON, or GraphQL BFF if UI shapes diverge. Internal services that need streaming or strict stubs → gRPC. GraphQL in front does not replace gRPC between leaves.
- REST wins on docs, CDN GET caches, curl, and OAuth browser flows.
- gRPC wins on polyglot .proto, bidi, buf breaking checks, mTLS HTTP/2 meshes.
- Connect/Twirp: Protobuf contracts over plain HTTP — sibling, not enemy.
Alternative
gRPC everywhere because binary is faster
Serialization helps; architecture dominates. Partners cannot curl it. CDNs cannot cache RPC verbs. Browsers need grpc-web or a gateway you forgot to budget.
- REST can stream (SSE / chunked / WebSocket). GraphQL is usually a BFF facade.
- Protobuf JSON mapping exists — it is not the default strength.
- Idempotent public POST still needs keys — idempotency cluster, pointer only.
Decision order interviewers like
Who calls it, then UI flexibility, then streaming/stubs. REST remains a valid internal choice.
- 1
Who calls this API?
Browser, public partners, or internal services. - 2
Browser or partners?
Yes → GraphQL BFF if flexible UI queries, else REST/JSON + OpenAPI. - 3
Internal only?
Need streaming or strict stubs → gRPC + Protobuf. - 4
Otherwise REST is OK
Pick simplicity. Hybrid gateways are allowed.
Overview
There is no universal winner. Choose gRPC for internal typed service meshes and streaming; REST/JSON for public, cacheable, browser-native HTTP; GraphQL when many clients need flexible graphs of data from a BFF.
Honest senior answers include when REST wins — not only when binary RPC looks faster on a whiteboard.
Decision matrix
| Concern | gRPC | REST/JSON | GraphQL |
|---|---|---|---|
| Browser clients | Needs grpc-web / gateway | Native | Native (HTTP) |
| Public partner APIs | Rare | Default | Sometimes |
| Internal mesh | Excellent | Fine | Unusual |
| Streaming | First-class | SSE / WS / chunked | Subscriptions (ops heavy) |
| Mobile bandwidth | Compact binary | Larger text | Can over-fetch without care |
| Human debuggability | grpcurl / reflection | curl / browser | GraphiQL |
| Caching | Harder (RPC verbs) | HTTP GET caches | Complex (persisted queries) |
| Tooling ecosystem | Stubs + buf | OpenAPI huge | Schema + clients |
| Contract evolution | Field numbers | Versioning / additive JSON | Schema + deprecate |
Flow
- 1
1 Who calls this API?
- next2 Browser or public partners?
- 2
2 Browser or public partners?
- next3 Flexible UI → GraphQL BFF
- 3
3 Flexible UI → GraphQL BFF
- next4 Else → REST/JSON + OpenAPI
- 4
4 Else → REST/JSON + OpenAPI
- next5 Internal stream/stubs → gRPC
- 5
5 Internal stream/stubs → gRPC
- next6 Else REST still OK
- 6
6 Else REST still OK
Lesson map
gRPC vs REST/JSON & GraphQL — When to Choose What
There is no universal winner. Choose gRPC for internal typed service meshes and streaming; REST/JSON for public, cacheable, browser-native HTTP; GraphQL when many clients need flexible graphs of data from a BFF. Honest senior answers include when REST wins — not only when binary RPC looks faster on a whiteboard.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB a["1 Who calls this API?"] b["2 Browser or public partners?"] c["3 Flexible UI → GraphQL BFF"] d["4 Else → REST/JSON + OpenAPI"] a -->|1 Who calls this API?| b b -->|2 Browser or public partners?| c c -->|3 Flexible UI → GraphQL BFF| d
When REST wins (be honest)
- Public documentation and partner onboarding.
- CDN-friendly read paths (
GET+ cache headers). - Teams live in curl, browser DevTools, and API gateways.
- File downloads / standard OAuth browser flows.
REST naming and versioning still apply at the public edge: API Design.
When gRPC wins
- Polyglot microservices with shared
.proto. - Bidirectional or server streaming.
- Strict compatibility via field numbers + buf breaking checks.
- mTLS mesh already HTTP/2 everywhere.
When GraphQL wins
- One BFF serving web + mobile with divergent screens.
- Aggregating many backend calls behind one query.
- Strong schema + persisted queries for production.
GraphQL is not a replacement for gRPC between leaf services — often GraphQL BFF calls gRPC/REST backends.
Hybrid patterns
| Pattern | Role |
|---|---|
| grpc-web via Envoy | Browser → gRPC services |
| REST gateway from protos | Public edge + internal gRPC |
| GraphQL BFF → gRPC | Flexible queries over typed mesh |
| Connect / Twirp | Protobuf contracts over plain HTTP/1.1+JSON option |
Comparative myths
| Myth | Reality |
|---|---|
| gRPC is always faster | Serialization helps; architecture dominates |
| REST cannot stream | SSE/chunked/WebSocket exist |
| GraphQL replaces backends | It is usually a BFF facade |
| Protobuf cannot do JSON | JSON mapping exists; not the default strength |
Sandbox: tiny decision helper (Python)
Interview toy — not a platform standard. Prefer GraphQL BFF when UI queries flex; REST when browsers/partners show up; gRPC when internal streaming or stubs dominate.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Same matrix (TypeScript)
Press Run. Snippets must be self-contained — no network, files, or native modules.
Pitfalls
Public partner catalog, internal ledger, mobile app with 12 screens. What sits at each edge? Where does the BFF stop and gRPC start?
Interview Q&A
Default for a public SaaS API in 2026?
Answer
REST/JSON + OpenAPI unless you have a strong reason otherwise.
Internal payments ledger service-to-service?
Answer
gRPC (or similar IDL) for contracts + deadlines + metrics uniformity.
Mobile app with many screens and one backend team?
Answer
GraphQL BFF or well-designed REST; leaf services may still be gRPC.
Does GraphQL need a different auth model?
Answer
Often same OAuth/OIDC at the BFF; authorize fields carefully to avoid over-exposure.
How do you expose gRPC to browsers?
Answer
grpc-web proxy, or generate a REST/JSON gateway from the same protos.
Caching GraphQL?
Answer
Harder than REST GET — use persisted queries, CDN carefully, cache at BFF/data layer.
Is Connect/Twirp a competitor?
Answer
Sibling idea: Protobuf contracts with simpler HTTP — good compromise cultures.
How does this relate to API Design cluster?
Answer
REST naming/versioning still apply at the public edge even if internals are gRPC. See API Design — do not recap /getUser here.