gRPC in practice: fast internal APIs without creating a debugging nightmare

gRPC's advantages are easy to demonstrate and easy to sell: binary encoding, HTTP/2 multiplexing, generated clients in every language, real streaming. The costs arrive later and in a less quotable form - at three in the morning, when a service returns INTERNAL with no message, your packet capture is unreadable binary, and the load balancer you configured months ago has been sending every request to one pod.

None of that is an argument against gRPC. It is an argument for going in with the operational bill itemised. This covers Protocol Buffers and the rules that keep a schema evolvable, the four streaming modes and when each is right, contract tooling, the observability you need before you ship, the browser situation as it actually stands, and the cases where plain HTTP is the better answer.

Three things bolted together: Protocol Buffers as the serialisation format and interface definition language, HTTP/2 as the transport, and a code generator that turns a .proto file into a typed client and server stub in your language.

The mental model is a function call, not a resource. You do not GET /orders/42; you call OrderService.GetOrder(GetOrderRequest{id: 42}) and get back a typed GetOrderResponse. That framing is the source of both its ergonomics and its opacity - a function call has no URL, no readable body, and nothing a browser can show you.

Protobuf is the part that pays off and the part that bites. It is a binary format where field names do not appear on the wire - only field numbers, types and values. That is why messages are small and parsing is fast, and also why a captured packet means nothing without the schema that produced it.

In proto3, scalar fields have no explicit presence by default. A field set to 0, false or "" is indistinguishable from a field never set at all - both are absent from the wire and both decode to the zero value.

Protobuf Editions replace the syntax = "proto2" / syntax = "proto3" declarations with edition = "2024". Instead of two hardcoded behaviour sets, each behaviour - field presence, enum openness, repeated encoding - becomes a feature you can configure at file, message or field level.

The .proto file is the contract, and unlike an OpenAPI document it is not a description of the implementation - it generates it. That is a real advantage: drift between spec and code is structurally impossible.

What is not automatic is preventing a breaking change from reaching a consumer. buf is the standard toolchain for this, and the breaking-change check is the part worth adopting even if you use nothing else.

Streaming is gRPC's clearest advantage over request/response HTTP, and the feature most often adopted for the wrong reason. A stream is a long-lived logical channel over an HTTP/2 stream, with backpressure and flow control handled for you.

Long-lived streams also interact badly with infrastructure that assumes short requests. Load balancer idle timeouts, proxy read timeouts and Kubernetes rolling restarts will all sever streams. Design for reconnection from the start rather than discovering it during a deployment.

gRPC has its own status code set, deliberately smaller than HTTP's. The mapping to HTTP status codes is lossy in both directions, which matters when you put a gateway in front.

This is the section that earns the title. gRPC's opacity is not a minor inconvenience - it invalidates a set of habits every engineer has, and you have to replace them deliberately.

This one deserves its own section because it silently produces the exact opposite of what you configured, and teams often run in that state for months.

gRPC uses long-lived HTTP/2 connections and multiplexes many calls over each one. A layer-4 load balancer balances connections, not requests. So a client that opens one connection sends every subsequent RPC to whichever backend that connection landed on - while your dashboard shows a load balancer distributing traffic evenly across connections that no longer reflect load.

Browsers cannot speak gRPC. Not for lack of trying - the fetch API and XHR do not expose the control over HTTP/2 frames that the protocol requires. Three workarounds exist, and their trade-offs are different enough to matter.

Connect is the most interesting of the three. A Connect server responds to all three protocols and the client selects via Content-Type, so Node-to-Node services can use native gRPC while the browser talks Connect against the same .proto contract and the same server. Unary Connect calls are notably plain - no length-prefix framing, the serialised message is simply the HTTP body - which is exactly why they work with ordinary HTTP tooling.

The practical shape most teams land on: gRPC between internal services, and a REST, GraphQL or Connect layer at the edge for browsers. That is not a compromise so much as correct placement - the edge has different requirements from the interior.

Protobuf's compatibility rules do most of the work, which means the majority of changes need no version bump at all. Add fields freely; old clients ignore what they do not know about, and new servers see zero values for what old clients omit.

gRPC is a strong default between internal services in a polyglot estate. It is a poor default almost everywhere else, and the reasons are practical rather than philosophical.

The honest summary of the performance argument: binary encoding and HTTP/2 multiplexing produce real savings in CPU and bytes, and those savings scale with call volume. Published comparisons vary enormously depending on payload size, language runtime and whether the REST baseline uses HTTP/2 and connection pooling. Measure your own workload before treating any specific multiplier as a reason to migrate.

gRPC is the right choice for internal service-to-service communication at meaningful volume, especially across languages. The contract is generated rather than described, so drift is impossible. Deadlines propagate through the call graph. Streaming is first-class instead of bolted on. Those are real engineering advantages and they compound as the estate grows.

The bill is paid in observability. Every debugging habit that relies on reading text off the wire stops working, and you replace it with tracing, structured logging, reflection and tooling you have to set up before you need it - not during the incident that made you want it.

And keep it inside. Internal services speak gRPC; the edge speaks HTTP. That boundary is not a compromise - it is putting each protocol where its trade-offs are the right ones. The teams who regret gRPC are almost always the ones who pushed it out to a browser or a third party and spent the next year maintaining a translation layer.