This post is about a process I attempted, and succeeded in - Google’s Remote Procedure Call or gRPC, the next level communication on HTTP/2. All this time I used to write REST APIs. I was aware that there are some alternative ways for this, however I had never tried any. In the meantime, I heard about gRPC and thought to try it. This is my experience with gRPC.

This post, first of a series, is a basic introduction to gRPC.

As software engineers (API developers) it is our duty to make inter-service communication better. There are two main options for inter-service communications.

• REST (Representational State Transfer)
• RPC (Remote Procedure Call)

 

REST (Representational State Transfer)

Sends resources back and forth and manipulates those resources.

 

 

 

 

RPC (Remote Procedure Call)

This differs from REST by involving functions and procedures whilst REST is based on resources.

 

 

However, expectation from both options are the same.

 

Why RPC than REST?

REST uses text-based messaging and HTTP semantics for communication. RPC has the following features and it paves way for better clarity when communicating with services.

• It is actions focused
• It uses programming semantics
• It uses binary based messages (very small compared to text in REST)

 

Important facts about gRPC

• It’s fast and efficient
• It supports cross-platform apps
• It is scalable
• It enables streaming — not designed to a single request and response, it can manage a group of requests and expect a single response or vice versa
• Free-and-open- No cost to use and the source is available

Ultimately, gRPC allows all other different technologies (languages) to talk to each other natively irrespective of the language the service is written.

 

gRPC Structure

As we are aware, most of the systems consist of at least one server and one client. Even though it does not have to be one-to-one map, multiple servers and multiple clients are possible. Server is responsible for processing the request and responding accordingly. Client is responsible for sending the request to the server and wait 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.

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 allow the client and server to communicate.

 

 

 

Life Cycle of gRPC

 

 

 

Creating the channel is the first thing to do. This is a one-time process. Once the channel is created you can use it for communication throughout 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 purposes of sending and receiving meta data is to confirm the communications. Authentication is one example.

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

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

 

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

Let’s talk about authentication.

 

gRPC — Authentication

This is not the user level authentication nor rejecting and allowing features based on the role of the user. This authentication is the mechanism where the client is recognised and server obtains secure connectivity.

Simply, this is to recognise one another and to assure secure communication.

 

gRPC has 4 different authentication mechanisms.

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

 

Let’s discuss about each of the above separately.

 

Insecure

Here, the client and server will communicate with each other on top of HTTP/1. It is basically clear text communication. I don’t have to emphasise the risk when communicating in such a way, but this is often used in the development environment although it is recommended not to be used in production. To use this mechanism we don’t have to talk to any CA or validate any certificates.

 

SSL / TLS

Once we have SSL / TLS as the authentication mechanism, data going back and forth is protected. This uses HTTP/2. HTTP/2 shares information faster and efficiently than HTTP/1. That is an added advantage. Moreover, the client validates the certificates. (Client communicates 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 it comes to custom authentication, OAuth comes to mind. However, it is not yet supported with gRPC. This is language specified and you could develop your own.

 

gRPC Communication Options

These are known as “message types” too. There are 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 send the response back. 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 though there is no data.

 

 

Server Streaming RPC

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

 

E.g. Streaming a video

 

rpc methodName(RequestType) returns (stream ResponseType)

 

 

Client Streaming RPC

This is the opposite to server streaming. For e.g. Imagine of an uploading scenario where we have to send multiple chunks to the server to be processed. Difference is, server waits until it receives the full request and at the end, it sends back a single response.

 

rpc methodName(stream RequestType) returns (ResponseType)

 

 

Bidirectional Streaming RPC

This is a little bit crazy because the requests and responses both happen asynchronously. An array of data can be sent, one at a time and an array of data will be sent back, one at a time as the response.

 

rpc methodName(stream RequestType) returns (stream ResponseType)

That concludes this episode, I’ll catch you with the second part where I explain how gRPC was tried with Node JS.

---

---