Introduction
Golem is a durable computing platform that makes it simple to build and deploy highly reliable distributed systems.
The WASM component model eliminates the need for microservice architectures, since components written in different languages can interact with each other in-process (through component composition), without having to go through remote protocols like HTTP, gRPC, or JSON RPC.
Despite this, however, there are times when remote procedure calls (RPC) are useful or necessary when developing applications on Golem:
- You want to parallelize computation that cannot be done on a single worker, either due to lack of memory or lack of compute.
- You want to partition state that is too large to store in a single worker; or, perhaps, you want to partition state that can fit in a single worker, but cannot be read and written fast enough due to contention.
Both of these are examples require the development of a distributed system, where some combination of state and computation is distributed to improve performance, reduce latency, or improve scalability.
To build a system that distributes state or compute, it is necessary to coordinate work, which requires RPC of some kind.
Recognizing the critical nature of internal communication for many distributed systems, Golem provides a feature called worker-to-worker communication. This feature allows you to simply, and in a type-safe way, communicate between workers, with strong guarantees, such as reliable, exactly-once invocation semantics.
Technical details
For worker-to-worker communication, Golem generates a type-safe client interface for each remotely callable component. These client interfaces are matching the component's interface, but packaged into a resource that can be only constructed by giving enough information to know which worker to communicate with.
In case of durable components, this can be either a worker name (using the known name of the component) or a custom worker ID for special use cases. For ephemeral components, there is no need to specify a worker name, as each call will spawn a new ephemeral worker.
Caller components are importing this generated client interface, so they no longer only use the host interfaces provided by Golem but also this dynamically created one.
There are two ways to resolve this extra import:
- Using the
wasm-rpcbinding type in the application manifest. In this case the import will be dynamically linked in the Golem server whenever a worker of the caller component is created. This is the recommended way as it has no additional build-time dependencies. - Using the
static-wasm-rpcbinding type in the application manifest. In this case the build tool (golem app build) will generate a Rust implementation of the client interface, compile it to WASM and compose it with the caller component's WASM module. This is useful for studying how the client implementation works, but as it requires the Rust toolchain to be installed, it is not recommended in general.