gRPC is a remote procedure call framework built by Google on top of HTTP/2 and Protocol Buffers. The pitch: define your API in a .proto schema file, and gRPC generates type-safe client and server code in any language. You call remote functions like local ones.

The Proto File: Contract First

Unlike REST where the contract is implicit (or an OpenAPI spec bolted on later), gRPC starts with a .proto file. This is the source of truth. Generate the client, generate the server stubs, and both sides are guaranteed to speak the same schema.

syntax = "proto3";

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc StreamUpdates (GetUserRequest) returns (stream UserEvent);
}

message GetUserRequest { string user_id = 1; }
message User { string id = 1; string name = 2; int32 age = 3; }
message UserEvent { string event_type = 1; User user = 2; }

HTTP/2 and Binary Encoding

gRPC runs over HTTP/2, which gives it multiplexing (multiple requests over one connection), header compression, and full-duplex streaming. Payloads are binary Protobuf — typically 3-10x smaller than equivalent JSON. This matters at scale: fewer bytes, faster serialization, lower CPU on both ends.

Four Communication Patterns

• ▸Unary: one request, one response — like a regular function call
• ▸Server streaming: client sends one request, server streams back many responses
• ▸Client streaming: client streams many messages, server responds once
• ▸Bidirectional streaming: both sides stream simultaneously — great for real-time systems

When gRPC Wins

gRPC is the right choice for internal service-to-service communication where you control both client and server, performance matters, and polyglot code generation is valuable. It's ideal for microservice meshes, mobile backends that need compact payloads, and any scenario where streaming RPCs are needed.

The Trade-offs

• ▸Not human-readable — binary Protobuf requires tooling to inspect (grpcurl, grpc-ui)
• ▸Browser support requires grpc-web or a translation layer — not native browser HTTP/2
• ▸Schema evolution needs care — field numbers in .proto are permanent contracts
• ▸Steeper initial setup vs just writing a REST handler
• ▸Excellent observability requires interceptors (equivalent to middleware)