gRPC – the binary future of microservices?
gRPC – the binary future of microservices?

A little bit of history

Nowadays, we have a variety of formats to communicate between different application layers, microservices infrastructure, REST, SOAP, RPC, JSON-RPC, XML-RPC, etc. protocols.

They are mainly specified by two most popular formats:

  • for REST operations and codes are stored in the request, URI and headers, whereas data is sended as text (JSON format in request body)
{
    "username": "user@example.com",
    "password": "some_password"
}
  • for SOAP we have standards for description of interfaces, endpoints, etc. – such as XML Schema and WSDL. In this case operations are done mainly through XML
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
    soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
    <soap:Body xmlns:m="http://host.example.com/login">
        <m:Login>
            <m:Username>user@example.com</m:Username>
            <m:Password>some_password</m:Password>
        </m:Login>
    </soap:Body>
</soap:Envelope>

As you know, text-based data formats are a bit burdensome (especially in the excessive amount of text in XML tags) – as web developers – we have all known it for years.

RPC? Sounds familiar?

There is also an alternative, old solution called RPC (Remote Procedure Call) , which is used today – mainly in desktop apps and in UNIX-based systems.

The main advantage is that RPC sends data as binary stream, so it’s very efficient in comparison with sending data as text (JSON, XML).

Unfortunatelly, there is one strong limitation, that throws out RPC from today’s web applications – it can be used only where client and server are written in the same programming language, CPU architecture or compiler optimization used by program. For example it only works for Java(client)-Java(server), C(client)-C(Server), etc.

Why this limitation exist? Because the data(integer, float, char, etc.) types have different binary representations in different languages and CPU’s. So if you have C++ code you cannot call C code without adding the support of external libraries (mostly require a lot of memory and calculations, when you have to convert data between different architectures).

HTTP/2.0 – a huge milestone

All described above protocols uses HTTP/1.1.

There was a big step into future – in 2015 new version of HTTP/2.0 protocol was standarized.

It have decreased latency, which helps us with improving page load speed in web browsers mainly thanks to:
– data compression
push server HTTP/2
pipelines in requests (bi-directional messages)
– multiplexing multiple requests into one TCP connection:

Source: blog.cloudflare.com

The HTTP/2 protocol was added to most major browsers (Chrome, Firefox, IE11, Edge, Safari, etc.) by the end of 2015, also it was added to major web servers.

This caused an increase of usage (in may 2017 there were 13.7% of the top 10 mln websites, which supports http/2) – according to W3Techs statistics (w3techs.com).

Of course, this protocol and its capabilities have been noticed by many companies (including big players like Google).

gRPC – a universal, multi-language RPC framework

Also in 2015, Google announced that it had created the gRPC framework. It uses the capabilities of the RPC protocol and HTTP/2.0 with its functionalities. It’s implemented on top of HTTP/2 layer.

Moreover Google has provided gRPC with a support of multiple programming languages (C++, Objective-C, PHP, Python, Ruby, Node.js, Go, C#, Java, etc.).

Generally, we have Proto Requests and Proto Responses, whose have the same binary representation, and they are translated between several environments..

This image (taken from the grpc.io) explains how gRPC conceptually looks like:

Source: grpc.io

What does it mean for us?

This signifies that we are able to send binary data between microservices, servers, applications – in many different languages with greather performance than older solutions. (gRPC is pretty simple and very efficient in comparison with old HTTP/ 1.1)

The biggest obstacle of the past regarding the RPC protocol has been resolved. What are the benefits of using this by our servers, hosting and applications?

Thanks to HTTP/ 2.0, we have a lot of data savings (no redundant text data) => transfer savings => energy savings => cost savings => end customer and business satisfaction.

Performance tests in comparison with JSON (in terms of throughput on VM instance using 9 gRPC channels and throughput per CPU):

Source:  Google BigData blog

gRPC has many advantages over RPC – you can also use additional things such us:

  • oauth2.0 to auth your RPC calls (per call level),
  • TLS for free
  • client certificates for transport authentication

I encourage you to try and test gRPC in your programming language. You can start with:

Short summary

I think gRPC may be the future of many apps, microsevices. It’s not yet popular or known among many companies and developers, but it will probably change over the years. If you want to speed up your project – you may want to try out this technology to see also the powerful possibilities of the new HTTP/2 protocol. I think it’s worth it!

Sources:

Interesting articles / videos:

Mateusz Palichleb

Blog author

I am a experienced programmer in building web applications (generally I started programming in 2005). I'm always open to conversation about clean code, and interesting programming techniques, whoose can improve our work as developers.

You Might Also Like

An AutoMapper for PHP, the powerful and simple solution for mappings

An AutoMapper for PHP, the powerful and simple solution for mappings

Leave a Reply

Your email address will not be published. Required fields are marked *