Don't Panic — gRPC Fundamentals

The corridor version: gRPC is a way to call a function that runs in another program on another machine and have it look almost like calling a function in your own. You write down what the functions are and what they accept, both sides generate code from that description, and most of the network plumbing is handled for you.

Before this, teams that wanted services to talk either invented a request format over HTTP and hand-wrote a client for every language, or reached for something heavier. The recurring cost was that the description of the API and the code that spoke it drifted apart. The fix here is to make one file the source of both.

That file is a .proto, written in Protocol Buffers: a schema language that lists your messages and your service methods. A compiler turns it into message classes, a client object called a stub, and a server interface, in whichever supported language you asked for. The server implements the methods; the client calls the stub; the contract between them is the file.

Three ideas carry most of the weight. There are four RPC shapes: one request and one response, a stream of responses to one request, a stream of requests to one response, and both sides streaming at once. Every call should carry a deadline, meaning how long the client will wait before it stops caring. And a call finishes with a status code, not just a value, so "it worked" and "it timed out" are different answers you have to handle separately.

Here is the part that catches people. The call looks local, but it is not, and the framework does not paper over the difference. A deadline firing means the client gave up; it does not mean the server did. If the method wrote to a database, it may have committed before you stopped waiting, so retrying it blindly can do the work twice. Cancelling a call stops further work; it does not roll anything back.

The other surprise is where the difficulty actually lives. Not in writing messages: in traffic. gRPC runs many calls over one long-lived connection, so an ordinary load balancer sends all of them to a single backend while the others sit idle. Fixing that needs a smarter proxy or a service mesh, and it shapes how the service gets deployed.

For the whole picture, read the Intro, with the Slides as the compressed version. The Cheatsheet has the RPC-shape table and the rules for turning a failure into the right status. The Practice tab builds a real unary service and forces a timeout on purpose. Field Notes covers what teams get wrong once the diagram makes sense: load balancing, deadlines that do not propagate, keepalive settings that close connections, and the few kilobytes you actually get for an error message.

Don't Panic — gRPC Fundamentals

Relevant careers