gRPC – Remote Procedure Calls

We know that today’s trend is to build microservices, and these microservices can be built in different languages.  And in a software system, we will be having a bunch of microservices that need to communicate with each other. In this type of scenario, we need to share data across different programming languages.

For example:

We have a Buy microservice, this may be connected with another microservice written in another programming language ‘Promotion Service’, There will also be another microservice ‘Delivery service’. Also, there will be a ‘User ‘ microservice that may be connected to Deliver, Buy, and Promotion. 

So we have a bunch of microservices in different programming languages and they have to talk to one another.

These  microservices when  exchanging information need to agree on a lot of things like,

• The API to exchange data
• The data format
• The error patterns
• Load Balancing
• Many other

One of the most popular choices for building API is REST which uses HTTP-JSON

Building an API is really hard

• We need to think about data models, i.e. whether we need

○ JSON

○ XML

○ binary

• Need to think about endpoints like

○ GET /api/v1/user/abc/post/123

○ POST /api/v1/user/abc/post

• Need to think about how to invoke these API endpoints and how to handle errors
• Need to think about the efficiency of the API
• How much data do we get out of one call

○ Is it too much data?

○ Or is it less data?

• Need to think about latency?
• Need to think about the scalability of API
• Need to think about load balancing
• Need to think about authentication and authorization

Don’t you think it could be better if we have a framework to handle all this stuff?

Yes, That framework is gRPC. 

With the gRPC framework, we only need to take care of the core requirements of an API that is receiving the request and sending back the response. All others we can just leave to the gRPC framework.

What is gRPC?

• gRPC is a free and open-source framework developed by Google
• It allows us to define REQUEST and RESPONSE for RPC(Remote Procedure Calls) and it will handle all the rest for us.
• gRPC is built on top of HTTP/2
• It is fast and efficient, low latency.
• It supports streaming
• gRPC is language independent.
• It is super easy to manage authentication, load balancing, and monitoring with gRPC

What is RPC?

RPC stands for Remote Procedure Call

In the client code, it looks like we are calling a function directly on the server.

For example

So in the above code, we can see that from the client side a function is calling myFunction(). And a function definition of myFunction is present on the server side. It is not actually calling a function on the server-side from the client side but it looks like that.

RPC is a  technique for constructing distributed, client-server-based systems. It is based on extending the conventional local procedure calling so that the called procedure need not exist in the same address space as the calling procedure. The two processes may be on the same system, or they may be on different systems with a network connecting them.

RPC is implemented very clearly in gRPC which helps in solving a lot of problems.

How does the gRPC work?

From this image, we can see that we have a C++ server on the left-hand side and Ruby & Android clients on the right-hand side. Both clients are communicating with the C++ server through protocol requests and responses.

How to work with gRPC?

At the core of gRPC, we need to define the messages and services using Protocol Buffer.

The rest of the gRPC code will be generated for us automatically and we need to provide an implementation for it.

Protocol Buffer Role in gRPC

Protocol Buffers is used to define

• Messages (data, Request & Response)
• Service (Service name and RPC (API) endpoints)

We will generate code from Protocol Buffer.

• Why are we using Protocol Buffers instead of JSON is gRPC?
• Protocol Buffers have very less payload size than JSON. This will save network bandwidth.
• Parsing JSON is more CPU intensive than Protocol Buffers. Because JSON is human readable and Protocol Buffers is in binary format.
• Protocol Buffers is more fast and efficient in communication, it is friendly with devices having comparatively slower CPU like mobile devices and IOT devices.

Officially supported gRPC languages

• C 
• C++ 
• C#
• Dart
• GO
• JAVA
• Hotline
• Node.Js
• Objective-C
• PHP
• Python
• Ruby

gRPC vs REST

• gRPC uses Protocol Buffers which is smaller and faster

REST uses JSON which is text-based, slower, and bigger compared to Protocol Buffers.

• gRPC uses HTTP/2 which has low latency

REST uses HTTP1.1 which has higher latency

• REST allows the only Client to Server requests 

gRPC allows Bidirectional and  Asynchronous APIs

• REST supports Request / Responses only

gRPC supports data Streaming also

• REST is CRUD (Create, Retrieve, Update, Delete / POST, GET, PUT, DELETE) oriented.

gRPC doesn’t have any constraints, it is freely designed. 

• REST normally won’t support auto code generation.

gRPC generate code through Protocol Buffers

Some researchers found that gRPC is 25 times more performant than REST API. 

Overall if you are looking for a highly scalable performance-driven API gRPC is going to be the default choice over REST APIs..

Types of API in gRPC

There are 4 types of API that we can use in gRPC they are

• Unary
• Server Streaming
• Client Streaming
• Bi-Directional Streaming

Unary

Unary API follows the normal style of API communication. I.e the client sends a request to the server and it will respond with the data.

Server Streaming

method of enabling streaming capability in API communication. In this case, the client will request some data and the server will respond with a stream of data. So as the ser

Client Streaming

This is the opposite of the Server Streaming API. I.e the client will open a streaming connection to the server and send multiple streams of messages to the server and after a certain stream message client will receive a response from the server. So this is also a streaming connection but here the client is sending streaming data.

Bi-Directional Streaming

In Bi-Directional Streaming the client sends requests to the server in the form of streaming data and the server responds to it in the form of data streaming. Here data is sent and received asynchronously between client and server.

Note: The streaming capability in gRPC is enabled through HTTP 2

Scalability in gRPC

• gRPC Servers are asynchronous by default
• So each gRPC server can serve millions of requests in parallel
• gRPC client can be asynchronous or synchronous
• gRPC clients can perform client-side load balancing
• As a proof of scalability:

Google has 10 Billion gRPC requests being made per second internally. 

Security in gRPC

• By default gRPC strongly advocates for us to use SSL in our API
• Each language will provide an API to load gRPC with required certificates and provide encryption capability out of the box.
• In gRPC using Interceptors, we can provide authentication
• In short, gRPC has a built-in security

Summary Why use gRPC

• Easy code definition in over 11 languages
• With Protocol Buffers, we have easy code generation in these 11 languages
• Uses a modern, low latency HTTP/2 transport mechanism
• SSL Security will be built in
• Support for streaming APIs for maximum performance.
• gRPC is API oriented, instead of Resource-Oriented like REST

Have a project in mind that includes complex tech stacks? We can be just what you’re looking for! Connect with us here.