Page 51 - MSDN Magazine, October 2019

codes) form the syntax of each call, and every call in every service may feature different characteristics.
So where does gRPC come from? It was originally developed by Google as a framework to better connect its large internal network of standalone services. That framework was open sourced in 2015 under the name gRPC, and is now owned by the Cloud Native Computing Foundation. The gRPC framework addressed precisely the scenario of most of today’s microservice-style architectures.
In which way is gRPC preferable over a REST-inspired HTTP API? Let’s take a look.
Contrasting gRPC and HTTP API
At its core, the gRPC framework is designed for any scenario where communication efficiency is critical. This marks a first cru- cial difference from the HTTP API. Two microservices are not like two communicating Web sites. For example, the ASP.NET application that consumes the API exposed by another Web site evolves independently from the site. While there’s still no realistic guarantee that the HTTP API will evolve, preserving backward compatibility toward all of its callers, the link between API owner and callers remains quite loose.
The gRPC framework instead enforces a binding between client and service. In this regard, it represents a viable option in circumstances where client and service are managed by the same team and follow the same development cycle. In other words, tight coupling is ideal in a tightly coupled network of components like a microservice- oriented application. Once it’s determined that the tight-coupling argument isn’t an architectural shortcoming, then the benefits of bindings between client and service can be further analyzed.
The major benefit of gRPC over a plain HTTP API is performance. As mentioned, the gRPC framework uses HTTP/2 as the transpor- tation layer, which is the newest version of HTTP with some specific improvements in the area of binary framing, compression and multi- plexing over a single connection. As a result, HTTP/2 is more efficient and also flexible both in sending and receiving packets. Beyond the transportation protocol, the framework itself takes care of serializing and deserializing data using the Protobuf binary format. This contrib- utes to making the traffic generated by each gRPC call more compact.
Beyond performance, the gRPC framework provides benefits also in the application development space. Each service is based on a .proto file that acts as the contract of the service. The contract can be used to generate the service and client. The framework takes care of the dirty job of generating client, service base class and mes- sages for every major computer language, with all of them using the same contract standard. Messages in particular are crucial as any method is designed to receive a message and return a message, and the contract of both is fixed. This means that the call fails if anything is sent or received outside the boundaries of the contract. Anybody who ever experienced the burden of receiving incorrect or inconsistent JSON or weird status codes knows very well what I mean here. The gRPC framework is type-safe and consistent across all supported platforms and implementations.
In a nutshell, the gRPC framework was somehow to avoid the shortcomings of a RESTful, HTTP-based API in the context of a (very) large organization and myriads of distributed components.
msdnmagazine.com
Microservice-to-Microservice Communication
In past installments of this column, I covered the basics of gRPC and discussed some examples of its capabilities. In particular, last month I wrote about the streaming API. Leveraging the low-level capabilities of HTTP/2, the gRPC framework allows the client to send, and the service to return, multiple packets per connection. The interesting thing is that both the client and the service can be sending and returning multiple packets per connection, thus turning a gRPC communication into a sort of superfast chat.
One of the most talked about anti-patterns of SOAP and REST, and distributed architecture in general, was the “chatty” style of an API in which the client needs to place multiple calls in order to receive all the data it logically needs. While the “chatty” style remains an anti-pattern to avoid, the advanced streaming capabilities of the framework make it possible to arrange a bi-directional channel between two endpoints so messages can be exchanged in real time without polling.
Think, for example, of a monitoring scenario in which the service receives data constantly from a connected device, does some work on it and then passes data to a real-time Web dashboard. In an architecture in which the aggregator and the real-time data provider microservice communicate directly, the use of the gRPC protocol for bi-directional communication can realistically increase the performance of every single call by at least a few milliseconds.
Doesn’t it sound like a huge gain? Well, that’s probably why gRPC isn’t (or not yet) a good fit for the Web UI. But for back-end microser- vice-to-microservice communication, especially in applications with heavy loads where every bit counts, it could really make a difference.
When Using gRPC between microservices the front end is con- nected to a microservice (that is, the gateway to the microservice cluster) via a plain HTTP API consumed over the Web. As men- tioned, at the current stage of both gRPC and the browser technology, no gRPC services can be invoked directly from any browser. Most modern browsers support HTTP/2, but only in a sort of transpar- ent way and only after negotiating the protocol to use during the initial connection to the server. Because of this, browsers don’t allow clients to dictate the protocol to use and therefore can’t directly invoke the gRPC service. Microservice-to-microservice communication or, more broadly, server-to-server communi- cation, is a good scenario for gRPC, but mobile and desktop applications can use gRPC, as well.
Wrapping Up
Until recently, the word REST has been used to label nearly any public endpoints exposed over the Web through the HTTP proto- col. REST came with the promise that once resources are defined the entire public API results from the combination of resource names and HTTP verbs. As more verbs and resources are added, new and existing clients can just connect and place calls. This flexibility comes at an obvious cost—the lack of strict rules and contracts. This is just what gRPC brings to the table. n
Dino Esposito has authored more than 20 books and 1,000-plus articles in his 25-year career. Author of “The Sabbatical Break,” a theatrical-style show, Esposito is busy writing software for a greener world as the digital strategist at BaxEnergy. Follow him on Twitter: @despos.
October 2019 47