A curious case of gRPC


Does the world need another RPC framework? Yes, it does. In order to clarify why, let me rephrase the original question. Does the world need a highly performant, language-neutral, platform-neutral, binary safe, real-time, efficient, and low-memory footprint RPC framework? Yes. That framework is gRPC. It’s developed by Google and hosted under the umbrella of the Cloud Native Computing Foundation, and in this post I go over gPRC in detail.

What is it all about?

RPCs are a form of inter-process communication (IPC). They are used particularly in distributed computing to perform operations among processes that are geographically apart from each other. RPCs are an old story going back to the ‘60s up until the advent of gRPC, and there were a lot of hit-and-miss scenarios among existing implementations.

The g before the RPC

I will tell you why gRPC is so good. It epitomises the idea of scalable inter-process communication by providing a fully fledged and modernised approach to an old problem. It opens the barrier of reliable operations across geographically dispersed processes by using HTTP2, which, among other things, offers server push events, multiplexing, pipelining and data compression. It breaks the traditional synchronous request-response model of RPCs, thus making it suitable for IoT and microservice architectures.

The bill of materials, of course, is the increased complexity of some operations in the case of network partitions or failures. The technical details of HTTP2, which may be more of a burden for some people, need to be considered.

The figure below clarifies a little bit further how gRPC works:


The gRPC server implements the service interface and runs an RPC server to handle client calls to its service methods. Clients can be written in the same or different supported languages. Clients use a stub implementation of service methods which are simply delegates to the actual method on the server side. The delegation medium is the protobuf request-response cycle.

gRPC so far has native support for 10 languages: C++, Java, Go, Python, Ruby, Node.js, Android Java, C#, Objective-C, and PHP.

To give you an example of how it works, we will take a simple echo service and expose it via a gRPC interface. We are going to use a gRPC-proxy to generate client front-end proxies for us.

It only takes three steps:

  1. Define your function: Write the function you want to expose to your clients.
  2. Define your protocol interface: Write a protocol buffers definition for that function and generate the code for your language of choice.
  3. Finish with boilerplate client and server code: You’ll write mostly boilerplate code to initiate the server. In the client side you only need to open a gRPC channel, create a stub, and call the provided function. Everything else is handled by the protocol.

So, let’s get cracking.

We define our simple echo service by writing the proto definitions:

We have defined two endpoints. One is Echo with the endpoint /v1/echo/{id}, and the other is EchoBody, with the endpoint /v1/echo_body. The first one just echoes back the ID you pass and the second one just echoes back the ID in the POST payload you pass.

Now that we have our definitions, let’s generate the proxy and the server stub code:

Generate Server Code:

Generate Client Proxy Code:

The commands will create the files service.pb.go and

Now that we have the associated Go code for the server and proxy definitions, we need to create a client that will register the gateway code, and a server that will implement our echo service.

First, let’s create the gateway:

Most of the code is boilerplate. The most useful function is the call to gw.RegisterEchoServiceHandlerFromEndpoint that will attach all the service endpoints to the HTTP server.

Now, the code for the server is similar:

And now we are ready to use our service:


In this article, we have managed to create a gRPC server in Go and have made RPC calls from a grpc-proxy client based on a protocol buffer definition. We also learned that gRPC is not only important, but should also be one of the things you should learn if you are interested in microservices engineering. It is no small matter that the CNCF has accepted it into their list of hosted projects.


Do you think you can beat this Sweet post?

If so, you may have what it takes to become a Sweetcode contributor... Learn More.


Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *