Topic 6.7
gRPC
In one line
RPC with a schema, HTTP/2 multiplexing, and binary protobuf payloads — the internal-to-service favorite.
Think of it like this
Two departments in the same company using a private, fast internal phone line with a pre-agreed script, instead of writing formal letters (REST) to each other every time. It's efficient because both sides already know exactly what to expect.
Key ideas
- 01
gRPC = protobuf schema (.proto) + HTTP/2 + codegen (stubs) → typed, fast, self-documenting service contracts.
- 02
HTTP/2 multiplexing fixes head-of-line blocking at the connection level and kills per-call overhead.
- 03
Four RPC styles: unary, server-streaming, client-streaming, bidi-streaming.
- 04
Why services pick it: contract-first, smaller payloads (binary), streaming, deadlines.
- 05
Cost: stricter versioning discipline; tooling beyond curl; debugging needs grpcurl.
- 06
Interview contrast: REST = developer ergonomics + browser; gRPC = throughput + strict contracts inside the DC.
Java / Spring map
- →
Spring: gRPC via armeria/grpc-spring-boot-starter; protobuf-maven-plugin codegen.
Code & diagrams
Same request, two very different wire formats and connection models.
Explain without notes
When do you choose gRPC over REST for an internal API? Name the two strongest reasons.
Practice
Write a .proto for a status-check service (unary + server-streaming) and list the generated types.
Trade-offs
- ↔
Binary payloads break curl-and-log inspection; protobuf schema evolution needs rule discipline (never renumber).
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can say why gRPC is fast and when its strictness pays.