Remote Procedure Call (RPC)
Remote Procedure Call (RPC). Exposes local function calls across process or network boundaries.
Summary
Why hold: RPC hides latency, partial failure, and contract evolution behind a synchronous function shape. Teams inherit tight coupling, brittle client stubs, and debugging pain when services move or scale independently. Prefer resource-oriented REST with OpenAPI for most HTTP services.
When RPC anyway: local IPC-shaped control planes, plugin hosts, or tooling protocols where both sides share a lifecycle (for example a CLI talking to a co-located daemon). gRPC is assess in those bounded cases, not a greenfield default for product APIs.
Relationship to IPC: same-machine RPC is often just IPC with a serializer. Treat cross-host RPC as a service boundary design problem, not a convenience wrapper.
Details
| Topic | Notes |
|---|---|
| Default alternative | REST + explicit DTOs and error models |
| High-performance internal | assess gRPC with strict schema and ownership |
| Local tooling | IPC primitives or local gRPC before remote RPC |
| Failure handling | Timeouts, retries, and idempotency must be designed; RPC stubs do not provide them |
| Garden link | API subcategory stance: adopt REST, assess gRPC, hold RPC as default |