RPC (Remote Procedure Call)¶

RPC is a method that allows a program running on one machine (client) to call a procedure or function on another machine (server) as if it were a local procedure. This communication is done over a network.

Several protocols used to encode and transfer data between the client and server;

• gRPC: Protocol Buffers (protobuf) for its data format. It supports multiple programming languages
• Thrift: Supports multiple programming languages and data serialization formats (e.g protocols are; ThriftBinaryProtocol, ThriftJSONProtocol, ThriftTextProtocol(like HTTP, HTTPS or TCP))

What’s the Difference Between RPC and REST?¶

RPC and REST are two ways you can design an API. An API is a mechanism that enables two software components to communicate with each other using a set of definitions and protocols.

In RPC, one component (the client) calls or invokes specific functions in another software component (the server).

In REST, instead of calling functions, the client requests or updates data on the server.

When to Use RPC¶

1. RPC are used in communication between two backend systems. Like Microservices Architecture to enable communication between loosely coupled services. Cloud-based applications, peer-to-peer networks, and distributed databases.RPC allows different components of the distributed system to communicate and collaborate efficiently.

2. Frameworks that support RPC from front end clients are less common. (No go for client-server ui applications)

3. Perfect choice API provided to a different company instead of an end user app or web page.

4. Real-time applications, such as online games, chat applications, collaborative editin tools, to enable efficient and low-latency communication between clients and servers.

5. Abstracting away the network communication and focusing only on the actions the client wants to perform.

When NOT to Use RPC¶

1. When we want to to take direct advantage of HTTP (like cookues or headers)

2. Where we don't want to abstract the network communication away (Usage of explicit HTTP Clients)

3. Where we needs to exchange simple data between components.

4. Designing an API that is more data-centric

Drawback of RPC¶

RPC is a powerful and versatile technology for building distributed systems, but it does have certain drawbacks that you should be aware of:

• Reliability: The reliability of an RPC service depends on the reliability of the network between the client and server. If the network is unreliable or unavailable, RPC calls may fail or time out, leading to errors or lost data.
• Slowness: Serialization and deserialization of data can introduce additional overhead, especially for large or complex data types. This overhead can result in increased network traffic and slower response times.

What is gRPC?¶

gRPC is an open-source API architecture and system governed by the Cloud Native Computing Foundation. It’s based on the Remote Procedure Call (RPC) model. While the RPC model is broad, gRPC is a specific implementation.

What is the Difference Between gRPC and RPC?¶

• gRPC is a system that implements traditional RPC with several optimizations. For instance, gRPC uses Protocol Buffers and HTTP 2 for data transmission.
• Abstracts the data exchange(underlying HTTP communication) mechanism from the developer.

What's the Recommended Workflow for gRPC ?¶

1. First you define the service methods and data using an IDL(Intermediate Description Language) of your choice. Protocol Buffers is one possible choice of IDL. Definitions are stored in *.proto files.

2. The next step is to invoke the protoc compiler to generate code in languages of your choice. Protocol buffers support generated code in C++, C#, Dart, Go, Java, Kotlin, Objective-C, Python, and Ruby.

protoc -I=$SRC_DIR --csharp_out=$DST_DIR $SRC_DIR/protofilename.proto