gRPC Foundations

The idea in one sentence

gRPC lets one program call a function in another program — running on another machine — as if it were a local call. You define the functions and their data once, in a .proto file, and gRPC generates the client and server code that makes the network disappear.

That is the whole promise: you write stub.GetUser(id), and a request travels across the network, runs on a server, and returns a typed result — with no URLs, no JSON parsing, and no hand-written HTTP.

What this module covers

Lesson	What you’ll learn
What is gRPC?	The RPC model, the `.proto` contract, and the generate-then-call workflow
gRPC vs REST	Where each fits, the real trade-offs, and honest guidance on choosing
HTTP/2 & gRPC	Why gRPC needs HTTP/2 — multiplexing, streams, and binary framing
Protocol Buffers intro	The contract-first idea and why a binary schema beats ad-hoc JSON

Why start here

Every later topic — streaming, deadlines, interceptors, load balancing — is a consequence of two design decisions gRPC made up front:

flowchart TB
  proto["Protocol Buffers
(contract-first schema)"] --> gen["Generated stubs
(typed client + server)"]
  http2["HTTP/2
(multiplexed, streaming, binary)"] --> transport["One connection,
many concurrent calls"]
  gen --> grpc["gRPC"]
  transport --> grpc
  grpc --> features["streaming · deadlines ·
interceptors · load balancing"]

The two foundations everything else builds on

Understand those two — a binary contract and a multiplexed transport — and the rest of gRPC stops feeling like magic and starts feeling like the obvious result.