Calling a function on another machine — partial failure behind the RPC stub
A remote call is dressed up to look like a local function call, but unlike a local call it can fail after the server already did the work — so you can be left not knowing whether it happened.
Scene 01
Calling a function on another machine
- Watch
- Try it
- Predict
- Capture
Start with something you already trust. When your code calls a function like greet("Ada"), the call and the answer happen in one place, in memory — instantly, and all-or-nothing: it either ran and gave you "Hello Ada", or it didn't run at all. Now put the function on ANOTHER machine. Your code still writes greet("Ada"), but the framework quietly turns that line into a network round-trip: a client sends a request over the wire, a server runs the function body and computes "Hello Ada", and a reply comes back. That trick — making a call to another machine LOOK like an ordinary local function call — is called a Remote Procedure Call (RPC): an RPC is a useful lie, a network round-trip dressed up as a function call. The piece doing the dressing-up is the stub: the auto-generated client-side shim that you call like a normal function, which packs your arguments, sends them, and unpacks the reply — so your code never sees the network. Watch the local call first, then the same call as an RPC. Linger on the wire: that gap between request and reply is the whole story.
Where this sits in Build a gRPC-style RPC framework
Scene 01 of 14, in the The wire act — Bytes, frames, and the schema that gives them meaning.. A remote call is dressed up to look like a local one — but unlike a local call it can fail after the server already did the work, so the caller can't tell if it happened.
Up next. If greet("Ada") has to travel as actual bytes over that wire, the very first problem is that the wire hands the other side a pile of bytes with no idea where one message ends and the next begins.
All 14 scenes in Build a gRPC-style RPC framework · Every curriculum