HTTP/2 and gRPC

This entry is part 3 of 4 in the series Engineering in Orfium

Software applications have dramatically evolved over the last few years, as they are getting more capable, more complex and offer more and more functionalities. For the purpose of these functionalities, various services have to interact and coordinate each other. These services have to be as efficient and fast as possible, so the application user can have the best possible experience, which in the end is the main goal.

In order for these to happen, software engineers have to constantly learn and adopt new tools and technologies that can help them build reliable and scalable applications.

In this post, we will talk about two of these technologies HTTP/2 and gRPC and their key advantages.


HTTP/2 Overview

In 2015, the Internet Engineering Task Force (IETF) released HTTP/2, the second major version of the HTTP protocol, fifteen years after the HTTP/1.1 release.

HTTP/2 is built on top of HTTP/1.1, so it does not modify the application semantics of HTTP, so all the core principles like HTTP Methods, headers etc. are still there, but rather aims to address many of its pitfalls. Below are the main benefits that HTTP/2 provides:

  • Multiplexing – Back in HTTP/1.1 clients could make only one request per connection and had to wait for the server response in order to send the next request, known as “head-of-line blocking” issue. HTTP/2 can solve this issue by sending multiple requests in parallel over a single connection and receiving responses out of order.                      
  • Header compression – HTTP/2 uses header compression HPACK to reduce overhead. HTTP/2 forces all HTTP headers to be sent in a compressed format, reducing the amount of information that needs to be exchanged between browser and server.
  • Prioritization – Clients can point out which of the resources are more important and they would like to receive first than others, allowing the server to prioritize the requests.
  • Server Push – The server can send resources that the client has not yet requested for but can predict that is going to be requested in the near future. This allows the server to send multiple responses in a single client request.

As we can see HTTP/2 main goals is to reduce load times and data size by improving the communications between clients and servers.

HTTP2 is currently supported by almost all the major browsers and web servers and is backward compatible so someone can upgrade to HTTP/2 without changing anything to his code.

gRPC Overview

gRPC is a modern Remote Procedure Call (RPC) system initially developed at Google and made open source in 2015. gRPC is the evolution of their internal RPC technology named Stubby. It uses by default HTTP/2 for transport protocol communication, which allows exploiting the benefits of HTTP/2 we discussed before, and Protocol Buffers (known as Protobufs) for binary data serialization, although it can be used with others serialization formats. It’s designed as technology-agnostic, which means that can be used and interacted with server and clients from different programming languages.


Remote Procedure Call (RPC) is a technique for implementing HTTP services. An RPC service is a collection of message types and remote methods that provide a defined way for clients to communicate with HTTP services and hides the details of the network communication.  In a nutshell, RPC allows a client to access a remote service simply by calling a remote function as if the function was a local client function.

Protocol Buffers

Protocol buffers, or Protobufs, are an Interface Definition Language (IDL) for describing services, methods, and messages. Protobufs are used for serializing and deserializing the data sent between clients and servers. Their binary format allows for small messages size and fast serialization and deserialization. They use the .proto file’s extension that can be used to generate both the server and client side bindings.

A common proto file looks like this

syntax = “proto3”;
option java_multiple_files = true;option java_package = grpc.model;
message Genre {   int64 id = 1;   string name = 2;}
message GenreResponse {   repeated Genre genre = 1;}
service GenreService {   rpc getGenres (Genre) returns (GenreResponse);}

As we can see proto files describe the data structure and the services that are going to be used with method params and return types.

Some benefits of using Protobufs are:

  • Language-Agnostic – The proto files can be used in multiple applications and multiple environments with no change at all. The latest ‘proto3’ syntax currently supports various languages such as Python, Go, Java and more.
  • Less boilerplate code – Model builders, setters and getters, services are all auto-generated by the proto files. Below are the generated classes for the Genre.proto file above
  • Speed and Security – Smaller, faster output (especially with larger data) that cannot be decoded without knowing the schema.



gRPC with HTTP/2 seems to be a perfect fit for modern software applications, as it offers many benefits out of the box, as its adoption by many companies such as Square, Bugsnag, VSCO, Netflix, Lyft makes it even more attractive.

Our goal as Orfium’s Engineering Team is to have a good knowledge and adopt these technologies in the next few months, so we started experiment them.

In the next part, we will talk about this experiment and what were the results from it.

Series Navigation<< Embarking on a <strong>QA</strong> quest <strong>Music Publishing Formats:</strong> Some common interoperability standards >>