Introduction to gRPC
“A high performance, open source universal RPC framework.”
That’s what the official website has to say on their homepage https://grpc.io/ . But why are we talking about this? Lets get to know a brief history of gRPC and then we would discuss more about all the whats and whys.
For around 15 years Google has been using a RPC framework internally and all of Google’s services communicate using this Remote Procedure Call (RPC) infrastructure named Stubby.
Now, this technology is available for everyone as part of the open-source project called gRPC. It’s intended to provide the same scalability, performance and functionality.
Let’s talk about the whats and whys..
Now we’ve done this before, back in around 2005 the developers were rapidly moving to REST from SOAP. Then after a few years, came GraphQL which is slowly shadowing the RESTful services. And now we’ve yet another framework to look into that is gRPC.
Whenever we design an architecture for a particular application, the primary thing we keep in account is to break down the feature based requirements into different services. There are times when we are building a service for an existing application and cannot just punch in the feature into the existing service, hence we build a new service and make them talk to one another. Modular services which are independently deployable are usually well-defined and easily maintainable.
What we want to stress here is on the communication between these services. For seamless communication the services need to agree on a lot of pointers:
- Data format
- Error formats and patterns
- APIs to do the data exchange
- Efficiency of the APIs
- Scalability
- Load Balancing
- Authentication and much more…
Not only would we want to take care of the above pointers but also want to be able to communicate seamlessly between the services that are not written in the same language.
gRPC is a fundamentally good protocol and adopted by many other languages. It presently supports 11 different languages.
Let’s talk about gRPC some more. It is a protocol built on HTTP/2. From a high level perspective, you can define Request and Response for the Remote Procedure Calls (RPC).
The basic thing you need to get started is define the messages and services using Protocol Buffers. You will do this by writing proto files i.e. with the extension .proto, this single proto file can work for 11 different languages. Lets see what a simple proto file may look like:
There are many reasons to use protocol buffers but some of them are:
- Can be generated for almost any language.
- Deals with binary data and hence is efficient.
- Convenient option for transporting huge data.
You could say, why not REST? I am happy working with it. Well, yes I was pretty comfortable with that too. But there are certain drawbacks which I have faced in my course of development and hence decided to go for gRPC. Let me list down a few:
- Streaming in REST APIs is a tough nut to crack.
- No Bi-Directional streaming.
- Tough to get huge resources in a single request.
- No contract defined between service and client.
Now, I am not saying stop using the REST paradigm, but if I have a better solution for my requirements, I would definitely use it.
So, hopefully I have given you a brief idea about what gRPC is all about, but I know that’s not enough unless you play around with it and get more comfortable. In my next article I would be discussing this framework with examples that will make this more comfortable to adopt.
Keep Learning!
