gRPC

"A modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment," per its own front page (T1, grpc.io). It arrived here in the same minute as protocol-buffers and belongs to it: you define the service in a .proto file, and gRPC's protoc plugin generates client and server stubs alongside the message classes Protobuf already generates.

Transport is HTTP/2. Governance is CNCF incubation — which is worth noting against protocol-buffers, whose docs tell you not to use it where formal standards compliance matters: the RPC layer built on the vendor format sits in a foundation, the format underneath does not. Quickstarts cover Go, C++, Java, Rust and Python among others; Netflix, Cisco and Juniper Networks are the named adopters.

The four call shapes

The .proto service definition picks one of four, and this is the part that distinguishes gRPC from generated REST clients:

• Unary — one request, one response, "just like a normal function call."
• Server streaming — one request, a stream of responses. Order is guaranteed within a call.
• Client streaming — a stream of requests, one response after the server has processed them.
• Bidirectional streaming — both sides stream independently, and either may read or write in whatever order it likes.

The last one is the capability an OpenAPI-generated HTTP client cannot express at all, and it falls out of HTTP/2 multiplexing rather than being bolted on.

The parts that are honest about distributed systems

Three details in the core-concepts doc read like they were written by people who had been paged:

• Deadlines, not timeouts. A client states how long it will wait; the RPC ends with DEADLINE_EXCEEDED. Some languages express it as a duration, others as a fixed point in time — and the docs say the difference out loud rather than papering over it.
• The two ends can disagree. Client and server "make their own independent determination" of whether a call succeeded, and those determinations can differ. A server can consider an RPC complete while the client calls it failed.
• Cancellation does not roll anything back. Either side can cancel immediately, and "changes made before a cancellation are not rolled back."

Channels carry the connection to a host and port and configure things like compression; metadata is key-value pairs on a call, usually authentication, with grpc- reserved and -bin marking binary keys.

Why it is filed here and not with production ops

A judgment call worth recording, because the spoke has a precedent pointing the other way. The Ky boundary (2026-06-18) keeps application-level runtime libraries out of this spoke — an HTTP client you npm install is a dependency, not build infrastructure. gRPC is a runtime library by that test.

It routes here anyway because its dominant substance is the same machinery as schema-driven-codegen: a .proto contract compiled by protoc into stubs for ten languages, which is this spoke's subject and the reason protocol-buffers is here. gRPC without codegen is not gRPC. The runner-up spoke is platform-ops-wiki, which owns service-to-service communication as an operational practice — the seam is that the framework is here and the consequences of running it in production are there, and a source about gRPC load balancing, retries or service mesh integration should route there instead.

Related

protocol-buffers · protobuf-wire-format · protobuf-editions · schema-driven-codegen · openapi-generator · google · developer-tooling · synthesis