I applaud their effort on this! It's great to see push from more companies of WebAssembly on the server-side (disclaimer, I work at Wasmer).
I have one nit about the article though. I think I haven't seen the claimed support for the Component Model anywhere in the code (other than naming the Wasm modules components), as its mainly based on the extent of WebAssembly Interface Types (WIT). Could anyone from the team give more info on where the Component Model proposal is actually used?
Hi, and thanks for your comment!
(one of the authors of Spin here.)
First, both Spin and the component model are in their early stages, but there are a few things I'd mention here:
- as you correctly pointed out, all "trigger" interfaces are based on WIT (https://github.com/bytecodealliance/wit-bindgen/blob/main/WI...), the new WebAssembly interface format, so a) building a WebAssembly binary that implements a trigger interface can be done pretty easily in languages with bindgen support, and b) extending Spin with a new trigger type can also be done by starting with the WIT interface (really early on this topic, but here's an example — https://spin.fermyon.dev/extending-and-embedding/)
- we want to add support for defining component dependencies, and dynamically linking them at runtime based on the environment.
- all "platform features" we want want to add to Spin will be initially based on host implementations for WebAssembly interfaces (you can see an early example of this in this PR — https://github.com/fermyon/spin/pull/165)
I have one nit about the article though. I think I haven't seen the claimed support for the Component Model anywhere in the code (other than naming the Wasm modules components), as its mainly based on the extent of WebAssembly Interface Types (WIT). Could anyone from the team give more info on where the Component Model proposal is actually used?