gRPC: What Is It?
Some time ago I started to hear about gRPC, and the benefits it would bring for communication between different applications and devices.
Since one of the main requirements of the projects I work on is to have a very efficient average response time (below 200ms), we started to use gRPC, in order to transfer information more efficiently than we would have using REST with standard http protocol…
And it is about the beginning of this journey that I will comment briefly here, addressing what gRPC is, advantages and disadvantages.
After all, what is gRPC?
gRPC is an acronym for Google Remote Procedure Call, it is a protocol for remote execution of services, allowing a client application to directly call a method of an application on a remote server, and of course, this is a protocol created by Google, based on the old RPC protocol.
Also, gRPC is Open Source, and by default it uses HTTP/2 for data transmission between remote computers. The data is transported using an Interface Definition Language (IDL), and the one most used with gRPC is the Protocol Buffer (Protobuf for the close ones :D).
The protocol provides four different methods for remote calls:
- Unary Call: Unary calls are those in which the client sends a single request to the server and the server responds with a single response, basically the same as a normal REST request, for example.
- Server Streaming Call: Server stream calls are those where the client sends a single request to the server, however, unlike the unary call, the server responds with a stream of data, as if it were a list of responses. So the client reads this stream until there is no more data.
- Client Streaming Call: Client stream calls are basically the opposite of Server Streaming Calls in that the client sends a stream of data to the server, which will process all this data and finally send a single response to the customer.
- Bi-directional Streaming Call: Bi-directional calls are the combination of server and client streaming calls, in other words, both the client and the server can transfer a stream data during the call.
Finally, it is important to say that gRPC is considered not just a new protocol, but a framework, as it already implements several features in different languages without the need to rewrite the basics.
Advantages
The first big advantage is the ease of implementation, with easy and practical examples in several languages. A good starting point is the gRPC documentation itself.
In addition, one of the most observed positive points in gRPC and even one of the great motivators for using this framwork is its high performance, since your messages with protobuf can be up to 30% smaller than an equivalent JSON message, and its execution can be between 5 and 10 times faster than a REST to JSON communication.
The different types of calls possible in gRPC are also a great advantage, as in addition to allowing the transmission of unary messages, like REST, it also ends up allowing streaming of data, which can be very useful in some scenarios.
Disadvantages
The main downside is the fact that it is quite difficult to test with gRPC, and by tests I mean integration tests and E2E.
The messages transmitted by gRPC are not human-readable, like a JSON, which complicates debugging moments, since it becomes necessary to convert the messages from the binary to some other format that is easier to understand .
And that’s it for today folks!