My experience with Google’s Remote Procedure Call (gRPC)

This post is about a process I attempted, and succeededin - Google’s Remote Procedure Call or gRPC, the next level communication onHTTP/2. All this time I used to write REST APIs. I was aware that there aresome 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 togRPC.

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

·        REST (Representational State Transfer)

·        RPC (Remote Procedure Call)

REST(Representational State Transfer)

Sends resources back and forth and manipulates thoseresources.

                               REST communication — from a Plurasight lesson By Mike Van Sickle

RPC (Remote ProcedureCall)

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

                                    RPCcommunication - from a Plurasight lesson By Mike Van Sickle

However, expectation from both options are the same.

Why RPC thanREST?

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

·        It is actions focused

·        It uses programming semantics

·        It uses binary based messages (very small compared totext in REST)

Importantfacts about gRPC

·        It’s fast and efficient

·        It supports cross-platform apps

·        It is scalable

·        It enables streaming — not designed to a single requestand response, it can manage a group of requests and expect a single response orvice versa

·        Free-and-open- No cost to use and the source isavailable

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

gRPCStructure

As we are aware, most of thesystems consist of at least one server and one client. Even though it does nothave 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 theresponse. In gRPC both the server and the client will have a generated codewhich allows the connection between the client and the server. The conversionof the code to the desired language is abstracted under that generated code.

The transport layer will help byconnecting these generated codes from client side and the server side. Thislayer will transport messages back and forth and allow the client and server tocommunicate.

                                                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 thefirst thing to do. This is a one-time process. Once the channel is created youcan 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 theserver. This request can be embedded with meta data. One of the main purposesof sending and receiving meta data is to confirm the communications.Authentication is one example.

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

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

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

Let’s talk about authentication.

gRPC —Authentication

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

Simply, this is to recognise oneanother and to assure secure communication.

gRPC has 4 differentauthentication 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 eachother on top of HTTP/1. It is basically clear text communication. I don’t haveto emphasise the risk when communicating in such a way, but this is often usedin the development environment although it is recommended not to be used inproduction. To use this mechanism we don’t have to talk to any CA or validateany certificates.

SSL / TLS

Once we have SSL / TLS as theauthentication mechanism, data going back and forth is protected. This usesHTTP/2. HTTP/2 shares information faster and efficiently than HTTP/1. That isan added advantage. Moreover, the client validates the certificates. (Clientcommunicates with certificate authority to see whether the certificate is validor not).

Google TokenBased Authentication

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

Custom

When it comes to custom authentication, OAuth comes tomind. However, it is not yet supported with gRPC. This is language specifiedand you could develop your own.

gRPCCommunication Options

These are known as “message types” too. There are 4methods of options.

5.     Unary — Simple request and response

6.     Server Streaming — Server streaming data back to theclient

7.      Client Streaming — Client streaming data up to theserver

8.     Bidirectional Streaming

Unary RPC

This acts as the normal requestresponse 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 singlerequest 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 responsepipeline stays same as above. But instead of a single request and response,server can send many responses while it processes the request or once theprocession is completed. Simply what it does is streaming data back to theclient.

E.g. Streaming a video

rpcmethodName(RequestType) returns (stream ResponseType)

Client Streaming RPC

This is the opposite to serverstreaming. For e.g. Imagine of an uploading scenario where we have to sendmultiple chunks to the server to be processed. Difference is, server waitsuntil it receives the full request and at the end, it sends back a singleresponse.

rpc methodName(streamRequestType) returns (ResponseType)

Bidirectional Streaming RPC

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

rpc methodName(streamRequestType) returns (stream ResponseType)

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

‍