When should you choose gRPC over REST or GraphQL?
Learn when gRPC beats REST or GraphQL: HTTP/2, protobuf, streaming and typed contracts for fast internal services versus browser-friendly public APIs.
Expected Interview Answer
Choose gRPC when you need high-performance, low-latency service-to-service communication with strongly-typed contracts and streaming, rather than public-facing browser APIs where REST or GraphQL fit better.
gRPC uses HTTP/2 and Protocol Buffers to send compact binary messages over multiplexed connections, giving low overhead, generated client/server stubs in many languages, and native bidirectional streaming. REST is simpler, cacheable and browser-friendly; GraphQL excels when clients need to shape flexible queries over aggregated data. In practice gRPC shines for internal microservices, real-time streaming and polyglot backends, while REST/GraphQL remain the default for external and web clients.
- Compact binary payloads over HTTP/2
- Strongly-typed, versioned contracts via protobuf
- Native uni- and bidirectional streaming
- Auto-generated stubs across many languages
- Lower latency for internal service calls
AI Mentor Explanation
REST is like radio commentary anyone can tune into — verbose and easy to follow. gRPC is the coded hand signals between captain and bowler: compact, agreed in advance, instantly understood, and useless to outsiders. When your fielders need fast private coordination you use signals, not a public broadcast, exactly as internal services pick gRPC over open REST.
Step-by-Step Explanation
Step 1
Map the caller
Identify whether clients are browsers/public (favor REST/GraphQL) or internal services (favor gRPC).
Step 2
Weigh performance needs
For high call volume, low latency, or streaming, gRPC's HTTP/2 + protobuf gives a real edge.
Step 3
Check the contract discipline
If you want strongly-typed, code-generated stubs across languages, gRPC's .proto files fit well.
Step 4
Assess tooling and reach
REST is universally cacheable and debuggable; gRPC-web or a gateway is needed for browsers.
Step 5
Decide per boundary
Commonly gRPC internally with a REST/GraphQL gateway at the public edge — pick per boundary, not globally.
What Interviewer Expects
- Clear tradeoffs between gRPC, REST and GraphQL
- Understanding of HTTP/2 and Protocol Buffers
- Awareness of streaming use cases
- Knowledge of browser limitations and gRPC-web
- Ability to pick per service boundary, not dogmatically
Common Mistakes
- Claiming gRPC replaces REST everywhere including browsers
- Ignoring that browsers need gRPC-web or a gateway
- Overlooking protobuf schema and versioning discipline
- Confusing gRPC's binary payload with plain JSON over HTTP
Best Answer (HR Friendly)
“gRPC is best when your own backend services need to talk to each other very fast and reliably with a strict shared format. For public websites and flexible client queries, REST or GraphQL are usually the easier, more compatible choice.”
Code Example
syntax = "proto3";
service OrderService {
rpc GetOrder(OrderRequest) returns (Order);
rpc StreamOrders(OrderQuery) returns (stream Order);
}
message OrderRequest { string id = 1; }
message OrderQuery { string customer_id = 1; }
message Order {
string id = 1;
string status = 2;
double total = 3;
}Follow-up Questions
- How does gRPC-web let browsers call gRPC services?
- What are the four gRPC streaming modes?
- How does protobuf handle backward compatibility?
- When would GraphQL be a better fit than gRPC?
- How do you expose a gRPC service through a REST gateway?
MCQ Practice
1. Which transport does gRPC use by default?
gRPC is built on HTTP/2, which provides multiplexing, header compression, and streaming.
2. Which scenario most favors gRPC over REST?
gRPC's binary payloads and HTTP/2 streaming make it ideal for high-throughput internal service-to-service traffic.
3. What serialization format does gRPC use by default?
gRPC uses Protocol Buffers, a compact strongly-typed binary format defined in .proto files.
Flash Cards
What transport underpins gRPC? — HTTP/2, enabling multiplexing, header compression and streaming.
Default gRPC serialization? — Protocol Buffers (protobuf) — compact, typed binary messages.
Best gRPC use case? — Low-latency, high-volume internal service-to-service and streaming APIs.
Why not gRPC for browsers directly? — Browsers lack raw HTTP/2 frame access; you need gRPC-web or a gateway.