gRPC

What gRPC is

gRPC is a remote procedure call (RPC) framework. A service defines methods in a Protocol Buffers schema, and client/server code can be generated from that contract. Calling a remote method can therefore look much closer to calling a local function while the framework handles serialization and transport.

Protocol Buffers

A .proto file defines services, request messages, response messages, and field types. The schema is strongly typed and designed for efficient binary serialization. Generated code gives clients and servers a shared contract and helps catch incompatible changes before runtime.

Protocol Buffers also provide a disciplined way to evolve schemas. Stable field numbers and compatibility rules matter when independent services are deployed on different schedules.

HTTP/2 and streaming

gRPC commonly runs over HTTP/2, which provides multiplexed streams, binary framing, header compression, and long-lived connections. It supports unary calls as well as server streaming, client streaming, and bidirectional streaming.

These properties make gRPC attractive for service-to-service communication where typed APIs and efficient serialization matter. It is also useful for model orchestration, token services, schedulers, retrieval components, and internal inference APIs.

gRPC vs REST

REST is an architectural style rather than a wire format. In practice, REST APIs usually expose resource-oriented HTTP endpoints and exchange JSON, while gRPC exposes typed methods defined in a .proto contract and commonly serializes messages with Protocol Buffers.

Concern	gRPC	REST
Contract	Schema-first service and message definitions	Resource-oriented URLs and HTTP semantics
Encoding	Protocol Buffers by default	JSON is common, though other formats are possible
Streaming	Unary, server, client, and bidirectional streaming are built in	Usually requires SSE, WebSockets, or chunked HTTP
Browser access	Typically needs gRPC-Web or a gateway	Native browser and command-line support
Best fit	Internal APIs, high-volume service calls, and generated clients	Public APIs, third-party integrations, caching, and human-debuggable endpoints

The choice is often architectural rather than ideological. A public API may use REST at the edge while internal services use gRPC behind an API gateway. gRPC can reduce serialization overhead and make contracts harder to drift, but REST is usually easier to expose, inspect, cache, and integrate across heterogeneous clients.

gRPC vs browser APIs

Browsers do not generally use ordinary gRPC directly, so browser-facing systems often use gRPC-Web or place an HTTP/JSON or SSE gateway in front of the service. A common architecture is simple HTTP at the edge and gRPC inside the service network.

Operational concerns

The protocol does not remove distributed-systems problems. Teams still need explicit deadlines, cancellation, retries, load balancing, connection management, tracing, and backpressure. Long-lived HTTP/2 connections can also interact differently with proxies and middleboxes than short-lived HTTP/1.1 requests.

Example

A chat gateway can call an internal inference scheduler over gRPC. The gateway sends a typed request containing the model, prompt metadata, and generation limits. The scheduler selects a worker and streams results back over gRPC. The public browser connection can then expose those results as SSE.

The core idea

gRPC is valuable because it provides a strong contract and efficient transport for service-to-service communication while supporting streaming and generated client/server code.