REST vs GraphQL vs gRPC
Three very different API styles, optimised for three very different problems. Here is how they compare on performance, schemas, real-time, tooling, and browser support.
Feature Comparison
| Feature | REST | GraphQL | gRPC |
|---|---|---|---|
| Format | JSON over HTTP | JSON over HTTP POST | Protobuf over HTTP/2 |
| Performance | Good | Good | Excellent — binary + multiplexed |
| Schema | Optional (OpenAPI) | Strict schema | Strict .proto |
| Over-fetching | Yes | No — you pick fields | No |
| Under-fetching | Often needs N+1 calls | Single query | Multiple RPCs OK with HTTP/2 |
| Tooling | Mature — Postman, Insomnia | Apollo, GraphiQL | grpcurl, BloomRPC |
| Real-time | Polling | Subscriptions via WebSocket | Bidirectional streaming native |
| Browser support | Native | Native | Needs grpc-web proxy |
| Caching | HTTP caching excellent | Hard | Hard |
| Best for | Public APIs | Complex client needs | Internal microservices |
Capability Chart
Verdict
Choose REST when:
- Building a public API where caching and simplicity matter
- Resource-oriented data model fits cleanly onto HTTP verbs
- Third-party integrators expect JSON + OpenAPI
- You want CDN caching and HTTP semantics for free
Choose GraphQL when:
- Multiple clients (mobile, web, TV) need different fields
- You want to avoid N+1 round trips for nested data
- Schema-first development with generated TS types
- Subscriptions for real-time updates to many clients
Choose gRPC when:
- Internal service-to-service communication at scale
- Low latency + high throughput are non-negotiable
- Strong typing across polyglot backends via .proto
- Bidirectional streaming use cases (chat, telemetry)
Frequently Asked Questions
When should I use REST vs GraphQL vs gRPC?
REST for public APIs and cache-heavy reads — HTTP semantics work for free. GraphQL when clients (especially mobile) need flexible field selection and over-fetching is a real cost. gRPC for internal service-to-service traffic where latency matters and you control both ends — Protobuf + HTTP/2 is the fastest binary option.
Is GraphQL better than REST for mobile apps?
Usually yes — mobile apps benefit most from GraphQL because (a) bandwidth is metered, (b) screens have varying data needs, (c) one round trip beats N. REST can match GraphQL with field-selection conventions, but at the cost of bespoke endpoints. GraphQL pushes that flexibility into the protocol.
Is gRPC faster than REST and GraphQL?
Yes — gRPC with HTTP/2 + Protobuf is typically 5–10× faster than JSON-over-HTTP/1.1 REST for service-to-service calls, due to binary encoding, multiplexing, and bidirectional streaming. The gap shrinks vs HTTP/2 REST + compression, but gRPC stays ahead on serialization cost and streaming patterns.
Can I use gRPC in the browser?
Not directly — browsers cannot use raw gRPC. gRPC-Web is a workaround (proxy-based), but it loses bidirectional streaming. For browser-facing APIs, REST or GraphQL are still the right picks; reserve gRPC for backend service mesh communication.