gRPC: APIs Between Machines
Every time a rider ends a trip in Riverport, a lot more happens than the one webhook Vera receives. Behind Tandem's counter, its own programs are talking to each other: the ride service tells the billing service, which tells the account service, which tells the notification service. Dozens of small conversations per ride, none of them meant for a human eye. A great many companies run that inside traffic on gRPC.
gRPC is a style of API built for programs talking to programs at high volume. The contract is written in a file and compiled straight into both sides, and the messages travel as binary — compact data meant for machines rather than the readable text this book has used all along. You will almost certainly never send one by hand, and understanding why not is the actual lesson of this page.
A Contract Compiled Into Both Sides
Here is the part worth carrying away. In this book, the contract lives in documentation: Tandem writes down which addresses exist and what they answer, and you read it. In gRPC, the contract lives in a file — conventionally ending in .proto — that lists the available calls and the exact fields going in and coming out. That file is then compiled: fed through a tool that generates matching code for each program, in whatever language each one is written in.
The consequence is strictness. Both sides were built from the same file, so a field the contract does not mention cannot be sent, and a mistyped name fails when the program is built rather than at three in the morning. That is the trade this style makes: less freedom, far fewer surprises, and messages small enough to send by the million.
Where gRPC Actually Lives
Think of freight rail next to a post office counter. Sealed containers run between company depots on fixed schedules — brutally efficient, nothing hand-addressed, and no window for walk-in customers. The post office exists precisely because the public needs somewhere to walk in. gRPC is the freight line; Tandem's partner API is the counter.
So gRPC turns up where both ends are code owned by the same organization and deployed together: services inside a company's systems, the internals of a mobile app talking to its own backend, pipelines moving large volumes of events. What those places have in common is that no human ever needs to read the traffic, and that the two ends can be changed together whenever the contract changes.
Why You Will Never curl One
Point curl at a gRPC service and you get gibberish, and the gibberish is not a sign of trouble. Two things make it unreadable. The messages are binary rather than text, so there are no field names to see. And the transport is HTTP/2, a newer version of HTTP that packs several conversations into one connection in a form built for speed rather than for reading.
Neither of those is hostility. It is a different audience: this traffic was never meant for a person with a terminal, so nothing was spent on making it legible. gRPC has its own tooling for the engineers who work with it — command-line clients and inspectors that read the contract file and translate for you — and that tooling is where their debugging happens. "My tools show nothing useful here" means you are holding the wrong end of a system, not that someone is hiding something.
What This Says About the Counter You Know
Now turn it around, because this is the payoff. Public, partner-facing APIs stay overwhelmingly text and JSON, and gRPC has not displaced them, for one reason: people integrate with the public counter. Strangers. A city coordinator, a tourism board, a researcher, you. They need to read the docs, paste an address, see what came back and work out for themselves whose side an error is on. Everything that makes the counter slower on the wire is what makes it usable by someone who does not work there.
Practically, that means one thing for you. If a job posting or an architecture discussion mentions gRPC, it is describing engineering work on the inside of a system — the subject of the Backend Deep Dive course this catalogue is still writing, not this one. The fluency this book gave you lives exactly where gRPC does not: at the counter, where the promise is written in plain text for strangers to read.
- "gRPC is the faster successor to REST, everywhere." It dominates one niche — machine to machine, at volume, both ends owned by the same team — and serves the public counter poorly. Both styles thrive, on purpose, because they are aimed at different readers.
- "Binary means secret, or encrypted." Binary is a format: compact, machine-first, awkward for humans. Encryption is a separate matter entirely, handled by TLS just as it is for the addresses in this book. Plenty of contract files are published openly.
- "I should feel behind for not knowing gRPC hands-on." Its hands-on audience writes services for a living. Nothing about this book's skill is diminished by a style whose entire design assumes no stranger will ever read the traffic.
- The word turns up in job ads and architecture conversations. One honest page turns it from something intimidating into something you can classify in a sentence: inside traffic, compiled contracts, not your counter.
- Seeing a contract compiled into both programs sharpens what makes the world you learned so approachable. Loose, text-based and documented is not a lesser design; it is the design that lets a stranger join in.
Knowledge Check
Where does gRPC do most of its work?
- Between a company's own services, inside its systems
- On public partner counters, where outsiders integrate
- Between a browser and the website it is showing you
- Between a program and the files it stores on disk
What is the contract file at the heart of a gRPC service?
- A schema file compiled into both programs
- A legal agreement between the two companies
- A documentation page the developers read
- A list of quotas each caller is allowed
Why do public partner APIs stay text and JSON instead of moving to gRPC?
- Because strangers have to read and integrate with them
- Because gRPC is not available to most companies yet
- Because binary messages travel more slowly than text
- Because only text over HTTP can be encrypted safely
A colleague says gRPC's binary messages mean the traffic is private. What is wrong with that?
- Binary is a format, and privacy comes from encryption
- Nothing is wrong, because binary traffic cannot be read
- Binary messages are slower, so nobody uses them anyway
- Contract files are secret, which is what keeps it private
You got correct