2. RPC: Background
● Remote Procedure Call (RPC) is a powerful technique for constructing distributed, client-
server based applications.
● The objective of using RPC is same as that using API (Application Program Interface)
○ To invoke a function/method on a remote server.
● Open up the door for microservice architecture.
● The two processes may be on the same system, or they may be on different systems with a network
connecting them.
● The variation of same request via HTTP and RPC (only POST):
3. RPC: Functionality
Stub: On the client side, the stub handles the
following function:
● Interface with server machine
● Marshaling and unmarshaling data.
● Invoking the RPC run-time protocol.
On the server side:
● Stub provides a similar interface as
client.
● Along with acknowledgement
capability.
Traditionally, RPC can be implemented as
RPC-XML and RPC-JSON.
4. gRPC: Google Remote Procedure Call
● It is an adaptation of traditional RPC frameworks.
● gRPC is built on top of HTTP/2 ( REST API uses: HTTP/1.1).
● gRPC allows a loose coupling between server and client (long-lived connection).
● The binary(bytes) data format allows the communication to be lighter.
○ REST uses JSON and it is a text-based format, it will be much heavier.
● The most important difference is that gRPC uses protocol buffers.
● First Class Load Balancing (grpclb protocol): gRPC has built in library feature it can
intelligently pick which backend to send traffic to.
5. Protobuf: Protocol Buffer
● Protocol buffers can describe the
structure of data interface.
● The code can be generated from the
following protobuf.
○ Using protoc (CLI-tool).
○ Currently support 10+ languages.
● RPC runtime converted proto are only
machine readable (secured).
● Supports types and Validations
○ Hence, no complication over
network.
6. gRPC: Distinct Features
Features packed along with HTTP/2:
● Client-side Streaming.
● Server-side Streaming.
● Duplex Streaming.
[detailed]