AssemblyLift IO Modules (IOmods) are a system for providing asynchronous input and output (IO) to WebAssembly (WASM) modules.

In Theory

At the core of each AssemblyLift function is a compiled WASM module. The WASM guest is executed by a runtime, and is isolated from the host environment. To allow access to services available to the host (such as the filesystem or networking), the AssemblyLift ABI provides the WASM guest an interface to run an IO call in an IOmod process at the registered coordinates (the org.namespace.name triplet).

This is inspired by the approach taken by the Haskell programming language to IO. Haskell being a purely functional programming language, operations which change the state of the world (i.e. which have side-effects) must specially handled. Haskell has the concept of I/O Actions which separates the side-effect code from the pure-function code.

AssemblyLift IOmods follow the same paradigm, where our WASM modules are disallowed from having side-effects by design. Said another way, AssemblyLift considers that a WASM module is a pure function.

The AssemblyLift "Threader" runtime tracks the completion status of IOmod calls and manages the flow of data between IOmods and the WASM guest.

In Practice

IO Modules are distributed in packages containing a manifest & an executable binary entrypoint. Functions in each service share the same set of IOmods as dependencies. When the AssemblyLift runtime starts, it first spawns all IOmods distributed with the service; each then registers itself with the runtime at the start of execution.

Each IOmod should also distribute a guest library for each supported guest programming language. These libraries wrap the low-level RPC code used to communicate with an IO Module in an API idiomatic to the language.

For example if you specify akkoro.aws.s3 as a dependency in your service, a function written in Rust will interact with it by importing the assemblylift-iomod-s3-guest crate.