Google’s Remote Procedure Call to communicate through services. (gRPC)

All this time I used to write REST APIs. I knew there are some others ways for this purpose, but I have never tried any of that. Meanwhile I heard about gRPC which is the next level communication on HTTP/2.

So, I thought of sharing my experience about gRPC. This article is all about how I get to know about gRPC. The article will be a series of episodes. This is the Episode 01 where I write about the basic intro about gRPC.

Making the Inter-service communication better is what we do as software engineers (API developers). When we start looking at the options for inter-service communications, here are the main two.

1. REST (Representational State Transfer)
2. RPC (Remote Procedure Call)

REST (Representational State Transfer)

Sends resources back and forth and manipulate those resources

REST communicatio — from a plurasight lesson By Mike Van Sickle

RPC (Remote Procedure Call)

This is different than REST, because REST is based on resources but RPC is based on functions and procedures.

RPC communication — from a plurasight lesson By Mike Van Sickle

Anyway, the expectation from the both options are same.

Why RPC than REST?

REST uses text based messaging and HTTP semantics for the communication.

RPC has the following features and that will make it has more clarity when communicating with services.

• It is actions focused
• It uses programming semantics
• It uses binary based messages (very small compares Text in REST)

Some facts about gRPC

• It supports cross-platform
• It is scalable
• It enable streaming — not designed to a single request and response, it can manage chunk of requests and expect a single response or send a single request and expect chunk of responses.
• Free-and-open — no price to use and the source is there for you.
• It’s fast and efficient

Ultimately

gRPC allows all other different technologies (languages) to talk to each other natively without knowing what language the service is written.

gRPC Structure

As we all know most of the systems consist of at lease one server and one client. It actually does not has to be like one to one map, It can have multiple servers and multiple clients.

Server is responsible for processing the request and to respond accordingly.

Client is responsible of sending the request to the server and waits for the response.

in gRPC both the server and the client will have a generated code which allows the connection between the client and the server. The conversion of the code to the desired language is abstracted under that generated code.

And the transport layer will help by connecting these generated codes from client side and the server side. This layer will transport messages back and forth and allows the client and server to communicate.

gRPC structure — from a plurasight lesson By Mike Van Sickle

Life Cycle of gRPC

RPC life cycle — from a plurasight lesson By Mike Van Sickle

Creating the channel is the first thing to do. This is only one time process. Once the channel is created you can use it for the communication through out the applications life cycle.

Next is creating the client, which is a must component. It initiates the request which is to be sent to the server. This request can be embedded with meta data. One of the main purpose of sending and receiving meta data it to confirm the communications. Authentication is one example.

Finally in the life cycle, the messages will be sent back and forth.

The standardization effort was supported by Chrome, Opera, Firefox,[11] Internet Explorer 11, Safari, Amazon Silk, and Edge browsers.[12] Most major browsers had added HTTP/2 support by the end of 2015.[13] About 98% of web browsers used have the capability,[14] while according to W3Techs, as of August 2020, 47% of the top 10 million websites supported HTTP/2.[15]

gRPC is supports HTTP/2, so it is worth learning and practicing.

Let’s talk about authentication

gRPC — Authentication

This is not the user level authentication or rejecting and allowing features based on the user role. This authentication is the mechanism where it uses to recognize the client and server to have a secure connectivity.

Simply this is to recognize one another and to know they communicate securely.

gRPC has 4 different authentication mechanisms.

1. Insecure — Does not has any type security measures
2. SSL / TLS
3. Google Token based authentication
4. Custom authentication service providers

Let’s discuss about each of above separately.

Insecure

Here, the client and server will communicate each other on top of HTTP/1. It is basically the clear text communication. I don’t have to emphasis about the risk when communicating such a way, but often use this in the development environment. Recommend not to use in the production. To use this mechanism, there will be no special handling. Which means we don’t have to talk to any CA s of validate any certificates.

SSL / TLS

Once we have SSL / TLS as the authentication mechanism our data going back and forth is protected. This uses HTTP/2. HTTP/2 does share information faster and efficiently than HTTP/1. So.. That advantage is also there. And the other thing is that the client validates the certificates.( Client communicated with certificate authority to see whether the certificate is valid or not. )

Google Token Based Authentication

This mechanism must be on top of a secure authentication mechanism. Which means Google token based authentication works on top of SSL / TLS.

Custom

When we talk about custom authentication, OAuth comes to the mind. Anyway it is not yet supported with gRPC. This is language specified, you could develop your own.

gRPC Communication Options

We can call them as message types too. Here we can find out 4 methods of options.

1. Unary — Simple request and response
2. Server Streaming — Server streaming data back to the client
3. Client Streaming — Client streaming data up to the server
4. Bidirectional Streaming

Unary RPC

This acts as the normal request response within client and server. Client can create the request to the server. Server will process it and sends the response back. So this will be a single request and a single response in the procedure call.

rpc methodName(RequestType) returns (ResponseType)

this requires a Request type and a Response type even there is no data.

Server Streaming RPC

In here the request response pipeline stays as same as above. But instead of a single request and response server can send many responses while it processes the request or once complete processing the request. Simply what is does is streaming data back to the client.

ex: Streaming a video

rpc methodName(RequestType) returns (stream ResponseType)

Client Streaming RPC

This is the reverse of the server streaming. I ll start with an example. Think of a uploading scenario like we should send multiple chunks to the server to be processed. Specialty is the server waits until it receives the full request and at the end server sends back a single response.

rpc methodName(stream RequestType) returns (ResponseType)

Bidirectional Streaming RPC

This is little bit crazy because the requests and response both happen asynchronously. Array of data can be send one at a time and a array of data will be sends back one at a time as the response.

rpc methodName(stream RequestType) returns (stream ResponseType)

This concludes this episode, I’ll catch you with another article which explains how I tried gRPC with Node js.

References

gRPC

HTTP/2

REST vs gRPC | Why Milliseconds Matter | Yonego