Announcing Spin 2.1
- Spin uses Wasmtime 15, and supports a new WASI snapshot
- Multiple components can register for the same Redis channel trigger
- Plugins can be configured using plugin-specific keys in the
- Multiple plugins can be upgraded in one go, with the ability to interactively choose which ones to upgrade
Let’s have a look at a few of the highlights of the release!
Update to Wasmtime 15 and Supporting Multiple WASI 0.2 Snapshots
Time for a quick recap: As we laid out in a previous post, the WebAssembly Component Model is A Very Big Deal—not just for us and our customers, but for software development as a whole. The Component Model provides a way to create applications whose parts are very tightly isolated and far less prone to the kinds of security issues that plague most software in existence, and lead to countless cases of stolen personal information, outright theft, and nation-scale sabotage. The Component Model comes paired with the WebAssembly System Interface (WASI): a way for individual components to talk to the outside world via well-known interfaces.
Both the Component Model and the upcoming major new release of WASI are getting close to being done, but right now are still in development.
In our announcement of Spin 2.0, we described how Spin supports production use of the upcoming WASI 0.2 release by supporting not just the underlying WebAssembly Component Model, but also a snapshot of the WASI 0.2 APIs before their specification has been finalized.
With this release, we’re making good on a promise that’s integral to our approach: we’re shipping a new snapshot of the APIs, but we’re also keeping around support for the previous snapshot. This has multiple essential benefits:
- it enables our customers to rely on stable support for existing content
- it decouples the release schedule of our runtime from that of our various language SDKs
- it allows developers to test against multiple versions of the APIs in the same runtime
We didn’t create our own full implementation of all WASI APIs for Spin. Instead, Spin is inheriting support for them from the Wasmtime WebAssembly runtime Spin is built on top of.
In Spin 2.0, we directly used the WASI implementation provided by Wasmtime version 14. For Spin 2.1, we upgraded to Wasmtime 15, which provides an implementation of a newer snapshot: Wasmtime 14 included
WASI 0.2.0-rc-2023-10-18, whereas Wasmtime 15 includes
WASI 0.2.0-rc-2023-11-10. Instead of just copying all of the previous snapshot’s implementation, we re-implemented the previous snapshot as a thin layer on top of the new one. Where the APIs didn’t change, automatically generated glue code directly forwards to Wasmtime’s implementation, and where there are differences, we added the small bits of code to implement the old behavior in terms of the new implementation.
Registering Multiple Components for the Same Redis Channel Trigger
It’s now possible to have multiple components in the same application listen for events on the same Redis channel. This both addresses a developer experience issue and provides more flexibility in how developers can structure their applications: before this change, only the last component registered for a channel was invoked, which could lead to hard-to-debug issues. And by the same token, previously developers had to put all of the logic for reacting to events into the same component, whereas now they can split it out into multiple components.
id = "one"
source = "one/target/wasm32-wasi/release/one.wasm"
channel = "test"
id = "two"
source = "two/target/wasm32-wasi/release/two.wasm"
channel = "test"
Configuring Plugins in the Spin Manifest
Spin has long supported plugins to extend its functionality. With Spin 2.1, we’ve now added a way for those plugins to support configurability on the application and the component level directly in an application’s
Spin.toml manifest way instead of having to add additional configuration files as needed.
For example, a
lint plugin could enable configuring a lint level for the entire application and another one for a specific component like this:
lint_level = "savage"
lint_level = "mild-mannered"
Interactively Upgrading Multiple Plugins
And speaking of plugins, first-time contributor João De Macedo hit the ground running by adding support for interactively selecting which plugins to upgrade. Before this change, upgrading plugins only worked for a single plugin at a time, using the
spin plugins upgrade foo syntax, or for all installed plugins with
spin plugins upgrade --all.
With João’s change, you can now use
spin plugins upgrade to start an interactive process that shows which plugins can be upgraded and allows you to select which ones you want to apply an upgrade for.
We would like to thank the over 70 contributors to the Spin project and in particular our new contributors @deadprogram, @joaogdemacedo, @ogghead, @0xE282B0, and @laurentiustamate94. Hope to see you again in the commit history soon!
A special mention goes out to the maintainers of the Bytecode Alliance projects, particularly the Wasmtime project, as well as the developers working on WASI and the WebAssembly component model. Their work is instrumental in supporting Spin.
Stay in Touch
If you would like to get involved in the Spin project, join us at our Spin Community Developers Meeting which is held on the fourth Monday of every month at 1600 UTC. Our next one is on January 26.