Hello, dear readers! Welcome to my blog. On this post, we will delve on Google’s RPC style solution, gRPC and his serialization technique, protocol buffers. But what is gRPC and why it is so useful? Let’s find out!
The escalation of data transfer
When developing APIs, one of the most common ways of implementing the interface is with REST, using HTTP and JSON as transportation protocol and data schema, respectively. At first, there is no problem with this approach, and most of the time we won’t need to change from this kind of stack.
However, the problems begin when we get a API that has a big continuous volume of requests. On a situation like this, the amount of memory used on tasks like data transportation could begin to be a burden on the API, making calls more and more slow.
It is on this scenario that gRPC comes in handy. With a server-client model and a serialization technique from Google’s that allows us to shrink the amount of resources used on remote calls, we can scale more capacity per API instance, making our APIs more powerful.
This comes with a price, however: operations like debugging get more difficult on this scenario, because gRPC encapsulates the transportation logic on Google’s solution that utilizes binary serialization to do the transportation, so it is not as easily debuggable as a common plain REST/JSON application.
RPC
RPC is a acronym for Remote Procedure Call, a old model that was much used on the past. On that model, a client-server solution is developed, where the details of transport are abstracted from the developer, been responsible only for implementing the server and client inner logic. Famous RPC models were CORBA, RMI and DCOM.
Despite the name, gRPC only has the concept of a client-server application in common with the old solutions, that suffered from problems such as incompatible protocols between each other, alongside with not offering more advanced techniques from today, such as streams. Their solutions reminds more of the classical request-response model, from the first days of the web.
gRPC
So what is gRPC? This is Google’s approach to a client-server application that takes principles from the original RPC. However, gRPC allows us to use more sophisticated technologies such as HTTP2 and streams. gRPC is also designed as technology-agnostic, which means that can be used and interacted with server and clients from different programming languages.
With gRPC we develop gRPC services, which are generated based on a proto file we provide. Using the proto file, gRPC generates for us a server and a stub (some languages just call it a client) where we develop our server and client logic. The following diagram, taken from gRPC documentation, represents the client-server schematics:
As we can see on the diagram, gRPC supplies us with different types of languages to choose from to develop /expose our gRPC services. At the time of this post, gRPC supports Java, C++, Python, Objective-C, C#, a lite-runtime (Android Java), Ruby, JavaScript and Go – using the golang/protobuf library.
Protocol Buffers
Protocol buffer is gRPC’s serialization mechanism, which allows us to send compressed messages between our services, allowing us in turn to process more data with less network roundtrips between the parts.
According to Protocol Buffers documentation, Protocol Buffers messages offers the following advantages, if we compare to a traditional data schema such as XML:
- are simpler
- are 3 to 10 times smaller
- are 20 to 100 times faster
- are less ambiguous
- generate data access classes that are easier to use programmatically
The Protocol Buffers framework supplies us with several code generators for different programming languages. If we want to develop on Java, for instance, we download Protocol Buffers for Java, then we model a proto file where we design the schema for the messages we will transport and then we generate code using the protoc compiler.
The compiler will generate code for us in order to use for serialize/deserialize data on the format we provided on the proto file.
Types of gRPC applications
gRPC applications can be written using 3 types of processing, as follows:
- Unary RPCs: The simplest type and more close to classical RPC, consists of a client sending one message to a server, that makes some processing and returns one message as response;
- Server streams: On this type, the client sends one message for the server, but receives a stream of messages from the server. The client keeps reading the messages from the server until there is no more messages to read;
- Client streams: This type is the opposite of the server streams one, where on this case is the client who sends a stream of messages to make a request for the server and them waits for the server to produce a single response for the series of request messages provided;
- Bidirecional stream RPC: This is the more complex but also more dynamic of all the types. On this model, we have both client and server reading and writing on streams, which are stablished between the server and client. This streams are independent from each other, which means that could be possible for a client to send a message to a server by one stream and vice-versa at the same time. This allows us to make multiple processing scenarios, such as clients sending all the messages before the responses, clients and servers “ping-poinging” messages between each other and so on.
Synch vs. Asynch
As the name implies, synchronous processing occurs when we have a communication where the client thread is blocked when a message is sent and is been processed.
Asynchronous processing occurs when we have this communication with the processing been done by other threads, making the whole process been non-blocking.
On gRPC we have both styles of processing supported, so it is up to the developer to use the better approach for his solutions.
Deadlines & timeouts
A deadline stipulates how much time a gRPC client will wait on a RPC call to return before assuming a problem has happened. On the server’s side, the gRPC services can query this time, verifying how much time it has left.
If a response couldn’t be received before the deadline is met, a DEADLINE_EXCEEDED error is thrown and the RPC call is terminated.
RPC termination
On gRPC, both clients and servers decide if a RPC call is finished or not locally and independently. This means that a server can decide to end a call before a client has transmitted all their messages and a client can decide to end a call before a server has transmitted one or all of their responses.
This point is important to remember specially when working with streams, in a sense that logic must pay attention to possible RPC terminations when treating sequences of messages.
Channels
Channels are the way a client stub can connect with gRPC services on a given host and port. Channels can be configured specific by client, such as turning message compression on and off for a specific client.
Tutorial
On this lab we will implement a gRPC service, test by making some calls and experimenting a little with streams. It will get us a feel and a head start on how to develop solutions using gRPC.
Set up
For this lab we will use Python 3.4. For the coding, I like to use Pycharm, is a really good IDE for Python that the reader can find it here.
For containerization I used Docker 17.03.1-ce. I also recommend you create a virtual environment for the lab, using virtualenv.
Let’s create a new virtual environment for our lab. On a terminal, let’s type the following:
virtualenv --python=python3.4 -v grpc-handson
After running the command, we will see that a folder was created. That is our virtual environment.
To install gRPC, first we enable the virtual environment on our terminal session. we do this by typing the following, assuming we are inside the virtual environment’s folder:
source ./bin/activate
This will change our terminal, that will now show a prefix with our env’s name, showing it is enabled.
Now on to the installation. First, let’s install gRPC with pip by typing:
python -m pip install grpcioWe also need to install gRPC tools. This tools are responsible for installing the protoc compiler which we will use later on the lab. We install it by typing:
python -m pip install grpcio-toolsThat’s it! Now that we have our environment, let’s start with the development.
Creating the gRPC Service definition
First, we create a gRPC Service definition. We create this by coding a proto file, which will have the following:
syntax = "proto3";
option java_multiple_files = true;
option java_package = "com.alexandreesl.handson";
option java_outer_classname = "MyServiceProto";
option objc_class_prefix = "HLW";
package handson;
service MyService {
rpc MyMethod1 (MyRequest) returns (MyResponse) {
}
rpc MyMethod2 (MyRequest) returns (MyResponse) {
}
}
message MyRequest {
string name = 1;
int32 code = 2;
}
message MyResponse {
string name = 1;
string sex = 2;
int32 code = 3;
}
This file is based on examples from the official gRPC repo – you can find the link at the end of this post. Alongside setting some properties such as the service’s package, we defined a service with 2 methods and 2 schemas for the protocol buffers, used by the methods.
With the proto file created (let’s save it as my_service.proto), it is time for us to use gRPC to create the code.
Generating gRPC code
To generate the code, let’s run the following command, with our virtual environment enabled and on the same folder of the proto file:
python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. my_service.proto
After running the command, we will see 2 files created, as we can see bellow:
PS: The source code for our lab can be found at the end of the post.
Building the server
Now that we have our code generated, let’s begin our work. Let’s begin by creating the server side.
The code from our command is auto-generated, so is not a good practice to code on them. Instead, for the server we will extend the servicer class, so we implement our own gRPC service without editing generated code.
Let’s create a file called gRPC_server.py and add the following code:
import time
from concurrent import futures
import grpc
import my_service_pb2 as my_service_pb2
import my_service_pb2_grpc as my_service_pb2_grpc
_ONE_DAY_IN_SECONDS = 60 * 60 * 24
class gRPCServer(my_service_pb2_grpc.MyServiceServicer):
def __init__(self):
print('initialization')
def MyMethod1(self, request, context):
print(request.name)
print(request.code)
return my_service_pb2.MyResponse(name=request.name, sex='M', code=123)
def MyMethod2(self, request, context):
print(request.name)
print(request.code * 12)
return my_service_pb2.MyResponse(name=request.name, sex='F', code=1234)
def serve():
server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
my_service_pb2_grpc.add_MyServiceServicer_to_server(
gRPCServer(), server)
server.add_insecure_port('[::]:50051')
server.start()
try:
while True:
time.sleep(_ONE_DAY_IN_SECONDS)
except KeyboardInterrupt:
server.stop(0)
if __name__ == '__main__':
serve()
On the code above we created a class that it is a subclass of the class generated by the protoc compiler. We can see that in order to get the request’s parameters, all we have to do is navigate from the request object. To generate a response, all we have to do is instantiate the appropriate class.
We also coded the serve method, where we created a server with 10 worker threads to serve requests and initialized with the class we created to implement the server-side.
To start the server, all we have to do is run:
python gRPC_server.py
And from now on, unless we kill the process, it will be answering on the 50051 port.
Now that we created the server, let’s begin the work on the client.
Constructing the client
In order to consume the server, we need to create a client for our stub. Let’s do this.
Let’s create a file called gRPC_client.py and code the following:
import grpc
import my_service_pb2 as my_service_pb2
import my_service_pb2_grpc as my_service_pb2_grpc
class gRPCClient():
def __init__(self):
channel = grpc.insecure_channel('localhost:50051')
self.stub = my_service_pb2_grpc.MyServiceStub(channel)
def method1(self, name, code):
print('method 1')
return self.stub.MyMethod1(my_service_pb2.MyRequest(name=name, code=code))
def method2(self, name, code):
print('method 2')
return self.stub.MyMethod2(my_service_pb2.MyRequest(name=name, code=code))
def main():
print('main')
client = gRPCClient()
print(client.method1('Alexandre', 123))
print(client.method2('Maria', 123))
if __name__ == '__main__':
main()
As we can see, is really simple to create a client: we just needed to establish a channel and instantiate a stub with it. Once instantiated, we just need to call the methods on the stub as we normally would do with any Pythonic object.
Now that we have the coding done, let’s test some calls!
Making the call
To test a call, let’s first start the server. With a terminal session opened and our virtual environment enabled, let’s start the server, by entering the command we talked about earlier:
python gRPC_server.py
And on another terminal, started like the previous one, we call the client by typing:
python gRPC_client.py
After firing up the client, we will see that the client produced the following output:
main method 1 name: "Alexandre" sex: "M" code: 123 method 2 name: "Maria" sex: "F" code: 1234
And on the server terminal, we can see the following output:
initialization Alexandre 123 Maria 1476
Success! We have implemented our first gRPC service. Now, let’s wrap it up our lab by seeing the last topics: using streams and containerization.
Using streams
To learn about streams, let’s add a new method, that it will be a bidirectional streaming.
First, let’s change the proto file, creating a new method, like the following:
syntax = "proto3";
option java_multiple_files = true;
option java_package = "com.alexandreesl.handson";
option java_outer_classname = "MyServiceProto";
option objc_class_prefix = "HLW";
package handson;
service MyService {
rpc MyMethod1 (MyRequest) returns (MyResponse) {
}
rpc MyMethod2 (MyRequest) returns (MyResponse) {
}
rpc MyMethod3 (stream MyRequest) returns (stream MyResponse) {
}
}
message MyRequest {
string name = 1;
int32 code = 2;
}
message MyResponse {
string name = 1;
string sex = 2;
int32 code = 3;
}
That’s right, this is everything we need to do. After generating the files from the proto again, we need to modify our server to reflect the changes. We do this modifying the file as follows:
import time
from concurrent import futures
import grpc
import my_service_pb2 as my_service_pb2
import my_service_pb2_grpc as my_service_pb2_grpc
_ONE_DAY_IN_SECONDS = 60 * 60 * 24
class gRPCServer(my_service_pb2_grpc.MyServiceServicer):
def __init__(self):
print('initialization')
def MyMethod1(self, request, context):
print(request.name)
print(request.code)
return my_service_pb2.MyResponse(name=request.name, sex='M', code=123)
def MyMethod2(self, request, context):
print(request.name)
print(request.code * 12)
return my_service_pb2.MyResponse(name=request.name, sex='F', code=1234)
def MyMethod3(self, request_iterator, context):
for req in request_iterator:
print(req.name)
print(req.code)
yield my_service_pb2.MyResponse(name=req.name, sex='M', code=123)
def serve():
server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
my_service_pb2_grpc.add_MyServiceServicer_to_server(
gRPCServer(), server)
server.add_insecure_port('[::]:50051')
server.start()
try:
while True:
time.sleep(_ONE_DAY_IN_SECONDS)
except KeyboardInterrupt:
server.stop(0)
if __name__ == '__main__':
serve()
As we can see, the new MyMethod3 receives a iterator of request messages and also send a series of responses as well, by using the yield keyword, which teaches Python to create a generator from our function. We can read more about the yield keyword on this link.
Now we modify the client. We also use a generator with the yield keyword, but on this case, we make the generator create each item at random time intervals, to simulate a real life application with data entering at intervals. The response stream is read with a simple for loop, that it will continue to run until there is no data to output:
import random
import time
import grpc
import my_service_pb2 as my_service_pb2
import my_service_pb2_grpc as my_service_pb2_grpc
class gRPCClient():
def __init__(self):
channel = grpc.insecure_channel('localhost:50051')
self.stub = my_service_pb2_grpc.MyServiceStub(channel)
def method1(self, name, code):
print('method 1')
return self.stub.MyMethod1(my_service_pb2.MyRequest(name=name, code=code))
def method2(self, name, code):
print('method 2')
return self.stub.MyMethod2(my_service_pb2.MyRequest(name=name, code=code))
def method3(self, req):
print('method 3')
return self.stub.MyMethod3(req)
def generateRequests():
reqs = [my_service_pb2.MyRequest(name='Alexandre', code=123), my_service_pb2.MyRequest(name='Maria', code=123),
my_service_pb2.MyRequest(name='Eleuterio', code=123), my_service_pb2.MyRequest(name='Lucebiane', code=123),
my_service_pb2.MyRequest(name='Ana Carolina', code=123)]
for req in reqs:
yield req
time.sleep(random.uniform(2, 4))
def main():
print('main')
client = gRPCClient()
print(client.method1('Alexandre', 123))
print(client.method2('Maria', 123))
res = client.method3(generateRequests())
for re in res:
print(re)
if __name__ == '__main__':
main()
If we restart the server and run the new client, we will receive the following output:
main method 1 name: "Alexandre" sex: "M" code: 123 method 2 name: "Maria" sex: "F" code: 1234 method 3 name: "Alexandre" sex: "M" code: 123 name: "Maria" sex: "M" code: 123 name: "Eleuterio" sex: "M" code: 123 name: "Lucebiane" sex: "M" code: 123 name: "Ana Carolina" sex: "M" code: 123 Process finished with exit code 0
Please note that all this calls were made using the synchronous approach, so the client thread is locked each time a call is made. If we wanted to call the server asynchronously, we would use Python’s futures to do so. I suggest the reader to explore this option as a post-lab exercise.
Running gRPC on Docker
Finally, we would want to run our gRPC server on a Docker container. That is a very simple task to do.
First, let’s create a Dockerfile like the following:
FROM grpc/python:1.0-onbuild CMD [ "python", "./gRPC_server.py" ]
Yup, that’s all! This is a official image from gRPC which makes a pip install on a requirements file and adds the current directory on the container, so we don’t need to add the files ourselves. Let’s build the container:
docker build -t alexandreesl/grpc-lab .
And finally, launch it with our image:
docker run --rm -p 50051:50051 alexandreesl/grpc-lab
If we run again the client, we will see that the server was successfully started. If the reader want, you can also start the container directly by a image I created on Docker Hub for this lab, already built with the source code from our lab. To pull the image, just type the following:
docker pull alexandreesl/grpc-lab
Conclusion
And so we concludes another journey on our great world of technology. I hope I could help the reader to understand what is gRPC and how it can be used to improve our capacity on high demanding API scenarios. Thank you for following me on this post, see you next time.
Technology explained 
Hello, I am a newcomer to Grpc.Can I use Grpc to transfer images from client to server at a speed of MB/s. Thank you.
LikeLike
Hi, SPY! It is possible, but I think you will get a unnecessary overhead. See this article to learn more:
https://ops.tips/blog/sending-files-via-grpc/
LikeLike