Introduction to RPC - Remote Procedure Calls



1531 views Designing μ-services



What are Remote Procedure Calls? How were they conceptualized? and Why are people adopting them? Here’s why 👇‍

The two services need to communicate with each other so as to get things done. The most common way to do it today is to make a REST call over HTTP to the other service.

With this approach, every service needs to write logic to make HTTP call to the other service and handle things like failures, retries, compression, and security. Can we not abstract these complexities in some way?

RPCs were conceptualized to solve this problem.

Remote Procedure Calls

RPCs are designed to make remote network calls look and feel like local procedures. They abstract out all the complexities of remote invocations like Marshalling, Unmarshalling, Compressions, Retries, Security, etc.

RPCs achieve this level of coherence using Stubs that sit in between the two services and convert incoming and outgoing packets into native objects.

Stubs

Stubs are the common piece of auto-generated code that defines the interface, in a given language, exposed by the server, and used by the client to consume the data.

The interface is defined in a common language like Protobuf and holds the information about functions that the server exposes and the request response object types. A generator is shipped with the RPC runtime that would take this interface and generate code in the target language.

For example, if the Auth service is written in Golang, the generator would generate a working code with the interface along with the transport details. This way, we can solely focus on writing the business logic and not worry about the network or other repetitive things.

Communication RPC

RPC can use any transport protocol for communication - Raw TCP, UDP, HTTP 1.1, or even HTTP 2. The transport is just a way through which the marshaled information will be sent across systems; and depending on the features an RPC runtime plans to support, an appropriate protocol will be chosen.

Advantages of using RPC

  • easy to use
  • strong API contract
  • remote invocations are just local function calls
  • cross language communication is a breeze
  • mundane tasks like retries, compression, etc are abstracted
  • get performance out-of-the-box - streaming, connection pool
  • security is just a plug
  • no need to write client libraries, they can be auto-generated

Concerns while adopting RPC

  • stubs need to be re-generated whenever the signature changes
  • testing RPC is n trivial for beginners
  • getting started can be a little challenging
  • browser support for RPC is pretty limited

Arpit Bhayani

Arpit's Newsletter

CS newsletter for the curious engineers

❤️ by 14000+ readers

If you like what you read subscribe you can always subscribe to my newsletter and get the post delivered straight to your inbox. I write essays on various engineering topics and share it through my weekly newsletter.




Other videos that you might like


Introduction to RPC - Remote Procedure Calls

1531 views 97 likes 2022-05-13

One of the most interesting things that revived itself after a decade is Remote Procedure Calls, fondly called as RPCs; ...

Designing Workflows in Microservices - Orchestration vs Choreography

1659 views 111 likes 2022-05-11

In a microservices architecture there will always arise a need to design workflows; for example: when on an e-commerce w...

Synchronous and Asynchronous Communication between Microservices

1646 views 106 likes 2022-05-04

How should two microservices talk to each other? Picking the right communication pattern is super-important as a good de...

Should some microservices share a database?

1814 views 97 likes 2022-04-27

Microservices need to communicate with each other. Communication between them is always about getting or updating data t...


Arpit's Newsletter read by 14000+ engineers

🔥 Thrice a week, in your inbox, an essay about system design, distributed systems, microservices, programming languages internals, or a deep dive on some super-clever algorithm, or just a few tips on building highly scalable distributed systems.



  • v10.6.4
  • © Arpit Bhayani, 2022