What is gRPC, and when would you choose it over REST?
Quick Answer
gRPC is an RPC framework over HTTP/2 using Protobuf (a compact binary format) with a strict, code-generated contract. It's faster and supports streaming (client, server, or bidirectional) better than typical REST/JSON, which makes it a strong fit for internal service-to-service calls. REST/JSON stays the better choice for public APIs, where human-readability, broad tooling and browser support matter more.
gRPC is a contract-first RPC framework — you define your service and messages in a .proto file, and it generates strongly-typed client and server code. It runs over HTTP/2 with Protobuf's compact binary encoding, so it's noticeably faster and smaller on the wire than JSON over REST, and it has first-class support for streaming, including full bidirectional streams. That makes it a great fit for internal service-to-service traffic in a microservices setup where you control both ends and call volume is high. I wouldn't put it on a public-facing API, though — browser support needs a proxy layer, and it loses REST's big advantage of being human-readable and curl-able, which matters a lot for third-party developer experience.
- Contract-first: a
.protofile generates strongly-typed client and server code in many languages. - Binary + HTTP/2 multiplexing = lower latency and payload size than JSON over HTTP/1.1, valuable at high call volume between microservices.
- Native browser support is limited (needs grpc-web + a proxy) — not ideal for a public-facing web API.
- Debuggability is lower than REST/JSON — you can't just curl and eyeball the payload; needs tooling (grpcurl, BloomRPC).