gRPC A Communication Framework meant for Scale

gRPC is a recursive acronym for gRPC Remote Procedure Call. gRPC was invented because it solves the biggest problem with client libraries. Which is to maintaining it.

Some points to note for gRPC -

• it is an open-source Remote Procedure Call Framework developed by google.

• It uses HTTP/2 Protocol as an underlying transport mechanism.

• It uses Protocol Buffer as a messaging format.

Why does it Exist?

gRPC was invented to solve the biggest problem with client libraries that are built on top of protocol specifications like HTTP, webSockets.

If you are using web development frameworks and runtime like NodeJS, Django, EmberJS.

But what is client library exactly

Client library is the actual library that enables communication between your backend system and user accessing your page in browser.

Consider an example HTTP/1.1. When a user sends a request to your backend the browser generates the request and establishes TCP connection with the backend. But how will your backend server understand what it has received from the browser? How will it know to setup and maintain TCP connection with the client? This is where Client libraries come in. Client libraries help understand the protocol the browser is communicating in.

Client libraries help in many this -

• It make sure to Establish a TCP.

• It make sure to understand HTTPS.

• It make sure to understand TLS 1.2 and 1.3 negotiations.

• It make sure to negotiate Application Layer Protocol Negotiation.

• It makes sure to enforce security features.

Client Libraries are lot of work. with every new release or change in protocol. All the Client Libraries have to be updated. Consider you are using an open-source client library and suddenly the maintainers of the project decide to no longer maintain the library. This puts you on your own to patch security features, understand and maintain the protocol yourself.

There are so many client libraries with varying level of implementations and security features. This gets to a point when developers get confused which on to use.

Browsers are indeed an example of what client library does

How gRPC solves this issue?

gRPC is set to standardise the entire protocol communication. Google has launched this project to officially maintain the client libraries for popular programming languages used for backend development. This means that you can use it fearlessly without worrying about being left on your own and maintain the project long term.

Features of gRPC

1. Performance - gRPC uses binary messaging format like protobuf which is lot faster to transfer that text based format.

2. Client Library - One client library for each popular language. This takes out confusion of choosing a client library and repenting later.

3. Protocol - By default it uses HTTP/2 which is way more performant than HTTP/1 and its also stateless.

4. Streaming Support - It enables 3 types of streaming client streaming, server streaming, bi-directional streaming.

5. Language Antagonistic - This framework can establish communication between backend services written in completely different languages without any additional configuration.

Modes of communication

gRPC support 4 modes of communications. This can help in all mode of communication requirements and do so in an elegant way. This also means that gRPC is a drop-in replacement for all the protocols we use for various types communication HTTP, Server Side Streaming, WebSockets, etc.

1. Unary RPC Just like HTTP it works like request-response. Client makes a request synchronously wait and server sends back a response.

2. Server Streaming RPC In this Client makes a request and server sends back response in form of small chunks of data as a stream.

3. Client Streaming RPC In this Client sends a stream of data to server. The server receives all the chunks of data and then sends back an acknowledgement response to the client.

4. Bidirectional Streaming RPC Both Client and Server communicate with each-other as an adhoc manner and send response to each other

Pros

1. Fast & Compact - It uses Protobuf as a messaging format which sends message in binary format. For every character you send you save 7 bits of memory. Also It uses HTTP/2 as underlying protocol which has more compression ability than HTTP/1.

2. One Client Library - We don't have to maintain any client library since its already managed for us by gRPC community.

3. Progress Feedback - For features like uploading to server we can use client side streaming.

4. Cancel Request - gRPC is stateful since HTTP/2 is stateful. This gives us the ability to cancel a request because in stateless environment it is impossible to do this. But gRPC provides a hook to listen to and whenever a cancel request is sent from the event.

Cons

1. Schema - Protobuf requires you to define schema before you send a request which is an aditional thing to learn.

2. Thick Client - gRPC generates client code based on your apis.

3. Nasant Support - Doesnt support all languages but few popular once like Java, C++, Python, Go Ruby, C#, Ruby, Android Java, Objective C, PHP, Dart, web.

4. Proxies - Not every proxy support gRPC