gRPC

Definition of gRPC

gRPC is the latest incarnation (December 2020) of Remote Procedure Call (RPC). It was created by Google in 2015 as an Open Source project that is now under the umbrella of Cloud Native Computing Foundation (CNCF). In 2017 it was the sixth project (CNCF announcement) to join the CNCF and as of December 2020 is in incubation status within the CNCF maturity levels.

gRPC is defined as a general purpose RPC mechanism that is performant, platform and language agnostic using modern cloud-native based technologies to support a Microservice based architecture. It consists of 2 parts, (1) the protocol and (2) the data serialisation. gRPC uses protocol buffers (protobuf) by default for serialising messages, so that protobuf also becomes gRPC's default interface definition language (IDL). This, however, is defined as pluggable from the beginning so other serialisers (e.g., JSON) are possible.

The protocol itself is by default based on HTTP/2 and exploits HTTP/2 to allow messages traverse seamlessly across the internet. gRPC takes advantage of a number of features inherit in HTTP/2; these include:

• Data frames for flow control to allow both clients and servers to respect the throughput capabilities of each side.
• Single TCP connection
• Cancelation and timeout contracts
• Compression of HTTP headers

gRPC supports 2 types of RPC:

• The standard synchronous (blocking) request-response

• Streaming - this is one of the real powers of gRPC. It supports 3 forms of streaming to allow large payloads and asynchronous multi-streams. The 3 forms for streaming are:

  • Client push streams (aka “client streaming”),
  • Server pushed streams (aka “server streaming”) and
  • Bi-directional stream

From historic experience, versioning in distributed systems is both important and a complex subject. Microsoft provides in Versioning gRPC Services a detailed explanation of how versioning is handled and what happens when. gRPC defines in the official documentation of Versioning the rules for when the API versions may change and what is allowed.

Technology Evaluation

Unlike (some) other systems accessing external resources over a network, gRPC hides the protocol from the user by being a framework that does not expose the details about the protocol or the data serialisation. This is done by using an Interface Definition Language (IDL) that describes both the RPC services to be called and the messages to be transferred, then the protobuf compiler generates code that handles the details. As of December 2020, the IDL being used is proto3 with generators for most popular programming and scripting language - see gRPC supported languages for details.

OpenAPI (previously known as Swagger) is REST's equivalent of gRPCs’ IDL - it defines and documents the REST API over HTTP(s). OpenAPI is the de-facto standard for REST based APIs with 70-80% of all formally defined REST APIs being defined using it. Unlike gRPC, OpenAPI only supports HTTP(s) and therefore exposes details about the protocol and handling to the end user. Both OpenAPI and gRPC support code generators and tools to make the authoring and implementation of APIs easier, they both support a wide range of programming and scripting languages, but OpenAPI does not require you to use the code generators to build your APIs - gRPC is nearly impossible to use without the code generators.

One area where gRPC should be considered better than REST is its performance.  There are no official benchmarks and so this is subjective, but at least in gRPC vs REST Performance Simplified and Evaluating Performance of REST vs. gRPC, they document performance improvements in both Go and C# for the applications they used.  The performance improvements in gRPC vs REST Performance Simplified where 50-75% reduction in processing time for gRPC compared to REST and in Evaluating Performance of REST vs. gRPC where gRPC was 7-10x faster.

One of the capabilities of gRPC that is sometimes overlooked is that it has the ability to handle both RPC and REST/JSON based callers from one definition. To do this, it offers a proxy capability to handle the REST/JSON side.

Market - current adoption

Despite gRPC only being in incubation status within the CNCF maturity levels, it has been adopted by both large and small organisations in production. There are a number of adopters’ listed on the gRPC About page - we would consider these to be the tip of the iceberg.

Compared to REST, it is still in the early adopters side of the equation.  It's open how many public APIs are based on gRPC as there are no public registries for gRPC services and services like W3Techs do not provide a statistic for gRPC; de facto most public API are based on REST!

Market outlook - who, why and when to use?

gRPC should be viewed as a tool to add to your tool-belt. Like REST, SOAP, WebSockets, MOM and plain old HTTP, it is not meant to be a one size fits all (even though its general purpose like most of them are); it should be used where appropriate.

There are a number of places where gRPC is a better choice than the others; these include:

• When a usage is Service rather than Resource orientated - seeing developers trying to make something Resource orientated where they're really Service/RPC is a good sign gRPC might be a better fit!
• When “well” structured data (that can be defined) is used.
• When streaming is necessary.
• When performance is important.

We strongly recommend using this if your needs match one of the above.