In conversation with Google’s gRPC | Part1

6 min readMar 13, 2022

Question:- How does the world of Micro-services looks like today ?

Answer:- Today’s world is to build micro-services and you’ve heard it before and micro-services built in multiple languages shall cover your business functions. For example, Let’s take another example of below scenario :-

Buying-Service where users buy things right.
It may connect to another micro-service written in another language called Promotional-Service.
There may also be a Delivery-Service micro-service that will provide you with the service.
Next, we have a User-Service which talks about the users and their journey.

So, all in all you get a lot of micro-services in many different languages and they have to talk to each other.

Question:- What all is involved when two or more Micro-services exchanges information amongst themselves ?

Answer:- When two or more Micro-services exchanges information amongst themselves, following stuff are involved :-

Question:- Let’s talk about what all intricacies are involved, while we are designing any API ?

Answer:- Following are the things we need to deep dive, when we are developing any micro-service :-

Above list actually, is sufficient to scare anyone who is stepping their foot in the world of building a micro-service OR Restful API.

Question:- Does there not exists any framework, which can solve all of the listed problems above ?

Answer:- Well, there exist a glossy framework, known as gRPC :-

Question:- Ok, let’s get back to basics, what is an RPC ?

Answer:- It’s a remote procedure call in your client code. Basically, it looks like that, we’re going to be calling the function directly on the server.

Say, we have a function named createUser hosted @ server side.
Also, we have a function-call to createUser in client code.

So, as you can see in yellow-colour, the client code, directly run the function on the server, but something is happening over the network here. And that is what is called a RPC. And that’s what makes our RPCs great.

Question:- Is RPC a new concept ?

Answer:- RPC is not a new concept. It’s implemented very cleanly since many years ago.

Question:- How do we get started with gRPC ?

Question:- How does a sample-proto file looks like and explain it’s basic working ?

Here, we have a “Greeting” message.
We get a predefined “GreetingRequest” message and similarly a “GreetingResponse”.
At very bottom, we have a “GreetingService” that accepts GreetingRequest and returns the GreetingResponse.

Question:- Why are Protocol-Buffers in demand and widely preferred ?

Question:- Which all companies have used Protocol Buffers ? Why is this euphoria ?

Question:- What’s the fundamental ideology with which Protocol-Buffers works ?

Question:- Why gRPCs uses Protocol-Buffers why not JSONs for communications ?

Reason #1.) Lot of network-bandwidth is saved.

Reason #2.) Enhanced efficiency in communication on smaller devices.

Question:- Can we read Protocol-Buffers with our naked eyes ?

Answer:- We can’t read this using our eyes as it’s a byte buffer protocol that you won’t understand anything about. This will be less CPU intensive.

Question:- Can gRPC be used in any language, to build micro-service ?

Answer:- Yes, of-course, gRPCs are language-agnostic and can be used to code with any language. For example :-

Question:- What are the advantages of using Protocol-Buffers ?

Question:- Lets talk about the types of APIs available in gRPC ?

Answer:- There are following types of APIs available with gRPC :-

Unary → This is how a traditional API looks like with usual request/response. The client shall send one message to the server and would receive one response from the server. Unary RPC calls are well suited, when data to be transferred is small.
Server/Client/Bidirectional Streaming → With HTTP/2, we have streaming capabilities i.e. server and client can push multiple messages as part of one request. We can use these streaming RPC calls , if we have scaling and optimisation issues.

Question:- Lets talk about Unary vs others little more ?

Question:- Lets define the APIs/Services through gRPCs using ProtoBuffs ?

Answer:- Below is how we define the APIs (i.e. Protobuf Services) using gRPC :-

Question:- How do we achieve massive scalability using gRPCs ?

Answer:- Yes, it’s very much possible to scale the APIs/Services using gRPCs. To share a proof of scalability (as taken from google docs), Google have >10 billion of requests being made per second internally, which they serve using gRPCs.

Question:- Let’s talk about Security with gRPCs ?

Question:- Let’s revisit, how does a RESTful API works with HTTP/1 ?

Question:- Can you talk about the differences between REST & gRPC ?

Answer:- Following are the differences between REST & gRPC :-

REST shall be using JSON as data-transfer standard which would be slower, bigger and text-based while gRPC uses the protobuf as data-transfer standard which are smaller and faster in nature.
REST uses the HTTP/1.1 while gRPC uses the HTTP/2 which is lot more faster and efficient.
REST only supports Client to server calls while gRPC supports bidirectional and async calls as well.
REST only supports request/response while gRPC supports streaming capabilities as well.
REST is purely Resource-oriented while gRPC is purely API oriented with free-design.
REST supports auto-code-generation using swagger and openAPI as 2nd class citizens while gRPC supports auto-code-generation using prtobuf as 1st class citizens.
REST is Verbs based and thus we have to basic plumbing ourselves while gRPC is RPC based i.e. we can invoke the functions at server easily.

Question:- Let’s conclude our learnings about gRPCs by now ?

That’s all in this section. If you liked reading this blog, kindly do press on clap button multiple times, to indicate your appreciation. We would see you in next series.

References :-

In conversation with Google’s gRPC | Part1

Written by aditya goel