- rtshkmr's digital garden/
- References/
- Architecture Design Basics/
- Pattern Taxonomy/
- Encoding & Data Formats/
- Protocol Choices/
Protocol Choices
··
283 words·
2 mins
Table of Contents
🔴 P0 — REST vs gRPC vs GraphQL is a standard interview question
Problem #
How should services communicate? The protocol choice affects latency, developer experience, streaming capability, and tooling ecosystem.
Mechanism #
| Dimension | REST | gRPC | GraphQL |
|---|---|---|---|
| Transport | HTTP/1.1 or HTTP/2 | HTTP/2 (required) | HTTP (any) |
| Payload | JSON (typically) | Protobuf (binary) | JSON |
| Contract | OpenAPI (optional) | .proto (required) | Schema (required) |
| Streaming | Not native (workarounds) | Bi-directional native | Subscriptions (over WS) |
| Browser support | Native | Needs proxy (gRPC-Web) | Native |
| Caching | HTTP caching built-in | No standard caching | Complex (query-dependent) |
| Code generation | Optional | Built-in (protoc) | Built-in (codegen tools) |
| Learning curve | Low | Medium | Medium-High |
Key Trade-offs #
REST: Universal but verbose #
- Strength: Every language, framework, and tool speaks HTTP+JSON. Caching is built into the protocol (ETags, Cache-Control). Debugging with curl/Postman is trivial.
- Weakness: Over-fetching (get entire resource when you need one field), no streaming, no built-in schema evolution.
gRPC: Fast but opaque #
- Strength: Binary serialisation (~10× smaller), HTTP/2 multiplexing, bi-directional streaming, strong schema evolution via Protobuf.
- Weakness: Browser incompatibility, binary payloads hard to debug, requires proto toolchain, no built-in HTTP caching.
GraphQL: Flexible but complex #
- Strength: Client specifies exactly what it needs (no over-fetching), strong typing, introspection.
- Weakness: N+1 query problem on the server, complex caching, difficult rate limiting (every query is unique), security surface area (malicious queries).
Instinct #
Instinct framing: “I’d use gRPC for service-to-service communication where we control both ends and need performance or streaming. REST for public APIs where developer experience and HTTP caching matter. GraphQL only for specific client-facing use cases where over-fetching is a real, measured problem — not as a default.”
References #
- Understanding gRPC, OpenAPI and REST — Google Cloud
- GraphQL Best Practices
DDIA 2e Reference #
- Chapter 4: RPC and message-passing dataflow