Wasmer is completely focused on running WebAssembly modules server-side.
We started by running Emscripten-generated modules, but over time we added support for other ABIs (WASI, Wascap, etc).
You can run various programs with each ABI, such as Nginx (Emscripten) and Cowsay (WASI)
Over time we realized that the runtime had to do a lot of checks before starting an instance to verify that the WebAssembly module was compliant with a certain ABI (Emscripten or WASI). That means checking that the module imports and exports are what the runtime expects (namely the function signatures and global types match).
It turns out these checks are not just important for making sure a module is going to work with a certain runtime, but they can also be useful to assure a module is compatible with a given API.
This can be key for the creation of plugin ecosystems for any program that uses WebAssembly as part of its plugin system, where every module has to be compliant with a certain interface (think of the header files in C).
With Wasm Interfaces and WAPM, you can easily make use of the entire WAPM ecosystem to create, verify, and distribute plugins!
Because of that, we decided to work on a way to check these and propose it as a standard for defining a specific set of imports and exports that a module must have, in a way that is statically analyzable.
Validating imports and exports are as expected with Wasm Interface · WebAssembly/design
To help with linking, identifying and verifying the ABIs of modules for our package manager, and making using our…
Show me the WAI
The WebAssembly Interface is inspired by the lisp-like text format of WebAssembly.
We intentionally decided to push for a format that it’s completely agnostic of future proposals, because we wanted the interface to stay closer to the internals of WebAssembly (only four types:
This what a WebAssembly Interface for WASI looks like:
That means, that a module that implements the WASI interface has to be compliant with all this signatures.
How you can use it?
There are different projects already using this syntax to define interfaces for WebAssembly Modules.
WAPM pioneered the integration of WebAssembly Interfaces.
If you are using the wapm cli, the modules will be automatically type-checked with the provided interface before publishing to the registry.
That way, we can assure that new modules stay compliant with the ABIs they are supposed to fulfill.
Right now, the available interfaces in WAPM are:
- WASI: The WebAssembly System Interface is a modular system interface for WebAssembly. It’s focused on security and portability.
- Wascap: Wascap is a set of standards and conventions that attempts to fill the void for cloud-native Wasm module host environments.
Here’s a great article on how to publish a Wascap module to WAPM.
Verify an interface for a Module manually
When you use WAPM and the
interfaces field on the config, we will validate the module against the interface.
We also created a binary,
wasm-interface available now on WAPM:
wapm install -g wasm-interface
# Run the checks
wasm-interface --dir=. check wasi-module.wasm -i interface.wai
Verify an interface for a Module automatically with WAPM
Publishing a module for WASI or Wascap interfaces is super easy!
Make sure you are running the latest version of
wapm.toml file and add a
If you want to create a new interface in WAPM
Soon, creating new WebAssembly interfaces on WAPM will be open for everyone.
We decided to start with a manual creation of new Interfaces on WAPM to allow faster iteration if we need to do small changes on the syntax.
If you think you have an interesting use case for creating a global interface in WAPM (such as a new ABI, a plugin system, …), don’t hesitate to get in touch! email@example.com