gRPC

gRPC is a Remote Procedure Call framework that does something deceptively simple: it lets you call a function on another computer as if it were running locally.

You call a function. It runs on another machine. The network disappears.

This is the promise of RPC, and gRPC—originally developed by Google—delivers on it with modern infrastructure: HTTP/2 for efficient connections, Protocol Buffers for compact binary serialization, and code generation that gives you actual typed functions to call rather than raw HTTP requests to construct.

The Problem gRPC Solves

Modern applications are collections of services talking to each other. A single user request might touch authentication, user profiles, inventory, payments, shipping, and notifications. That's six network calls before anything useful happens.

With REST, each call means:

• Constructing an HTTP request
• Serializing data to JSON
• Sending bytes over the network
• Parsing JSON on the other side
• Handling errors manually
• Repeating for every single call

JSON parsing is expensive. Text protocols are verbose. HTTP/1.1 requires a new connection for each request. REST doesn't formally define what a service accepts or returns—you hope the documentation is accurate.

gRPC replaces all of this with: call the function.

Protocol Buffers: The Contract

You define your service in a .proto file:

syntax = "proto3";

service UserService {
    rpc GetUser (GetUserRequest) returns (User);
    rpc ListUsers (ListUsersRequest) returns (stream User);
    rpc CreateUser (CreateUserRequest) returns (User);
}

message User {
    string id = 1;
    string name = 2;
    string email = 3;
    int32 age = 4;
}

message GetUserRequest {
    string id = 1;
}

This is a contract. The compiler reads it and generates actual code—client code that calls these methods, server interfaces that implement them. In Go, Python, Java, C++, or a dozen other languages.

The field numbers (= 1, = 2) are stable identifiers. Never change them. Add new fields, but don't renumber old ones. This is how gRPC handles versioning without breaking existing clients.

The binary format is 3-10x smaller than JSON and dramatically faster to serialize. Your services spend less time parsing and more time doing useful work.

HTTP/2: One Connection, Many Calls

gRPC builds on HTTP/2, which solves a fundamental inefficiency in HTTP/1.1.

With HTTP/1.1, each request needs its own connection—or you wait for the previous request to finish. A service making 100 calls to another service needs 100 connections, or serialized waiting.

HTTP/2 multiplexes many requests over a single connection. One TCP connection between two services handles all their communication. Headers compress. Binary framing aligns with Protocol Buffers' binary format.

The practical result: less latency, fewer resources, more throughput.

Four Ways to Communicate

Unary: One request, one response. The familiar pattern.

rpc GetUser (GetUserRequest) returns (User);

Server streaming: One request, many responses. The server sends results as they become available rather than making you wait for all of them.

rpc ListUsers (ListUsersRequest) returns (stream User);

Client streaming: Many requests, one response. Upload data in chunks, get a summary when done.

rpc CreateUsers (stream CreateUserRequest) returns (CreateUsersResponse);

Bidirectional streaming: Both sides send whenever they want. Chat applications, collaborative editing, real-time synchronization.

rpc Chat (stream ChatMessage) returns (stream ChatMessage);

REST gives you request-response. gRPC gives you four patterns, chosen per-method based on what the data actually needs.

Deadlines That Propagate

Here's something elegant: gRPC deadlines flow through the system.

Service A calls Service B with a 2-second deadline. Service B calls Service C. Service C knows it inherited that deadline—it can check how much time remains. If the deadline expires, everyone stops working.

No more computing a response that nobody will receive because the original caller gave up. The timeout isn't just a client concern; it's shared context that prevents wasted work.

The Tradeoffs

You can't curl it. gRPC traffic is binary. You need specialized tools to inspect it. REST wins on debuggability.

Browsers can't speak it natively. gRPC-Web exists but requires a proxy. For browser-to-server communication, REST or GraphQL remain better choices.

The learning curve is real. Protocol Buffers, code generation, streaming semantics—there's more to learn than "send JSON to a URL."

Some networks hate it. Corporate proxies that inspect HTTP traffic may not handle HTTP/2 or binary protocols well.

These aren't reasons to avoid gRPC. They're reasons to use it where it shines: service-to-service communication inside your infrastructure.

Security

gRPC supports TLS for encrypted transport, token-based authentication via metadata (like HTTP headers), and mutual TLS where both client and server verify certificates. Interceptors—middleware for gRPC—handle authentication, logging, metrics, and tracing without polluting your service logic.

When to Use gRPC

Use it for: microservices talking to each other, real-time streaming, polyglot systems where services use different languages, anywhere performance matters and you control both ends.

Don't use it for: browser-facing APIs, public APIs where you can't control clients, situations where simplicity beats performance.

Many systems use both. gRPC for internal communication where efficiency matters. REST for the public API where compatibility matters.

The Core Insight

gRPC succeeds because it makes the network feel like it isn't there. You define a contract. The compiler generates code. You call functions. They happen to execute on other machines.

The complexity of distributed systems doesn't disappear—you still need to handle failures, timeouts, and partial availability. But the mechanical burden of network communication does. What remains is the actual work: implementing the logic your services exist to perform.