Understanding, building, and using gRPC APIs

TLDR; gRPC is a REST API antipattern. But the suffering could be worth It to some organizations (oh, and if you're using Kubernetes, then you're already using gRPC, even if you didn't know it).

It was back in 2005 during a small techie meetup in San Francisco when I learned in a conversation with two people --one from Google, the other from Yahoo -- that the two companies were independently on the verge of launching the Web's first public APIs. Google was about to launch the Google Maps API and Yahoo was launching an API for its recently acquired Flickr photo sharing site. If it could be said that the API economy was birthed from its own big bang, this was about as close to a big bang as I had ever been and probably am ever going to be.

Within a few months, I scrambled together the API economy's first major gathering in Silicon Valley; an event called Mashup Camp and in the years that followed, there were more Mashup Camps all over the world. If there was one thing that became evidently clear from these events, it was that Google would be setting the example for what it meant to be a public API provider (as well as a private one to itself). Sure, there were a lot of players rushing APIs out the door by the beginning of 2006, but Google was clearly the trend setter.

While other leading API providers have emerged in the intervening years, Google is still admired for a degree of scale that puts the company in a league of API providers all to its own. Back in 2016 (an eternity in Internet years), I attended a presentation given by Google's Tim Burks in which he said that Google was processing over 10 billion API calls every second. Yes, every second!

That was five years ago. In preparing this article, I asked Burks on Twitter if he had an updated figure. He tweeted to fellow and former Googlers who had no idea but knew the new number involved more zeroes. In fact, the consensus was that the original 10 billion estimate was low, citing Google's official 2015 introduction of gRPC in which then Google product manager Mugur Marculescu wrote "tens of billions" of API calls per second.

Google invented gRPC out of necessity. Stretching back to the day it was founded, the company is fanatical about performance. Across the many sessions that I've attended over the years at Google I/O (it's annual developer conference), it became abundantly clear to me that Google obsesses over every picosecond that doesn't belong between the moment a user clicks or taps something and the moment the screen reflects the complete response. This obsession appears in everything Google does from the way it builds Chrome to the developer tooling it offers (think WebAssembly) to, you guessed it, how it's API-led infrastructure works. If Google could have it's way, every user experience out there would perform as though the user had a quantum computer in the palm of their hand and no network was involved (even though neither is true, at least for now).

While Google and Yahoo may have helped to birth the API economy with Web APIs, it wasn't long before the performance-obsessed Google realized how, at scale (again, tens of billions of API calls per second), it was too expensive and too slow to rely on the Web's underlying protocol (HTTP) and payload formats like XML and JSON to handily support that volume of transactions. Not only was precious machine time (and therefore money) being wasted on the serialization and deserialization of data on the client and server sides of each API call, the process was leaving valuable seconds on the table. To Google, time is literally money.

Enter gRPC, Google's reinvention of the RPC (remote procedure call) architectural style of APIs; an architectural style that sacrifices some but not all of the lauded benefits of REST in the name of economies of scale and speed. As Ferraris go, gRPC makes REST look like a horse and buggy. It's so fast that it's well suited to situations where only the fastest will do (eg: for the container runtime interface in Kubernetes; an implementation that few if any Kubernetes admins will ever actually come into direct contact with).

With gRPC now under the hood of the gazillions of API calls taking place across Google's network every second, the company is saving an untold number of machine cycles, and accordingly, money. At scale, big money; significant shareholder value kind of money.

Relative to other API architectural patterns, cost friendliness at scale isn't gRPC's only beneficial value proposition. Compared to REST where APIs are described out-of-band using an independent description specification like OpenAPI , gRPC is similar to GraphQL in that the gRPC specifications include provisions for in-band API description. In other words, description is built-in. Aside from the convenience of not having to embrace a entirely separate set of technologies to build machine readable descriptions of your APIs, one major downstream benefit of this approach is the availability of Google-built tooling to automatically generate client libraries (SDKs) for a gRPC API in over 10 different languages . Unfortunately, compared to REST, there isn't a groundswell of other tooling for provisioning or consuming gRPC APIs the way there is for REST and even GraphQL. To really commit to gRPC, an organization must be prepared to suffer. But at some degree of scale -- we're not sure of the number -- the math could work in your favor.

gRPC has other appealing attributes. Whereas most common API architectural patterns like REST do not include an event-driven streaming option (for this, you must turn to a separate technology), gRPC not only includes provisions for event-driven streaming, it's a type of streaming that can go in either direction; server to client, client to server, or both.

Google, being the Google that is, didn't keep this invention for itself. The gRPC specification is available to anybody to use, free of charge and Google makes some of its own gRPC tools available as open source.

With so much going for it, this in turn begs the question that every organization should be asking itself; "If gRPC is so good for the API economy trend-setting Google, is it good enough for us?"

Unfortunately, that's not a question that ProgrammableWeb can answer for you. But what we can do is offer you the information you need to answer the question for yourself; the most comprehensive introduction and hands-on guide to using gRPC that could have been written. In this series, we discuss the history, the technology, how it works, the pros, the cons, and we give you some hands-on tutorials so you can experience gRPC first hand for yourself.

David Berlind
Editor in Chief, ProgrammableWeb