When would you use gRPC instead of REST?
Use gRPC for fast, strongly typed communication between internal services and for streaming. It uses HTTP/2 and Protocol Buffers, which are compact and quick, but browsers and public clients find REST easier.
Explain it simply
REST usually sends JSON over HTTP/1.1, which is readable but verbose. gRPC sends binary Protocol Buffers over HTTP/2.
Why teams pick gRPC for internal calls:
- Smaller and faster: binary messages are compact and quick to parse.
- Strict contract: you define services and messages in a .proto file, and client and server code is generated in many languages, so mismatches are caught at build time.
- Streaming: server, client or bidirectional streams are built in, useful for live updates.
- HTTP/2 multiplexing: many calls share one connection.
- Deadlines and cancellation are part of the protocol.
Why not everywhere:
- Browsers cannot call it directly without a proxy (gRPC-Web).
- Binary payloads are harder to debug with curl.
- Public APIs favour REST because every developer already knows it.
A common design: REST or GraphQL at the public edge, gRPC between microservices behind it.
Example
service Pricing {
rpc GetPrice (PriceRequest) returns (PriceReply);
}
message PriceRequest { string sku = 1; }
message PriceReply { int64 paise = 2; }Both sides generate typed code from this file, so a wrong field name will not compile.
What to say in the interview
"gRPC suits internal service-to-service calls where speed, typed contracts and streaming matter. REST stays better for public and browser-facing APIs. I would expose REST at the edge and use gRPC inside."