Guide what gRPC is, RPC protocol and the necessities for this tech. We will start checking a bit of RPC protocol, then we will see what gRPC solves from a few problems with REST architecture.
RPC protocol
Remote Procedure Call (RPC) is a protocol that one program can use to call another programs procedure in a remote machine without worrying about network architecture. RPC uses a client-server model, with the client initiating the request and with the server providing a service.
A few obstacles from REST architecture
REST is a great resource based software model, is easy to get started with it and shines in building light web services that can be consumed by every program or service which can make use of HTTP protocol and JSON which became a standard because of the XML processing problems from client languages. As every other architecture, REST comes with a few problems.
Not every client application is a browser
Nowadays the world is heading to interconnected services, whether we like it or not you can't fix every problem with monolith styled applications, so what we came up is adding small apps/services, that can take care of small requirements. Now since those apps are developed with some backend technology, why would one choose to make use of raw HTTP calls by hand instead of going for the SDK ?! Take for instance the Dropbox API, you have a plain HTTP option if you like, but there are six other SDK packages for six different languages, which make devs life easy.
Different services are built in different languages
Within the same company (consider a small one, with 2-3 divisions), different departments are probably using different languages to build their services. If you see the Dropbox API sample again, to maintain all their SDKs they should work with .Net, Java, Python, Objective-C, Swift, and Javascript, so, adding a new feature? 6 teams up, 6 different boards with only one thing in common, feature name.
The need for speed
Remember step one where we solved our puzzle by introducing a microservice-oriented architecture? Well with this model performance becomes a keep-in-mind-while-coding thing. It might not be the biggest problem for the developer when working with a service-oriented model but it still remains as a decision making aspect. Making a request? After authentication and model specifics you will do something like:
- Serialize the object to JSON/text
- Send it over the network
- Deserialize the retrieved string to object
- Response with another serialized object, which in turn probably has to be deserialized again
Feeling dizzy yet? Expressing an object as text(JSON) so humans can understand and the machine can convert it back takes a lot of time and memory! While some sort of convertion will take place in most systems, text makes payload bigger, therefore causing network issues.
gRPC to the rescue
A high-performance, open-source universal RPC framework
gRPC its an RPC framework build by google initially under name Stubby for internal purposes, then updated for community usage to be an OSS under name gRPC. If you have a microservice-based architecture system, there is a good change gRPC is a good fit for your architecture. So, how does gRPC helps the dev to overcome problems introduced in the first part?
Protocol Buffers
Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler.
Consider a simple entity with three properties: Id, Name and Email.
Here is a JsonSchema to represent it:
{
"type": "object",
"properties": {
"Id": {
"type": "integer"
},
"Name": {
"type": "string"
},
"Email": {
"type": "string"
}
},
"required": [
"Id",
"Name"
]
}
Now here's how we could express it using Protocol Buffers:
message User {
required string name = 1;
required int32 id = 2;
optional string email = 3;
}
.proto files are used to describe the interfaces that you build, using protoc compiler you could generate ready to use code for 12 different languages, giving the developer type-safety and comfort of making remote calls in the same manner such as another class of the current application.
Binary serialization
Data serialization in gRPC is done in binary, this results in smaller and simple (machine point of view) payloads, therefore faster responses.
Bi-directional streaming and integrated auth
gRPC is built on HTTP/2, which explicitly supports bi-directional streams. This means that the client can request data while the server is sending a response back. On top of this, authentication (app authentication) is also supported out of the box. gRPC promotes the use of SSL certificates to authenticate a client/server and encrypt the data exchanged between the two. Follow grpc.io for more information.
In the next article I'll show how to use gRPC framework to build a Server-Client example using C#
