Background image
Alt Text!
Geschreven door Bjarni Coenen op zondag, 15 december 2019

Is gRPC going for the win?

gRPC is a high-performance RPC framework created by Google. It uses Protocol Buffers to exchange data between services instead of JSON. Google is using it for almost all its internal communication. If Google is using gRPC, why is the biggest part of the software engineering world still using REST? 

In gRPC messages and services are defined in a .proto file to generate DTOs, client and server implementations. Defining your services in Protocol Buffers is super easy. The code generating works around many languages like Java, Kotlin, C, C#, C++, Objective-C, Dart, Go, Ruby, Python, PHP and Node. There is also great interoperability between different languages, for example, you can connect a Java client to a Python server. gRPC can be used for request/response to exchange data like REST but it is also possible to stream data thanks to HTTP/2.

A few advantages:

  • Schema-first design for well-defined and decoupled service interfaces
  • Protocol Buffers is very efficient because it is small, fast and simple
  • Based on HTTP/2 which allows multiplexing several data streams over a single TCP connection
  • Streaming requests and responses come in really handy
  • Generating code in many programming languages that can interchange data for maximum interoperability
  • Protobuf enforces strong-typed messages by its schema

A disadvantage:

  • Data over the wire is not human-readable. The schema is needed for the serialization of the structured data that is binary sent over the wire

Protobuf vs JSON

The biggest difference between gRPC and REST is the format of the payload. The most commonly used format in REST is JSON. JSON is a text-based format that is easy to read but therefore bigger than Protobuf. The reason why Google uses REST for their external APIs is that it is human-readable. For example, when you are going to use the Google Maps API you want to know what you are expected to send and receive. Another argument is that Google wants people to use their public APIs and at this moment REST has a way bigger market share. On the other hand for internal services performance is way more important. The binary sent data through gRPC is way smaller. A 52 byte message in JSON can be 20 bytes in Protobuf.

An int 150 assigned for ‘a’ in JSON:

   "a": 150

In protobuf the schema the message will be:

message Number {
   int32 a = 1;

When it is sent over the wire in protobuf:

08 96 01

The ’08’ is the varint key. The rest ’96 01′ is number 150.

96 01 = 1001 0110 0000 0001
→ 000 0001 ++ 001 0110 (drop the msb and reverse the groups of 7 bits)
→ 10010110
→ 128 + 16 + 4 + 2 = 150

Even in this simple message, the payload of the gRPC call is smaller. You can imagine how big the difference can be with a bigger message. Another difference is that JSON can have repeated keys in a list where protobuf will not have it in the payload.

Request/Response vs Streaming

Rest only support request/response model available in HTTP 1.x where gRPC has streaming possibilities. In gRPC it is also possible to make a Unary API, but there are three sorts of APIs extra. HTTP/2 lets you stream information constantly. gRPC has Server Streaming, Client Streaming and Bi-directional Streaming APIs. A Server Streaming API will receive one request and will send back one or more responses to the client. A Client Streaming API will send one or more requests but will only receive one response. As you might guess a Bi-directional Streaming API works both ways. When the channel is open it can send and receive multiple requests and responses.

My thoughts

I think gRPC will go for the win over REST. There are many advantages to using gRPC, but it will still take some time to beat REST (or it might never completely happen). REST is so commonly used that it will not easily lose in the API world. If your next project will be working on internal services I would really advise considering gRPC. The performance improvements are really worth it and it is very easy to use gRPC. If you are exposing your service to a web client then REST would still be a great solution. Although the gRPC support for a web client gets a lot better nowadays.

We will explain and discuss more (technical) details in the following blogs about this subject. So keep an eye on our website.


Check github for some examples (currently a gRPC unary and server streaming API)

Ben jij een IT-professional die zich breder wil ontwikkelen?
Neem dan contact met ons op!
Telefoon: 088-81 81 100

Deel dit Blog artikel