A high-performance, open-source universal RPC framework
gRPC is an open-source remote procedure call (RPC) system initially developed at Google in 2015. It leverage HTTP 2 for transport, with Protocol Buffers as the interface description language (IDL).
It has features such as authentication, bidirectional streaming, flow-control, blocking, non-blocking bindings and timeouts.
RPC, as a framework is very old, initially termed so and used in distributed computing in 1980. gRPC is a modem, open-sourced evolved version of several RPC implementation out there, that is universally accepted
How does it work?
In simple English, gRPC, provides a framework using which, a program on a server (gRPC client) can invoke a function or program on other server (gRPC sever), without making you feel like its calling a function on another server. gRPC is also language agnostic, meaning that client and server may have been implemented using different programming languages
In the illustration above, assume we have a microservice (let’s label it A) written in C++, having protocol buffer with gRPC server running. Assume we have another microservice written in Ruby (let’s label it B).
When microservice B, needs to serve an endpoint request that needs a procedure to be invoked on microservice A, it defines a stub for that procedure that in turn invokes that procedure via protocol buffer. Upon receiving the response, it can curate the response to serve the pending request.
gRPC clients and servers can talk to each other in a variety of environments, like both client and server can be running on the same system or distributed over the network
Protocol Buffers
By now you already aware that gRPC uses Protocol Buffers, A mechanism to serializing structured data. Here’s a quick intro to how it works.
The first thing to do is to define structure for data you wish to serialize in a .proto file. The structure is known as message, where each message is a small logical record that can hold information, as in name-value pairs known as fields. Here is an example:
message Person {
string name = 1;
int32 id = 2;
bool has_ponycopter = 3;
}
Once we have specified data structure for a message, we use protocol buffer compiler protoc to generate data access classes in a language that client or server is written in. Now we have simple accessors for each field, like getter and setter for each attribute, as well as methods to serialize/deserialize structure
You define gRPC services in ordinary proto files, with RPC method parameters and return types specified as protocol buffer messages. Let’s say we wish to say invoke sayHello procedure that would need name as parameter, so we define a message proto
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
Similarly, since we would be expecting a response in a certain format, we need to have proto defined for that as well
// The response message containing the greetings
message HelloReply {
string message = 1;
}
In end, we need to invoke remote procedure say SayHello we would do something like following
// The greeter service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
gRPC uses protoc with a special gRPC plugin to generate code from your proto file: you get generated gRPC client and server code, as well as the regular protocol buffer code for populating, serializing, and retrieving your message types.
Thanks for reading, request you to please follow this publication for more update
About The Author
I am Pankaj Baagwan, a System Design Architect. A Computer Scientist by heart, process enthusiast, and open source author/contributor/writer. Advocates Karma. Love working with cutting edge, fascinating, open source technologies.
To consult Pankaj Bagwan on System Design, Cyber Security and Application Development, SEO and SMO, please reach out at me[at]bagwanpankaj[dot]com
For promotion/advertisement of your services and products on this blog, please reach out at me[at]bagwanpankaj[dot]com
Stay tuned <3. Signing off for RAAM