RPC - Remote Procedure Call

Imagine you are working in a microservice architecture where there are 2 services: A and B.

Service B can operate only when it gets some request from Service A. Now, in order to get some output from Service A and give that as input to Service B there must be some sort of connection right? How do we establish that connection?

One will say a simple REST API call that’s it right? But is that enough?

Can we do something better?

While you think of it let’s try to understand the problems associated with this HTTP connection and try to shift our focus to RPC i.e. Remote Procedure Call which might offer a better and efficient solution.

Higher Latency:

-> HTTP relies on Json for data serialization which is fine but it adds extra size to the data.

-> Now this added size can increase the time it takes for the requests and responses to travel over the network…right? Performance can be affected.

Loosely Typed Json:

-> Data between 2 services is often exchanged in JSON format. Now, the issue with this json is that it isn’t strictly type safe.

-> In simple terms, imagine service A sends the following json data to service B:

 { "customerId": "123", "transactionAmount": "150.50" }         

-> In the above json customer id and the transaction amount both are passed as string, now if service B tries to process customer id as an integer but gets a string it’ll throw a runtime exception. Right?

-> RPC on the other hand can have this sorted since now the data can be defined in a strictly typed format. It’d look something like:

message Transaction { 
      int32 customerId = 1;
     float transactionAmount = 2; 
}         

-> You might be confused as to what are these 1 and 2 and where are the actual values? In RPC, there is a .proto file where the structure of the request is defined-consider it like how you define a model in your application.

-> Above is a sample .proto file.( .proto files define the structure of data we send, making data easy to validate.)

-> Values are provided at runtime hence you can give the dynamic values in your application code only. Does that make sense?

Repeated Connection:

-> In traditional HTTP(HTTP/1.x), there is a new connection established for each request.

-> This can add to the load on both clients and the server and also eventually increase the overall request time.

-> RPC on the other hand generally use HTTP/2.x protocols(gRPC for example) that can allow persistent connections.

Now, let’s try to understand the characteristics of RPC:

1. Address space is not shared between the processes: This basically means that the client and server are separate programs with their own resources. They communicate via messages and don’t make any direct contact.
2. No direct access to the caller’s encironment: The client only sends the information the server needs, in order to do a particular operation. It doesn’t directly access the variables in the server’s environment.
3. Parameters only pass the values: The client passes the value of each parameter while calling a remote function. The server gets a copy of this data and has no direct refereence to anything in the client’s memory.

Before I wrap this article up I just want to show you how simple it looks to use RPC(obviously you need to set things up and I’ll definitely bring in a practical implementation article some day soon).

Here is your normal code that has the function “add” in the same application. You are simply instructing the computer to run some code that is already loaded in memory:

fun add(a: Int, b: Int): Int {
    return a + b
}

val result = add(5, 10) 
        

Here is how RPC code would look like:

val result = rpcAdd(5, 10) //please note rpcAdd is a just a name of the method. It has nothing to do with the syntax for RPC.
        

Now the function “add” isn’t on your local machine but is somewhere on a different server.

Here’s what happens behind the scene:

1. Your program sends a request over the network to the remote server to run add(5, 10).
2. The remote server receives the request, runs add(5, 10), and gets 15.
3. The remote server sends 15 back over the network to your program.

So even though it looks like you’re calling a regular function (rpcAdd), it’s actually running on another server and then sending the result back to you. RPC hides the networking part, letting you call and receive the result as if it was local.

These are some of the characteristics of RPC. You can read about gRPC(a popular framework that works on RPC) here.

If you read it till here, do consider liking and sharing the post as it takes a lot of efforts to write about new topics. To be honest, most of the things I write about are new to me as well so whenever I write something I don’t know about I make sure to write only the part that I understand.

You can also follow me for more such content. Happy weekend folks!