How HTTP/2 & Protobuf Paved the Way for gRPC

with Raju Gurram

In 2015, Google open-sourced a new RPC (remote procedure call) framework named gRPC.  The fact that this was built and adopted by the company that has one of the largest (if not the largest) ecosystem of microservices should speak volumes about its efficacy.  Google makes tens of billions of gRPC calls per second proving the prodigious scalability of this framework.  No wonder then that the interest in gRPC has been rising steadily.  Perhaps, it is getting ready to cross the chasm and graduate from the “early adopter” to the “early majority” category. 

In this article, I would like to briefly introduce two technologies, namely, Protocol Buffer and HTTP/2 and discuss how gRPC is standing tall on the shoulders of these two.

Protocol Buffer

If you are making remote procedure calls, you need a mechanism to transform objects (payload) in memory into bytes such that they can be transmitted.  There are many names for it: serialization, encoding, marshaling.  Most programming languages support this by default and they often use JSON.  It is human readable and there is a large community behind it. But JSON has its drawbacks too.  It tends to be slower and bigger in size.  When you are dealing with big data or a large number of microservices communicating with each other, all these add up quickly.  JSON is also not typed which can create challenges with backwards or forward compatibility.

Protocol Buffer (aka Protobuf) was developed by Google and publicly released in 2008.   Protobuf is an Interface Definition Language that is language-neutral and platform-neutral. It tries to address some of the limitations stated above.  With protobuf, you define your message format in a .proto file.  You can then use the protobuf compilers to generate the client and service side code to encode and parse the data.  It uses an efficient binary format and it is typed that can be evolved over time.  One downside is that the binary format diminishes human readability. 

HTTP/2

Much like Protobuf, HTTP2 addresses some of the limitations of its predecessor HTTP 1.x.  It supports a binary format and header compression for enhanced performance.  Additionally, it maintains a single connection to avoid the overhead associated with setting up TCP connections.  It allows for full request and response multiplexing means for maximum throughput and it also means streaming can be supported on both sides more naturally. HTTP/2 has been picking up steam.  Roughly 27% of Chrome traffic is now HTTP/2.  Most browsers support HTTP/2 nowadays.

gRPC

gRPC is your good old remote procedure calls.  In other words, it is API oriented as opposed to REST which is resource oriented.  gRPC is built on top of HTTP2 transport layer and therefore can support 4 types of APIs (unary, client streaming, server streaming, and bi-directional streaming).  It also leverages Protobuf for message exchange.  Protbuf gives it support for 11 languages out of the box and all the benefits of a binary protocol.  It is the power duo of HTTP2 and Protobuf that gives gRPC it’s superpowers in terms of performance, throughput and flexibility.

API Management & gRPC

Here at Layer7, we have supported HTTP/2 for a while now.  One can leverage it for Apple Push Notification, for example.  Our customers can take advantage of the Gateway to interact with gRPC using our extensibility measures (assertions).  We can support any combination of gRPC and non-gRPC client and server.  For example, one can expose a legacy API as a gRPC API and have clients interact with it as if it was a gRPC API.  Conversely, if a client cannot talk gRPC, we can transform a non-GRPC call from a client and translate that into an outgoing gRPC call.  Please note in either case, all clients would still make the call onto a HTTP/2 port and let the Gateway sort out what needs to be done in the background.

Figure 2 – Gateway as gRPC Proxy

We need one more piece for this to work.  We need to create a gRPC entity such that we can attach both the proto file and the policies.  When the message arrives at the Gateway, service resolution takes place using this entity.  The routing assertion directs the message [call] to the appropriate protected service.

Figure 3 -gRPC Entity

Conclusion

gRPC owes a lot of its success to other advances in technologies such as Protocol Buffer and HTTP/2.  These are timely inventions that have become the wind beneath the wings of gRPC. As the popularity of Protobuf and usage for HTTP/2 increases, so has the adoption of gRPC.  Keep an eye out for gRPC – while it is not the magic bullet for every scenario, it is definitely picking up steam in the developer community and for good reasons!

Obaidur Rashid

Obaidur Rashid

Obaidur (OB) Rashid is an engineer at heart and by trade. He has over 22 years of experience developing software across numerous domains, industry verticals, and delivery models (SaaS & On-Premise). OB started his career at Oracle and rose through the ranks to become an architect. Since then he has worked with companies and products of various sizes and scale. He has dealt with data at scale and APIs all his professional life. He is also a regular speaker at industry events. OB lives in the San Francisco Bay Area with his wife and son. He loves to play and watch cricket!

Share With Your Network

Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on facebook
Facebook
Share on email
Email
Share on print
Print

More From The API Academy