API Paradigms: REST vs gRPC vs GraphQL
1. REST (Representational State Transfer)
The Standard choice.
- Protocol: HTTP/1.1 (text-based).
- Data Format: JSON (typically).
- Pros: Universally supported, cacheable, stateless, human-readable.
- Cons: Over-fetching/Under-fetching of data, chatty interface.
- Best for: Public APIs, simple microservices, web clients.
2. gRPC (Remote Procedure Call)
The High-performance choice.
- Protocol: HTTP/2 (binary).
- Data Format: Protocol Buffers (Protobuf).
- Pros: Extremely fast/compact, strongly typed contracts, bi-directional streaming, code generation.
- Cons: Not human-readable, requires browser proxy (gRPC-Web) for frontend use.
- Best for: Internal microservice-to-microservice communication, high-performance systems.
3. GraphQL
The Flexible choice.
- Protocol: HTTP (usually POST).
- Data Format: JSON.
- Pros: Client requests exactly what it needs (no over-fetching), single endpoint, strong type system.
- Cons: Complex caching (POST requests), N+1 query performance issues, complexity implementation.
- Best for: Complex frontends with varying data needs, mobile apps (bandwidth constrained).
Comparison Table
| Feature | REST | gRPC | GraphQL |
|---|---|---|---|
| Transport | HTTP/1.1 | HTTP/2 | HTTP |
| Payload | JSON (Text) | Protobuf (Binary) | JSON (Text) |
| Contract | OpenAPI / Swagger | .proto file | GraphQL Schema |
| Streaming | No (Server Sent Events usually) | Yes (Bidirectional) | Subscriptions |
| Browser Support | Native | Requires Proxy | Native |
🧠 Architect’s Note
Use gRPC for the backend mesh (service-to-service) for performance. Use GraphQL for the mobile/frontend aggregation layer (BFF) to allow flexible data fetching. Use REST for public partner integrations because it’s the universal language of the web.