Is It GRPC As Fast Versus REST As All The Industry Is Talking About?

Let’s find if gRPC protocol that is raising as one of the strong alternatives against traditional REST service can show all the benefits that people are claiming

If you already have been around the tech industry lately you know that gRPC is becoming one of the most popular protocols for integration among components, mainly microservices because of its benefits comparing with other standard solutions such as REST or SOAP.

There are other alternatives that are also becoming much popular on a daily basis such as GraphQL but today’s focus is on gRPC. If you would like to take a look at GraphQL benefits you can take a look at the article displayed below:

Why Should You Use GraphQL for your APIs?

3 benefits of using GraphQL in your API that you should take into consideration. Photo by Mika Baumeister on Unsplash We all know that APIs are the new standard when we develop any piece of software. All the latest paradigm approaches are based on a distributed amount of components created with a collaborative approach in mind […]

So, what are the main benefits that are usually exposed regarding gRPC usage and why companies such as Netflix or Uber is using it?

Lightweight messages
High performance
Streaming pattern support

So it seems a good alternative from a renovated version of the traditional remote procedure call that has been using on the 90’s but let’s try it in some real-use cases to try to measure the benefits that everyone is claiming, especially regarding performance and lightweight of the messages, so I decided it to define a very easy scenario of a request/response pattern between two application and test them with a normal REST call and a gRPC call.

Tecnology Stack

We are going to use TIBCO Flogo to create the application to use a visual no-code to simplify the application generating. If you would like to take a look more in detail about this technology please take a look at the post below:

TIBCO Flogo Introduction

Flogo is the next new thing in the developing applications in a cloud-native way. Since its foundation has been designed to cover all the new challenges that we need to face when dealing with new cloud-native development. So, please, if you or your enterprise is starting its movement to the cloud it’s the moment to […]

So, we are going to create two application: First one will be activated on a scheduled bases each 100 ms and it will call using gRPC to the second application that we just return the data to the call application hard-coded to avoid any other third party system could impact on the performance measure.

Regarding the data that we are going to transmit this will be a simple Hello world approach. First application will send a name to the second application that it will return the “Hello, name, This is my gRPC (or REST) application” to be able to print that in console.

REST Approach

Below are shown the application for the test case using TIBCO Flogo technology to define it:

As you could see it is simple and intuitive we have the first application activated by a Trigger and with a REST Invoke activity and then a Log Message to print what it has been received. Second application is even simpler, just expone the REST API and return the hard-coded data.

gRPC Approach

gRPC approach will be a little bit more difficult because we need to create the protobuf definition for the gRPC client and server. So we will start with a simple definition of the Hello service as you can see in the picture below:

And based on that we can generate the different applications both the client and the server of this simple test:

As you can see application are very similar to the one for REST just changing one protocol for the other and that is one of the awesome things of TIBCO Flogo, we can just have a simple implementation without knowing the details of the newest protocols but getting all the advantages that they provide.

Test Results

After 100 executions of the REST service those are the metrics we were able to get using the Prometheus exporter that the tool provides:

So we have around 4 ms for the client flow and 0.16 ms for the REST service itself, so they are already low numbers. Do you really think that a gRPC version could improve it? Let’s watch it. Here are the same metrics for 100 invokes of the second flow using gRPC:

So as you can see the improvement is awesome even for a simple service running on localhost. The gRPC service had a metrics of 0.035 ms vs the 0.159 that it had the REST version pretty much an improvement of 77.98% vs the REST API, this is just incredible.. but what about the client? It went from 4.066 ms to at 0.89 ms what means another 78.1% of improvement.

So the rationale should be if this can be done with a simple service where data exchanged is pretty much nothing, what it can do when the payload is big? the options are just unimaginable..

Summary

We tested the good things we have heard online of the gRPC method that most of the cutting-edge technologies are using today and we have been impressed just a simple scenario comparing it with the performance of a REST interface. For sure gRPC has its cons like any other option but in terms of performance and message optimization the data speaks for itself, it is just amazing. Stay tuned for new tests regarding gRPC benefits and also some of its cons to try to see if could be a great option for your next development!