gRPC Fundamental and Concept
I believe lots of you might have already heard about gRPC or have already even using it for their own works and creations.
These past few days i have been exploring and diving deep into gRPC and I found a lot of interesting things. Today, I will be sharing those things through my writing.
This is not a implementation tutorial so you will not find the example of gRPC implementation in any of the languages like Java or Go.
Wait, don’t quit reading this article yet! I assure you that the one you will learn here is the fundamental and the core architecture of the gRPC itself. On why is it being used so often, why does it perform so well, why it is able to work that way.
Let’s go back a bit
Before we rush into gRPC section, it’s better if we take a look back into past, exactly into something called RPC or Remote Procedure Call.
RPC is a form of Client-Server Communication Method that uses a form of function call rather than usual http call.
It’s using IDL (Interface Definition Language) as a form of contract on functions to be called and the data type.
If you guys haven’t realized yet, the RPC in gRPC does stands for Remote Procedure Call. And yes, gRPC does replicate this architectural style of client server communication, via function call.
So gRPC is technically not a new concept, instead it was adopted from this old technique and improved upon, making it very popular just in the span of 5 years.
Here comes gRPC
Overview
In 2015, Google open sourced their project which eventually will be the one called gRPC. But what does gRPC stands for actually?
Lots of people might assume its google, of course because google made it, and google obviously starts with g right? Except it does not.
For some reasons google change the meaning of the g for each of the versions to the point where they even made a readme to have list of the g meaning. This kind of thing does sounds familiar for Google to do though (I’m looking at you Android).
Since it has been introduced back then, it has regained quite an amount of popularity till now and it has been adapted into a lot of companies.
What makes it popular
There are plenty of reasons why they are popular such as:
- Abstraction is easy (it’s a function call)
- Supported on a lot of languages
- Performance
- Http calls are often confusing
And literally all of the reasons above are covered in one major reasons why grpc is very popular, it’s because microservices are very popular.
gRPC is very popular in service to service call as often http call is harder to be described than having a real function to be called. Developer can forget all those hassle about detailing documentations, when the code itself is the will explain everything.
Some of the services also might have different languages each and gRPC comes with multiple languages library to support that.
Performance is the cherry on top, it’s a big cherry though.
gRPC Architecture
As i have mentioned several times that gRPC performance is very good, but you might wonder what makes it very good? What makes it so different from usual RPC when the design between both of them is pretty similar?
Here, I will describe the gRPC architecture so you guys will get the grasp on how gRPC reach it’s performance.
HTTP/2
HTTP has been with us since a long time ago. Now, almost all kind of backend services are using this protocol for their services.
As picture above shown, HTTP/1.1 stayed for a very long time and in the fast moving world of technology, it’s pretty impressive to be able to still stay relevant for that long.
In 2015, HTTP/2 came out and essentially becomes the great contender to replace HTTP/1.1 as the most popular transport protocol on the internet.
If you realized that 2015 was also the year where gRPC came out, it was not a coincidence at all. HTTP/2 was also created by google, to be used by gRPC in its architecture. HTTP/2 is one of the big reasons on how gRPC can reach its performance.
Request/Response Multiplexing
In a traditional HTTP protocol, is not possible to send multiple request or getting multiple response together in a single connection, a new connection will need to be created for each of them.
This kind of request/response multiplexing is made possible in HTTP/2 with the introduction of HTTP/2 new layer, called by binary framing.
This binary layer will do encapsulation and encoding of the data. In this layer, the HTTP request/response will be break down into frames.
Headers frame will contain the typical HTTP headers information and data frame will contain the payloads. By this mechanism, it will be possible to have multiple request data with a single data.
Inherently, this will allow multiple request payload with the same header thus identifying it as a single request.
Header Compression
Sometimes in our life, we might have encountered many cases where our http header is even bigger than our payload. And HTTP/2 fully agree with that. HTTP/2 has a very interesting strategy called HPack to handle that.
For one, everything in http/2 is encoded before being sent, that includes the headers too. It does help for the performance, but that’s not the most important thing about this header compression.
HTTP/2 will map the header in both client and server side.
From that, HTTP/2 will be able to know if the header contains the same value and will only send header value that is different with previous header.
As seen in above picture, request 2 will only send path since other values are the exact same. And yes, this does cuts a lot of the payload and in turns pumping http/2 performance even more.
Protobuf
If you remembered about IDL previously, protobuf is the most commonly used IDL for the grpc. This is where basically you will store your data and function contracts. In the form of proto file.
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
}As this is in the form of contract, both client and server side will need to have the same proto file, this will act as the intermediary contract for client to call any available functions from the server.
Protobuf has it owns mechanism also here, unlike usual rest api where it just sends over string of json that has been made into bytes.
This will allows the payload to have much smaller payload and enable faster performance, yes it’s all about payload here.
The encoding method is pretty complicated, if you want to deep dive more into it you can read this, they have a very comprehensive documentation on how the encoding works.
What’s more
Now more or less you should have understood the basic architecture of gRPC, how it works and its capability.
I will now introduce some interesting things that gRPC offers us.
Metadata
Instead of using usual header like http request, grpc have something called metadata. Metadata is a type of key-value data that can be set either from Client or Server side.
From Client side Header can be assigned while Server can assign Header and Trailers where both is the same type of structure (Metadata).
Streaming
Streaming is one of the core concept in grpc where several things can happen all together in a single request. This is made possible because multiplexing capability of HTTP/2.
There are several types of streaming:
- Server Streaming RPC
This is the case where client will send a single request and server can send back multiple response. Example of this: When client send request for homepage with multiple item list, server can send back responses separately, making client enable lazy loading. - Client Streaming RPC
Here, client will send multiple requests and server will only send back a single response. Example of this: Zip/chunk files upload by client. - Bidirectional Streaming RPC
This is streaming where both client and server will sequences of message all together without waiting for the response.
Interceptor
gRPC supports the usage of interceptor for its request/response. It will intercept the messages and allow you to modify it.
Does that sound familiar? If you have been playing around with http process on Rest API, it’s basically similar to one called middleware.
gRPC library will usually support this and allow an easy time for implementation.
Usually used for:
- Modify the request/response before being passed on. It can be used to provide mandatory information before being sent to the client/server.
- Allow you to manipulate each function call such as adding additional logging to track response time.
Load Balancing
If you guys aren’t familiar with the term of load balancing, in short it is a mechanism to allow client request to spread out among multiple servers.
Load balancing usually is done in proxy level (i.e.: Nginx). So why am I talking about this here?
The reason is because gRPC itself support a method of load balancing by client. The implementation is already in the library (at least in Golang) and it can be used with ease.
The implementation itself is not some sort of black magic, it has some sort of DNS resolver to get IP list and it owns LB algorithm.
Call Cancellation
Grpc client is able to cancel grpc call when it doesn’t need the response anymore, rollback on server is not possible though.
This feature is especially useful for server side streaming where multiple server requests might be coming. gRPC library comes equipped with its Observer method pattern to know if a request is cancelled and allow it to cancel multiple corresponding requests at once.
Wrapping It Up
What i shared today is just the surface of what gRPC is, but this should help you guys to understand about what gRPC is and what does it provides, how it roughly works.
I truly hope this article can help in learning and understanding grpc even more. There are still a lot more things about gRPC to be learned, so don’t stop here! Since you have only seen the surface of it.
Thanks for reading my article till the end.
Keep on learning and always keep your thirst knowledge, since this world comes with never ending supply of knowledge.
