Overview:

• RPC means Remote Procedure Call. It's a client-server communication mechanism, the client calls locally a procedure which is actually in remote server.
• gRPC is Google's version of RPC open source simple service definition framework.
• When we work with micro services architecture, in few scenarios we need to make multiple api calls which will introduce high latency. gRPC service or in other words contract-first api can help with this problem by leveraging http/2.0 protocol and binary serialization technique called protocol buffers.
• Protocol buffers (protobuf) are language & platform agnostic for serializing data. It serializes the data into a compact format optimized for network transmission over HTTP2.0

gRPC vs REST:

• REST is text based and uses HTTP1.1 whereas gRPC is protobuf based and uses HTTP2.0
• REST leverage json/xml vs gRPC uses protocol buffers for data serialization.
• REST is request/response pattern whereas gRPC is encode/decode and streaming pattern.
• REST is resource oriented design as we need to communicate using HTTP verbs; gRPC is service oriented design where client knows all types and procedures locally before making a call.

When to choose gRPC:

• If we have multiple teams who are specialized in different programming languages and target to build lot number of inter connected services based on domain driven design, we can design micro service architecture by leveraging gRPC framework where needed. NOTE: REST is more established, popular and simple than gRPC and it is still preferred predominantly everywhere.
• If we need to stream or transfer huge data between client and server.
• As gRPC is strongly typed, we need to choose for a use-case where client and server are tightly coupled, maintained or enhanced together by the same team.
• Choose gRPC where performance is critical and non-negotiable.

Templates to build gRPC applications:

• gRPC has wide number of language support. C++, C#, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python, Ruby, and Swift. Sample

PROS:

• Better performance, low latency, high thorough-put.
• Ideal for low bandwidth networks.
• Efficient for internal service to service communication.
• Strongly typed with built in support to validate every request.
• Native protobuf compiler to generate code for any supported language based on '.proto' file.
• Built-in better load balancing routine and selective message compression capability. Note: I am yet to explore these advanced options.

CONS:

• Not evolved fully yet with all browser types. Thus, we can't fully leverage from browser to server communication.
• Not adopted widely yet.
• Binary serialization makes it tedious to debug during transport.

How gRPC works:

gRPC Client:

• Client calls a local procedure which is a gRPC client stub created based on '.proto' file.
• gRPC runtime will binary encode and transport the request to server over http/2.0

gRPC Server:

• gRPC runtime in server once it receives the request will binary decode and extract the request as server stub (created based on '.proto' file).
• gRPC service will process the request and return the response back.

Note: When the response goes back to client, encode/decode will happen vice-versa between client and server.

Referene

official gRPC link