gRPC who?
gRPC is an open source, lightweight and high performance remote procedure call (RPC) framework, by Google. It uses HTTP/2 for communication, protocol buffers as the interface description language and as its underlying message interchange format.
What are protocol buffers? Another invention by Google, protocol buffers provide a mechanism for serializing structured data. They are language neutral and run on all platforms. You define the structure of data once, and then by using specially generated source code, can read/write heaps of data based on the structure, to and from a variety of data streams.

gRPC supports 4 different types of RPCs;
* Unary streaming; a standard communication process between client and server, initiated by the client with a single request, reciprocated by a single response from the server.
* Client streaming; here, the client sends a stream of messages to the server in the provided stream, and the server responds with a single message. Messages remain ordered within an individual RPC call, guaranteed by gRPC.
* Server streaming; the opposite of client streaming, the server returns a stream of messages in response to a single client request. Again, the order remains intact.
* Bi-directional streaming; with a read-write stream, and initiation from the client, this streaming method forms a channel of request and response between the two entities. The two streams operated independently, wherein the order of each stream is preserved.
gRPC vs REST
gRPC is faster than REST, given its usage of HTTP/2. REST performs well when the payload is small, even if there are several clients making a call to the server at the same time. However, if the payload is higher, gRPC becomes the obvious choice, as it is 7 times faster than REST when receiving data, and roughly 10 times faster while sending the data.
Both of these beauties can be used cross-language, thereby giving you the flexibility of having a Java application use web services written in Go-lang.
REST uses JSON, a human readable language for communication, which makes it easier to understand the data interacted with.
HTTP API calls can be easily made by simply typing the URL in a browser, or by using a CURL command from the terminal. They can also be implemented easily using the basic HTTP library. In contrast, gRPC requires special software on both the ends. gRPC-generated code has to be incorporated in the client and server build processes.
gRPC does not define a standard mechanism to prevent data loss, when two client try to updated a common resource at the same time. HTTP has standard Etag and If-Match headers for this purpose. gRPC also does not define mechanism for partial updates, covered by the PATCH method in HTTP.
In conclusion, each has a battle of it’s own, you just gotta decide which fight do you wanna pick. REST remains to be the first choice of programmers, virtually every micro-services based infrastructure depends on REST APIs, acting as the glue. gRPC on the other hand, is not yet widely adopted, and it remains to be seen how lavishly it will be treated with the advances.
Toodles :)