gRPC and Modern RPC

gRPC is the dominant framework for service-to-service calls inside modern systems. It bundles three things: Protocol Buffers for a typed binary contract, HTTP/2 as the multiplexed transport, and code generation that turns a schema file into client and server stubs in a dozen languages. You define a service once in a .proto file, generate the code, and call a remote method as if it were a local function with typed arguments and a typed return.

The trade it makes is deliberate. gRPC gives up REST's human-readable JSON and curl-from-anywhere accessibility in exchange for compact binary encoding, native streaming, and a strict schema the compiler enforces on both ends. Inside a datacenter, between services you control, that is usually the right call. At a public edge where browsers and unknown clients live, it is usually the wrong one — browsers cannot even speak raw gRPC.

One request, one response (a normal function call)→Unary

One request, a stream of responses (a download, a feed)→Server stream

A stream of requests, one response (an upload, aggregation)→Client stream

Both sides stream independently (chat, live sync)→Bidirectional

Protocol Buffers — the IDL and Wire Format

A .proto file is the interface definition: it declares messages (typed structs) and services (collections of RPC methods). Each message field has a name, a type, and — critically — a field number. That number, not the field name, is what goes on the wire; the binary encoding tags each value with its field number, so the encoded form is compact and the names exist only in the schema. A message is a sequence of (field number, type, value) tuples, far smaller than the equivalent JSON.

Field numbers are also the contract for schema evolution. You can add a new field with a new number and old clients ignore it; you can stop using a field. What you must never do is reuse a retired field number for a different field — an old peer will decode the new value into the old field's slot and silently corrupt data. The rule is one line: never change or reuse a field number once it has shipped. Mark removed numbers reserved so the compiler stops anyone from reusing them.

// a .proto contract — field numbers are the wire identity
message User {
  string name = 1;        // field 1, never renumber
  string email = 2;
  reserved 3;               // retired field, blocked from reuse
  int32 age = 4;          // added later; old clients ignore it
}
service Users {
  rpc GetUser(GetUserRequest) returns (User);
  rpc WatchUsers(WatchRequest) returns (stream User);   // server stream
}

The Four Call Types

gRPC supports four call shapes, and you pick per method in the .proto. Unary is the familiar one request, one response — a normal function call. Server streaming sends one request and gets back a stream of responses: a subscription, a paginated feed, a result set arriving over time. Client streaming is the reverse — the client sends a stream and the server returns one response, good for uploads or aggregating many data points into a summary.

Bidirectional streaming opens both directions at once: client and server each send a stream independently over the same call, which maps onto chat, live coordination, or a long interactive session. All four ride the same HTTP/2 connection, which is exactly why gRPC needs HTTP/2 and not HTTP/1.1 — streaming and multiplexing are not bolted on, they are the transport's native model.

Why gRPC Requires HTTP/2

gRPC is built on HTTP/2's capabilities, not just layered over it. Multiplexing lets many concurrent calls share one connection without head-of-line blocking at the HTTP layer, so a service mesh holds a handful of long-lived connections instead of one per call. HTTP/2's bidirectional streams are what make client, server, and bidi streaming possible at all — HTTP/1.1's strict request/response ordering could not express them.

gRPC also leans on HTTP/2 trailers — headers sent after the response body — to carry the final status (grpc-status and grpc-message). A streaming call cannot know its success or failure until the stream ends, so the status has to come last, and only HTTP/2 trailers allow that. HTTP/2 flow control, per-stream and per-connection, keeps one large stream from starving the others on the shared connection.

Edge versus Internal

Browsers cannot speak raw gRPC. JavaScript has no access to HTTP/2 trailers or the raw frame control gRPC needs, so a browser literally cannot make a standard gRPC call. The workaround is gRPC-Web, a slightly different protocol that a proxy (Envoy, or a gateway) translates to and from real gRPC at the edge. Public APIs often sit behind a gRPC gateway that also exposes a REST/JSON facade, so external clients get familiar HTTP while internal services keep the typed binary contract.

Load balancing is the other edge trap. gRPC's long-lived HTTP/2 connections defeat a naive layer-4 load balancer — it pins all the multiplexed calls to whichever backend the connection first hit, so one backend gets hammered while others idle. You need a gRPC-aware (layer-7) balancer that load-balances individual calls across backends, or client-side load balancing. The rule for the edge is simple: terminate or translate gRPC at a proxy that understands it, and never assume a generic L4 balancer distributes gRPC traffic.