Remote Procedure Call (RPC) is a programming model and an API style that allows a program running on one computer to execute procedures or functions on a remote computer as if they were local function calls.
The key phrase is “as if they were local.” When you call a local function, you just invoke it and get a result. RPC aims to make calling a function on a different machine feel exactly like that, even though under the hood there is network communication, serialization, error handling, and a whole lot more happening.
The RPC Workflow
Here’s what happens when a client makes an RPC call to a server.
Client call
The client application calls a client stub. This is a piece of code that acts as a proxy, having the same interface as the remote function so the client doesn’t realize the logic isn’t local.
You might think: why can’t the client application directly call the remote function?
That’s because the remote function does not exist in the client’s memory space.
When you write a function in your program, that function’s code lives in your process’s memory on your machine. Your CPU can jump to that memory address and execute it. But a function on a remote server lives in a completely different process, on a completely different machine, with its own memory space. Your CPU has no way to jump to a memory address on a different computer.
Serialization and transport (client-side)
The client stub packages the function name (or identifier), the arguments, and any metadata into a format that can be transferred over the network. This is called serialization. The serialized data is then sent over the network to the remote server using some transport protocol, which could be HTTP, WebSockets, or any other network protocol.
Deserialization
On the server side, there is a corresponding piece of code called the server stub. The server stub receives the serialized data and deserializes it back into the original function name, arguments, and metadata.
Function execution
The server executes the actual function, performing whatever computation it needs to do.
Serialization and transport (server-side)
Once the function execution is complete, the server stub takes the return value (or error, if the function failed) and serializes it into a network-transmittable format. The serialized response is then sent back over the network to the client.
Client deserialization
The client stub receives the response, deserializes it into the original data types, and returns it to the client application.
From the application’s perspective, it simply made a function call and got a result. It has no awareness that the function executed on a different machine.
REST vs RPC
I’m sure you’ve built and consumed REST APIs. Both REST and RPC styles solve the same underlying problem, which is letting a client on one machine trigger work on a server on another machine, but they approach it from opposite directions.
REST asks you to think in terms of resources. A resource is a noun in your system: a post, a comment, a user, a tag. You design your API by identifying these nouns, giving each one a path, and then using a small fixed set of HTTP verbs to act on them. For example, GET /posts/1 gets a blog post, POST /posts creates one, and DELETE /posts/1 removes one.
RPC asks you to think in terms of procedures. A procedure is a verb in your system: createPost, publishPost, addComment, notifySubscribers. You design your API by identifying the operations your server can perform, giving each one a name, and then letting clients invoke those operations by name.