Time to replace REST (HTTP/1.1) with gRPC (HTTP/2)

HTTP/2 is a new version of HTTP, that is a major update of HTTP after the introduction of HTTP/1.1 in 1999.

While communicating client with the server, HTTP/1.1 process one request per TCP connection, to process multiple requests simultaneously, the client uses multiple TCP connections in parallel. HTTP/1.1 works on request-response protocol where each connection supports pipelining. This supports single direction streaming but does not support bi-directional streaming. HTTP/1.1 supports SSL, but for that, it establishes an extra connection, that is complete one extra cycle. More connections result in more wait times.

GRPC is a high-performance, open-source universal RPC framework initially developed by Google. It uses Protocol Buffers to define service. It establishes one connection like a tunnel and sends all response in one communication.

Fig: Communication in HTTP/1.1 (REST calls)

In REST, there is a separate request and response for header, body, SSL, etc.. with a separate connection is required. But in gRPC, once a connection is established, the client sends one request and in turns service returns all the response in the same connection.

Fig: Communication in HTTP/2

gRPC is being supported by many languages and platforms. You can generate client and server stubs to communicate between client and server or between services using Protocol Buffers.

Below is officially supported language with supported compilers for gRPC:

• C/C++ (GCC 4.4, 4.6, 5.3, Clang 3.5, 3.6, 3.7, Visual Studio 2013+)
• C# (.Net core, .Net 4.5+, Mono 4+)
• Dart (Dart 2.0 +)
• Go ( Go 1.6 +)
• Java (JDK 8+)
• Node.js (Node v4+)
• PHP (currently in beta)
• Python (Python 2.7 and Python 3.4+)
• Ruby

The main usage scenarios for gRPC is:

• Efficiently connecting polyglot services in microservices style architecture.
• Connecting mobile devices, browser clients to backend services.
• Generating efficient client libraries.

Core Features that make it awesome:

• Idiomatic client libraries in 10 languages.
• Highly efficient on the wire and with a simple service definition framework
• Bi-directional streaming with http/2 based transport
• Pluggable auth, tracing, load balancing, and health checking

gRPC introduced three new concepts, that is channels, remote procedure calls (RPCs) and messages. The relationship between these three is: each channel can have many RPCs, and each RPC can have many messages. It has a one-to-many relationship between channels and RPCs, and again one-to-many relationship between RPC and Messages.

Channels are virtual connecting between endpoints, RPC is HTTP/2 streams, and messages are associated with RPC and get sent as HTTP/2 data frames. A data frame can have many messages, or if one message is too big it can span to many data frames.

Once connection established between client and server, it creates like a tunnel and keeps that tunnel open for communication. For each set of client and server communication, there is a separate tunnel, in that way it will make several connections and keep all connections open that make communication super fast.

Using Resolver and Load Balancer, gRPC keeps the pool of connections healthy, alive and utilized. When a connection fails, the Load Balancer will begin to reconnect using the last known list of addresses, meanwhile, the resolver will begin to re-resolve the list of hostnames. Once resolution finished, the Load Balancer is informed of the new addresses. To check the health of connection gRPC periodically sending HTTP/2 PING frames on connections to determine whether the connection is still alive.

Implementation:

To write gRPC server or client, first, we can define service in a .proto file and implement client and servers in any gRPC supported languages.

.proto file will look like this:

syntax = “proto3”;
option java_multiple_files = true;
option java_package = “grpc.test.testMe”;
option java_outer_classname = “TestMeProto”;
option objc_class_prefix = “TM”;

package testMe;


service Testing {
rpc SayMessage (TestRequest) returns (TestReply) {}
}

message TestRequest {
string test = 1;
}

message TestReply {
string test = 1;
}

Using .proto file, generate server and client using Protocol Buffer Compiler.

And in the final step, use gRPC API of respective language to write client and server.

Protocol Buffer is a mechanism for serializing structured data.

You can learn more about Protocol Buffer from :

https://developers.google.com/protocol-buffers/docs/proto3

gRPC service method:

You can define four types of service method:

1. Unary RPCs: In this method, the client sends a single request to the server and gets back a single response. Example: rpc SayMessage (TestRequest) returns (TestReply) {} This is like a normal function call.
2. Server streaming RPCs: In this method, the client sends a single request to the server and get a stream to read a sequence of messages until there are no more messages. Here gRPC guarantees message ordering . Example: rpc SequenceOfResponse (TestRequest) returns (stream TestReply) {}
3. Client streaming RPCs: In this method, the client writes a sequence of messages and send them to the server, once the client finished writing a message it waits for the server to read and send its response. Here gRPC guarantees message ordering. Example: rpc SequenceOfRequest (stream TestRequest) returns (TestReply) {}
4. Bidirectional streaming RPCs: This is a combination of Server streaming and Client streaming RPCs. In this method both send a sequence of the message using read-write streams. Here also gRPC guarantees message ordering in each stream. Example: rpc SequenceOfRequest (stream TestRequest) returns (stream TestReply) {}

Strategy to migrate from REST to gRPC:

we have already written lots of microservices using REST, to move those microservices to gRPC not too much pain if you will plan it correctly.

You have all business logic written in each microservices, a plan to change from REST to gRPC can have below steps:

• STEP-1: Design gRPC API for your similar REST API, for example. REST: POST test/nameAdd gRPC equivalent : rpc AddName( Name){ return NameIndex; } REST: GET test/name/{ nameIndex } gRPC equivalent : rpc GetName( nameIndex ){ return Name; }

• STEP-2: Run both REST and gRPC services initially, so that rest client and gRPC client both can have access of implemented services.

• STEP-3: Solve problem area, like health check and API discovery.

• STEP-4: Remove REST services.

Current HTTP/2 support:

This is a relatively new technology that big companies already started implementing, still, HTTP/1.1 (REST) is leading in current developments of microservices. Slowly more tools and support will come and confidence will build up for HTTP/2. For sure REST will become thing of past and industry will move to HTTP/2.