gRPC

google(?) Remote Procedure Call (gRPC) is a new smart way of data transport and remote execution. It was born as a very hard alternative against the REST APIs. Powered by Google, its website defines it as. 

RPC + Protocol Buffers = gRPC

In 2001, google internally launched a framework and transport protocol that allowed serializing data in a more efficient and effective way. He called it protocol buffers.

Later, in 2006, it decided to release this framework as open source, and its use began to generalize.

Its operation is simple. The data models are defined and then the code generator is invoked for the desired language: C ++, Java, JavaScript, etc.

It is very efficient and effective because the data goes binary representation and the least information overhead is used. 

It is much more efficient than any other protocol based on XML or JSON.

On the other hand is Remote Procedure Call, developed by UNIX in 1982. His idea is the remote invocation of procedures and was one of the most used client-server architectures.

A few years ago, it underwent a transformation towards XML-RPC, where XML was used as serialization of messages.

The Google team saw that adding the function declaration to the Protocol Buffers (PB) specification, it was relatively "easy" to implement RPC over PB.

He shaped it and so was born gRPC.

gRPC Internals

An example of service specification can be the following.

	
	syntax = "proto3";
service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse);
}
message SearchRequest {
   string query = 1;
}
message SearchResponse {
  repeated Result results = 1;
  int32 numResults = 2;
}

message Result {
  string title = 1;
  string brief = 2;
  float weight = 3;
  string link = 4;
}

You can easily verify that an API is specified for search where a list of results is returned (SearchService). 

When compiling the specification with "protoc" and indicating the resulting language (Go, TypeScript, Java, ...) we have the stubs ready to implement.

The transport protocol used is HTTP/2. 

This brings all the benefits of HTTP/2: support bidirectional flow, header compression, TCP multiplex, server push etc.

The data is serialized in binary messages efficiently.

gRPC Web

Unfortunately HTTP/2 is not yet supported by most browsers in the way that gRPC expects. Although APIs are available as "fetch", it still does not support gRPC as such.

But this is no problem for gRPC to work correctly in Web browsers and/or WebView-based applications (Ionic, Cordova, ...) thanks to gRPC-Web.

It is a proxy that is installed on the backend and that adapts the gRPC calls to Fetch/XHR. It is totally transparent and works very well.