What Is gRPC?

What RPC Means and How gRPC Fits In

Remote Procedure Call (RPC) is a programming model where a process invokes a function that executes on a different machine. From the developer's perspective, the call looks like a normal local function: you pass arguments and receive a return value. The RPC framework handles serialising the arguments, sending them over the network, invoking the function on the remote server, and returning the result. This abstraction is older than the internet itself — Sun RPC dates to the early 1980s.

gRPC is Google's modern, open-source implementation of this idea. Google built it to replace an internal framework called Stubby, which powered billions of inter-service calls per second inside Google's data centres. Released publicly in 2015, gRPC combines two key technologies: Protocol Buffers for binary serialization and HTTP/2 for transport. Unlike REST, which models interactions as operations on resources (URLs), gRPC models interactions as method calls on services defined in a schema file.

Protocol Buffers: The Schema and Serialization Layer

Protocol Buffers (Protobuf) is the interface definition language and binary encoding format that gRPC uses for all messages. You define your data structures and service contracts in a .proto file. A simple example looks like this: you declare a service block with rpc method definitions, and message blocks that describe the request and response shapes. Each field in a message is assigned a numeric tag.

The protoc compiler reads your .proto file and generates client stubs and server interfaces in your target language. The generated code is strongly typed — if your schema says a field is an integer, the generated code enforces that type at compile time, not at runtime. This catches an entire class of bugs that JSON-based APIs discover only in production.

At runtime, Protobuf encodes messages using field numbers rather than field names. A JSON object {"user_id": 42, "email": "alice@example.com"} repeats the field names verbatim in every message. The equivalent Protobuf message encodes the same data using small integer tags, eliminating the name overhead entirely. The result is encoded messages that are typically 3 to 10 times smaller than equivalent JSON and significantly faster to encode and decode.

HTTP/2 Transport and Multiplexing

gRPC runs exclusively over HTTP/2, which provides several capabilities that HTTP/1.1 cannot match. HTTP/2 multiplexes multiple requests and responses over a single TCP connection using streams, each identified by a stream ID. This eliminates the head-of-line blocking problem in HTTP/1.1, where a slow response on one connection delays all subsequent requests behind it.

For gRPC, multiplexing means that a single connection between two microservices can carry thousands of concurrent RPC calls without opening thousands of TCP connections. HTTP/2 header compression (HPACK) further reduces overhead for repeated headers across calls. The persistent connection also means gRPC avoids the TLS handshake cost on every request — the handshake happens once when the connection is established, and subsequent calls reuse it.

The Four gRPC Communication Patterns

gRPC defines four RPC types in .proto files. Unary RPC is the classic one-request, one-response pattern. The client sends a single message and blocks until the server responds — equivalent to a REST API call. Server streaming RPC lets the client send one request and receive a continuous stream of responses. This is ideal for sending large datasets incrementally, pushing live event feeds, or returning paginated results without the client polling.

Client streaming RPC reverses this: the client sends a stream of messages, and the server responds once when the stream is complete. This suits uploading sensor readings, log lines, or chunked file data. Bidirectional streaming RPC is the most powerful pattern: both sides send independent streams of messages simultaneously over the same HTTP/2 connection. Neither side needs to wait for the other to finish before sending. This enables real-time collaborative features, chat systems, and live telemetry dashboards.

The Code Generation Workflow

A gRPC project starts with a .proto schema file that both the client team and server team agree on. Running protoc with the gRPC plugin generates two artefacts: a server interface that the backend team implements, and a client stub that the frontend or calling service uses. Both sides compile against the same generated types, so any breaking change to the schema — like removing a field or changing its type — produces a compile error rather than a silent runtime failure.

This schema-first workflow is one of gRPC's strongest advantages over loosely typed REST APIs. OpenAPI/Swagger attempts to bring similar structure to REST, but it is optional and must be kept in sync manually. In gRPC, the .proto file is the authoritative source of truth, and generated code is always consistent with it. Teams commonly store .proto files in a shared repository and version them with semantic versioning rules.

gRPC vs REST vs GraphQL

gRPC-Web for Browsers

Standard gRPC cannot run in a web browser because browsers do not expose the raw HTTP/2 framing interface that gRPC's binary protocol requires. The gRPC-Web specification addresses this with a thin compatibility layer. You include the gRPC-Web JavaScript client library in your browser application, and deploy a proxy — typically Envoy or the standalone grpc-web proxy — between the browser and the gRPC backend. The proxy translates gRPC-Web requests (which use HTTP/1.1 or standard HTTP/2 fetch) into native gRPC on the server side.

gRPC-Web supports unary and server-streaming calls. Client streaming and bidirectional streaming are not supported in the browser via gRPC-Web because the browser Fetch API does not allow the client to send a stream before the response begins. For full duplex streaming from a browser, WebSockets or the newer WebTransport API are the appropriate alternatives.

Use Cases for gRPC

gRPC is the dominant choice for internal microservice communication at companies with performance-sensitive architectures. When hundreds of services call each other thousands of times per second, the difference between 200-byte JSON payloads and 30-byte Protobuf payloads adds up significantly in bandwidth and CPU costs. Mobile backends benefit similarly: mobile clients on constrained cellular connections transfer less data per API call, and battery usage from network radio activity decreases proportionally.

Real-time data pipelines — streaming sensor data from IoT devices to processing services, pushing live financial quotes, or synchronising state between distributed game servers — use gRPC's streaming modes to maintain persistent connections rather than polling. Internal tooling such as build systems and deployment infrastructure also use gRPC because the compile-time contract enforcement prevents subtle API version mismatches during fast-moving development cycles.

Frequently Asked Questions

What is the difference between gRPC and REST?

REST uses HTTP/1.1 or HTTP/2 with JSON text payloads and a resource-oriented URL design. gRPC uses HTTP/2 exclusively with Protocol Buffers binary payloads and a procedure-oriented design where you call named methods. gRPC payloads are typically 3–10 times smaller than equivalent JSON, the binary encoding is faster to serialize and parse, and gRPC natively supports four streaming patterns. REST is human-readable, works natively in any browser, and has a vast ecosystem of tooling. gRPC trades those conveniences for raw performance and strong typing enforced at compile time.

What are Protocol Buffers?

Protocol Buffers (Protobuf) is Google's language-neutral binary serialization format. You define your data structures and service interfaces in a .proto schema file using an Interface Definition Language. The protoc compiler reads the schema and generates strongly-typed client and server code in your target language (Go, Java, Python, C++, and many others). At runtime, data is encoded into a compact binary format using field numbers rather than field names, which makes encoded messages significantly smaller than JSON and faster to encode and decode. Field numbers enable backwards-compatible schema evolution: adding a new field does not break existing clients.

Does gRPC require HTTP/2?

Yes, standard gRPC requires HTTP/2. This means gRPC is not directly usable in web browsers, which do not expose the raw HTTP/2 framing layer needed for gRPC's binary framing. The gRPC-Web specification solves this with a translation layer: a proxy (such as Envoy or grpc-web) sits between the browser and the gRPC server, translating gRPC-Web requests into standard gRPC on the backend. For server-to-server communication, HTTP/2 is widely available, and gRPC implementations handle connection management and multiplexing automatically.

What are the four gRPC streaming modes?

gRPC supports four communication patterns. Unary RPC is the simplest: the client sends one request and receives one response, exactly like a traditional function call. Server streaming RPC: the client sends one request and receives a stream of responses — useful for sending large datasets or live updates. Client streaming RPC: the client sends a stream of messages and receives one response when done — useful for uploading sensor data or chunked file uploads. Bidirectional streaming RPC: both sides send streams of messages simultaneously over a single HTTP/2 connection, enabling real-time collaborative or chat-style applications.

Can I use gRPC in a browser?

Not directly. Browsers do not expose the HTTP/2 framing layer that gRPC requires. The gRPC-Web protocol bridges this gap: your browser-side code uses the gRPC-Web client library, and a proxy (Envoy or the grpc-web Go proxy) translates between gRPC-Web and native gRPC on the server side. gRPC-Web supports unary and server-streaming calls but not client-streaming or bidirectional streaming in the browser. For full bidirectional streaming from a browser, WebSockets or WebTransport are typically used instead.

When should I use gRPC instead of REST?

gRPC is the better choice when performance and strong typing matter more than simplicity or browser compatibility. It excels in microservice architectures where many internal services communicate at high frequency, in mobile backends where bandwidth is constrained and binary payloads reduce data usage, and in real-time data pipelines that need streaming. REST remains the better choice for public APIs that external developers will consume, any endpoint that must be called directly from a browser without a proxy, and teams that prefer human-readable debugging over compile-time safety.