gRPC – What the hell is it ???

5 minutes to read read

In the modern everything is evolving very rapidly, and so is Web and standards. From SOAP to REST, standards have been shifting, but they seemed to have been stuck for a while while with the REST. Well, now again the ball is getting rolling with gRPC, the latest kid in the town. Not only it has all the latest and cool gadgets in its pocket, it is fast, really fast secure and can solve some of the typical problems that have been with since ailing the normal REST communications.

But.. There is always a but.. But, there are always two side of coin with all flexibility, there are some challenges. This is first part of the 3 article series on gRPC, what – why and how series including the handon demo. So without wasting time, lets dive in. This is a bit theoretical shit. For quick codies, you can jump to implementation in next article.

What is gRPC

As per wikipedia:

gRPC (gRPC Remote Procedure Calls) is an open source remote procedure call (RPC) system initially developed at Google in 2015. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts.

https://en.wikipedia.org/wiki/GRPC

gRPC is light weight protocol that has the capability to replace the REST for communication between “two endpoints”. Note that I used the word two endpoints, and not server client. This is because the two parties could be server-server or server-client or could be anything. gRPC is probably a better fit for service to service communications in a microservices based design. Lets see some of the problem are there in current HTTP 1.1 based REST which gRPC tries to solve.

Latency

Normal REST protocol based on HTTP1.1 requires a handshake for each call. Also, for each separate call being sent to server, this end to end latency increases.

Head of Line Blocking

Head of line blocking is the number of requests that can sent or received on a particular domain. In general, its 6-7. Although minification and bundling helps a bit, but again, if there are a number of resources in a call, not all can be fetched in parallel.

No Contracts

In a normal REST communication over HTTP 1.1, there is no contract in perspective of protocol. What this means is that any request you sent to server (with any payload) is valid and will be accepted. Further its the responsibility of the web application to do whatever validation required.

How does gRPC help

Firstly its based out of HTTP/2 protocol which is an advantage over HTTP 1.1 and provides inherent advantages to overlying system.

Well, gRPC has taken all the cream from HTTP1.1 that is better, and moved on to HTTP/2. Also, it is binary protocol i.e. its small in size and fast. gRPC also makes use of multiplexed streams which means that on the same set of connection you can request multiple calls in parallel.

Strong Typing

gRPC is runs on contracts as defined by protocol buffers (aka prota). In general REST uses Json (and some dorks using xml) but each of these requires serialization into native objects without validation from protocol side. Although these are textual and thus human readable, but increases the size a lot.

With ProtocolBuffers, it provides highly efficient and compressed binary payloads which are sent and processed faster. Also, this provides support for strong typing and strict contract validation directly with in the protocol.

Code Generation

REST is a very good system if implemented and practices well. With all the Get, Post, Put, Patch, Delete,…. its provide a very good conceptual model and design to work with. But when going to ground, there are very less system that actually implements it and use it well. Reason– its very tricky and difficult to implement. There is a very thin line, which is generally missed out.

With gRPC, its more like a level of abstraction. All the part of verbs and nouns are basically removed and moved out in line with interfaces. This makes it more analogous to OOPs based system, where there are interfaces and classes implementing them. Because of this, code generation for creating stubs and services for gRPC is easier. Both client and server side pluggable code can be easily generated with standard code generators.

Streaming

Any of you reading this know well that REST is a request response model. What this means, is that a request is initiated from client, and response is sent by the server. With no apparent support for streaming or sending multiple messages, libraries and implementation generally tend to move towards workarounds like sending messages in loop or using WebSockets. However, with many of those approaches, there is always a new connection being initiated by client (or server) and has all drawbacks around that. Also, this is not natively supported with REST.

With HTTP/2 streaming is provided for ‘free’. This implies with in the protocol you have the option for sending continous streams of message either way. gRPC uses this from base protocol to provide multiple streaming options.

Different type of communications from HTTP/2 protocol:

  • Single time or Unary
  • Client to Server Streaming
  • Server to Client Streaming
  • Bidirectional Streaming.

Push Communication

So far, personally speaking wherever there have been a requirement for streaming, always have fallbacked on SignalR which has certain issues such as server affinity when load balancing, which are difficult if not impossible to tackle unless moving to Managed services such as Azure SignalR.

With gRPC Server to Client Streaming (or any other way round) this is simplified and I now have another option rather then just the depending on one of the option.

But.. There are some cons when using gRPC.

Well, first problem is the very the binary nature. This makes it small and fast, but also remove the human readability. This can be troublesome for developers while developing and troubleshooting.

Limited browser support is another issue. In most cases, unlike REST, gRPC cannot be used natively in browser without any external plugin or module.

Limted user and developer support is also major factor that can pull back some of the developers from moving towards it.

Potential Use Cases

With the major drawbacks mentioned gRPC can still be a best fit in certain cases.

  • Service to Service Communication in a microservice based design
  • Anywhere where a client is custom written such as Android or desktop application.
  • Realtime communications – Removing SignalR and moving to gRPC can be better choice.
  • Bandwidth and network constrained environment – Since it runs across multiple languages, and communication is lightweight, it can be used in constrained environments such as remote sites or IOTs

Development with .netCore

While many of the languages have custom implementations, as in with my experience in .net, it was always tedious. However, with .netCore 3, it changed inversely. Its easier, more then ever to start with. In the next few articles, I shall share how to start with gRPC in .net Core 3.1 with almost any configuration such as one time or streaming in less then an hour or so. So keep watching.

Please put in any comments or queries below.

Leave a Reply

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