In this article, we are going to understand what RPC is, and the various implementations of RPC, with a focus on gRPC, which is Google’s implementation of RPC.
Join the DZone community and get the full member experience.
As we are progressing with application development, among various things, there is one primary thing we are less worried about: computing power. Because with the advent of cloud providers, we are less worried about managing data centers. Everything is available within seconds on-demand. This leads to an increase in the size of data as well. Big data is generated and transported using various mediums in single requests.
With the increase in the size of data, we have activities like serializing, deserializing, and transportation costs added to it. Though we are not worried about computing resources, the latency becomes an overhead. We need to cut down on transportation. A lot of messaging protocols have been developed in the past to address this. SOAP was bulky, and REST is a trimmed-down version but we need an even more efficient framework. That’s where Remote Procedure Calls — RPC — comes in.
In this article, we are going to understand what RPC is, and the various implementations of RPC, with a focus on gRPC, which is Google’s implementation of RPC. We’ll also compare REST with RPC and understand various aspects of gRPC, including security, tooling, and much more.
RPC stands for Remote Procedure Calls. The definition is in the name itself. Procedure calls simply mean function/method calls; it’s the „Remote“ word that makes all the difference. What if we can make a function call remotely?
Simply put, if a function resides on a server and in order to be invoked from the client side, could we make it as simple as a method/function call? Essentially what an RPC does is it gives the illusion to the client that it is invoking a local method, but in reality, it invokes a method in a remote machine that abstracts the network layer tasks. The beauty of this is that the contract is kept very strict and transparent (we will discuss this later in the article).
Steps involved in an RPC call:
RPC sequence flow
This is what a typical REST process looks like:
RPCs boil down the process to below:
This is because all the complications associated with making a request are now abstracted from us (we will discuss this in code-generation). All we need to worry about is the data and logic.
So far we discussed RPC, which essentially means making function/method calls remotely — thereby giving us the benefits like „strict contract definition,“ „abstracting transmission and conversion of data,“ „reducing latency,“ and so on, which we will be discussing as we proceed with this post. What we would really like to deep dive into is one of the implementations of RPC. RPC is a concept and gRPC is a framework based on it.
There are various implementations of RPCs. They are:
gRPC (google)
Thrift (Facebook)
Finalge (Twitter)
Google’s version of RPC is referred to as gRPC. It was introduced in 2015 and has been gaining traction since. It is one of the most chosen communication mechanisms in a microservice architecture.
gRPC uses protocol buffers (an open-source message format) as the default method of communication between client and server. Also, gRPC uses HTTP/ 2 as the default protocol. There are again four types of communication that gRPC supports:
Unary [typical client and server communication]
Client side streaming
Server side streaming
Bidirectional streaming
Coming on to the message format that is being used widely in gRPC — protocol buffers, a.k.a. protobufs. A protobuf message looks something like below:
message Person {
string name = 1;
string id = 2;
string email = 3;
}
Here, ‘Person’ is the message we would like to transfer (as a part of request/response) which has fields ‘name’ (string type), ‘id’ (string type) and ‘email’ (string type). The numbers 1,2,3 represent the position of the data (as in ‘name’, ‘id’, and ‘has_ponycopter’) when it is serialized to binary format.
Once the developer has created the Protocol Buffer file(s) with all messages, we can use a protocol buffer compiler (a binary) to compile the written protocol buffer file, which will generate all the utility classes and methods which are needed to work with the message. For example, as shown here, the generated code (depending on the chosen language) will look like this.
We need to define services that use the above messages to be sent/received.
After writing the necessary request and response message types, the next step is to write the service itself.
gRPC services are also defined in Protocol Buffers and they use the „service“ and „RPC“ keywords to define a service.
Take a look at the content of the below proto file:
message HelloRequest {
string name = 1;
string description = 2;
int32 id = 3;
}
message HelloResponse {
string processedMessage = 1;
}
service HelloService {
rpc SayHello (HelloRequest) returns (HelloResponse);
}
Here, HelloRequest and HelloResponse are the messages and HelloService is exposing one unary RPC called SayHello which takes HelloRequest as input and gives HelloResponse as output.
As mentioned, HelloService at the moment contains a single unary RPC. But it could contain more than one RPC. Also, it can contain a variety of RPC (unary/client-side streaming/server-side streaming/Bidirectional).
In order to define a streaming RPC, all you have to do is prefix ‘stream ’ before the request/response argument, Streaming RPCs proto definitions, and generated code.
In the above code-base link:
streaming.proto: this file is user defined
streaming.pb.go & streaming_grpc.pb.go: these files are auto-generated on running proto-compiler command.
We did talk about gRPC a fair bit. Also, there was a mention of REST. What we missed was discussing the difference. I mean when we have a well-established, lightweight communication framework in the form of REST, why was there a need to look for another communication framework? Let us understand more about gRPC with respect to REST along with the pros and cons of each of it.
In order to compare, what we require are parameters. So let’s break down the comparison into the below parameters:
Message format: protocol buffers vs JSON
Serialization and deserialization speed is way better in the case of protocol buffers across all data sizes (small/medium/large). Benchmark-Test-Results.
Post serialization JSON is human readable while protobufs (in binary format) are not.
