gRPC — Think Beyond REST

RPC is a way to call remote service in the early days and it helps to create disctributed architecture, ofcourse there are bottleneck in RPC. Here i am just writing how RPC get evolve and how it is modified by giant organization i.e.Google to overcome the limitation that exists in RPC and in current era same is struggling with REST. Since now a days working on microservice so of course we all face issue of performance in terms of latency and interservice communication.

Before going further lets clear what are the challenge to use RPC in microservice archotecture:-

1. Technology Coupling: Technology like Java RMI is heavily dependent on the platform.
2. Local calls are not like to remote calls: The cost of marshaling and the un-marshaling cost is significant, and the dependency of the network is high.
3. Brittleness: if any of the server method change, need to generate client stub again.

Google provide the solution to overcome the RPC challenge and it is only for performance because latency even millisecond matters for response.

Google came up with the gRPC with the solution that was facing in RPC call.

1. Machine-oriented payload: First and foremost if we are using RESTfull architecture, even service to service communication happens through heavy JSON/XML which is more compatible for humans, not for machines. But gRPC communicates using a lightweight binary format.
2. Streaming Capabilities: gRPC allows stream data, which is not available in the REST architecture solution. When your client & server is dealing with a large amount of data or a time-consuming process, gRPC streaming is the best solution.
3. Polyglot environments: According to gRPC official documentation, they already support C# / .NET, C++, Dart, Go, Java, Kotlin/JVM, Node.js, Objective-C, PHP, Python, Ruby. And most importantly it provides code generations out-of-the-box for many programming languages.

Core Concepts

With gRPC we can define our service once in a .proto file and generate clients and servers in any of gRPC’s supported languages, which in turn can be run in environments ranging from servers inside a large data center to your own tablet — all the complexity of communication between different languages and environments is handled for you by gRPC. We also get all the advantages of working with protocol buffers, including efficient serialization, a simple IDL, and easy interface updating.

In order to define both the service interface and the structure of the payload messages, gRPC uses google developed Interface Definition Language (IDL) called protocol buffers.

We can create <file-name>.proto file under a proto folder and gRPC maven plugin smart enough to generate message classes and service definition by referring protocol buffer file.

Example

syntax = “proto3”;

option java_multiple_files = true;

option java_package = “com.demo.models”;

message Car {

string make = 1;

string model = 2;

int32 year = 3;

BodyStyle body_style = 4;

}

enum BodyStyle {

UNKNOWN = 0;

SEDAN = 1;

COUPE = 2;

SUV = 3;

}

Maven will generate Java classes for integration or it depends on which environment you are working. If you are using .net it will c# classess for integration so it is polygot in nature. In next article will discuss what are the different ways to call method and how it is useful and advantages over REST.