My understanding of gRPC

Before I dive into gRPC, let me briefly explain the reasons for having gRPC. It is all about simplifying the communication between microservices and normal services. Normally, communication is done through implementing APIs to communicate between nodes and services. Unfortunately, APIs are hard because you need to specify the communication channel (HTTP REST API or Message Queue e.g. RabbitMQ), authentication methods, payload size(JSON, etc), data model, and error handling. Not only that, we need efficient ways of communication and a lightweight for mobile devices. By using gRPC, the developer will only need to care about the core services logic.

What is Remote Procedure Call (RPC)?

RPC is an inter-process communication in which a computer program calls a procedure (function or method) to execute on a different address space than its own. RPC 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. RPC follows a request-response protocol (client-server model). The below figure illustrates the lifecycle of the RPC.

There are various implementations of RPCs. They are:
1. gRPC (Google)
2. Thrift (Facebook)
3. Finagle (Twitter)

The most well-known framework that builds an RPC is gRPC. gRPC is part of the Cloud Native Computing Foundation(CNCF) like Docker and Kubernetes. RPC stands for the remote procedure call.

gRPC can use protocol buffer (a.k.a protobuf) as both its Interface Definition Language (IDL) and as its underlying message interchange format. The reason for having a protocol buffer is for readability, binary data representation, programming language interoperable, etc.

A protobuf message looks something like the below:

In the above code, Person is the message we would like to transfer (as a part of the request/response). Then, we have three fields with the string data type. The numbers 1, 2, and 3 represent the position of the data when it is serialized in binary format. Upon creating the Protocol Buffer file that includes messages like Person, 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.

Let’s define the services.

After knowing the message in RPC, we need to know the service that will send and receive messages. gRPC services are also defined in Protocol Buffers and they use the service and RPC keywords to define a service.

HelloRequest and HelloResponse are the messages and Greeter is exposing one unary RPC called SayHello which takes HelloRequest as input and gives HelloResponse as output. Note, RPC can contain a variety of RPCs (unary/client-side streaming/server-side streaming/Bidirectional).

The service in gRPC is written in many languages like c++ and Golang. The client and server can still communicate if they are both written in different languages.

The communication protocol in RPC is HTTP/2. gRPC which is based on HTTP 2 has encountered this challenge by having a persistent connection. We must remember that persistent connections in HTTP 2 are different from that in web sockets where a TCP connection is hijacked and the data transfer is unmonitored. In a gRPC connection, once a TCP connection is established, it is reused for several requests. All requests from the same client and server pair are multiplexed onto the same TCP connection.

The protocol buffer compiler called protoc will generate the stubs for the client and server.

Following a quick start in HERE, I was able to play with a simple client and server setup.

In the next blog, I will explain a simple project using gRPC.




I am interested in Distributed Systems!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store