In conversation with Google’s gRPC | Part1
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.