Anime GIF

What is RPC?

July 16, 2025

You know how when you're building a system, especially a microservices setup, you often hit this really annoying speed bump?

Let's say you've got your Authentication Service and a separate Notification Service. When someone tries to log in, Auth needs to tell Notification to send an OTP email. Makes sense, right?

Your first thought (and most common solution) is probably to use REST, you whip out your language's HTTP client and fire off a request.

That's where the headache starts.

The Pain of Too Much Boilerplate

Here's the core problem we all face: every single service in your network that wants to talk to Notification has to write a bunch of tedious, repetitive code:

  1. Client setup: Every language has its own HTTP library (Node's axios, Go's net/http, etc.). You have to set it up.
  2. Making the Call: You manually construct the URL, the JSON body, and the headers.
  3. The "Oh No" Stack: Then you have to write logic for all the messy bits: retries, failure handling, timeout logic, and manually converting the response JSON back into the native object you use in your code.

It's all boilerplate. You're spending more time babysitting the communication protocol than actually writing the logic that sends the OTP. It's frustrating when you just want to call a function, but you're stuck doing networking plumbing.

Enter RPC: Making the Network Disappear

What if we could simply abstract out all that repetitive, mundane stuff, the communication protocol, the object creation, the retries, compression, streaming and just focus on the core business logic?

That's the idea behind Remote Procedure Call (RPC).

The goal? To make a function that talks over a network look exactly like a regular, local function call.

Look at this:

// Code on the Auth Service
const userEmail = "user@example.com";
const otp = "123456";
 
// This looks like calling a local library, right?
const success = notificationService.sendOtp(userEmail, otp);

Behind the scenes, this simple function call is what actually happens:

  1. It connects to the Notification Service over the network.
  2. It sends the data (userEmail, otp).
  3. The Notification Service executes its logic.
  4. It sends a response back.

This beautiful illusion is called location transparency. The location of the code (local vs. remote server) becomes transparent to the developer.

How Does the Trick Work? Meet the Stubs

So, how does that routine-looking function turn into a network conversation? It’s all down to a piece of auto-generated code called the stub.

1. The IDL (The Blueprint)

First, we start with a Stub Interface Description Language (IDL), like Protocol Buffers (Protobuf). Think of this as the universal contract. You write down the service name and the exact structure (data types) for the request and response.

2. The Stub Generator (The Code Factory)

You then run a stub generator over this IDL file. This tool spits out all the necessary code for every language you use (Go, JS, Java, etc.).

3. Marshalling and Unmarshalling (The Translator)

This generated code, the stubs, is the main reason the trick works:

  • Client Stub: On the Auth Service, the stub intercepts your function call, takes your native objects (say, a JavaScript object), and marshalls (serializes) them into an efficient, network-ready format. This data then gets sent over the wire.
  • Server Stub: On the Notification Service, the stub receives the data, unmarshalls (deserializes) it back into a native object (like a Go struct), and finally executes the actual implementation of the sendOtp function.

This back-and-forth conversion and network packet movement is the stub's entire job. It shields your business logic from the communication mess.

Why We Use RPC (Besides the Chill Factor)

While it's true RPCs are magnitudes slower than actual local calls (network latency is a killer!), the framework you choose, like gRPC (which uses the high-performance HTTP/2 protocol), gives you massive advantages that make it worth it for inter-service comms:

  • Developer Productivity: Seriously, calling a remote function like a local one is a huge win.
  • Performance Out of the Box: Most RPC frameworks handle things like compression, connection pooling, and multiplexing (multiple calls over one connection) automatically. You get efficiency for free!
  • Built-in Features: They handle all the boilerplate we complained about: payload conversion, failures, retries, and network protocols.
  • Strong, Typed Clients: Because the stubs are generated from an IDL, you get strong API clients in almost any language without writing a single line of client library code yourself.

A Few Caveats

It's not perfect, though. Starting with RPC can be a bit more challenging than just slinging JSON over HTTP.

  • Stub Maintenance: If you change your function signature in the IDL (like adding a field), you must regenerate the stubs everywhere. Miss one, and things break.
  • Testing: Testing RPC services can sometimes be less straightforward than using a simple HTTP client like Postman.
  • Browser Woes: Direct support for protocols like gRPC in web browsers is still limited, often requiring a proxy layer.

But for rock-solid, high-performance, and type-safe communication between your backend services, RPC is tough to beat. It’s all about letting you write beautiful, clean code, while the stubs handle the ugly network grunt work.

LinkedIn
X