spin

Is this similar to Fermyon's Spin? https://github.com/spinframework/spin

linky: https://github.com/fermyon/spin#readme (Apache 2; and while I don't see any CLA, interestingly they do require GPG signed commits: https://developer.fermyon.com/spin/contributing-spin#committ... )

They’re VC-funded and their business model is vendor lock-in. See their response to my discussion: https://github.com/fermyon/spin/discussions/861 With WasmEdge there is no vendor lock-in

There's this, too: https://github.com/fermyon/spin "Spin is an open source framework for building and running fast, secure, and composable cloud microservices with WebAssembly"

> - JS is notably missing from the list of languages supported on the front page. But I see mentions of a Spidermonkey.wasm in the blog post. Is running JS on top of wasmtime in production a realistic prospect today? If so, where can I read more? (mainly interested in this for the instantiation time benefits, though maybe all/most of that will be negated by the embedded JS engine?) Shopify and others use QuickJS as their JS engine of choice. See https://github.com/Shopify/javy as a starting point. The real benefit is allowing authors of plugins to write JS and not AssemblyScript, not any performance or instantiation time benefits. > - How should I go about building a typical web service on top of wasmtime? Can wasmtime itself handle network requests/connections or would I need to build the web server in some other host language and pass r

Webassembly is also gaining steam for server workloads due to several advantages (less overhead, better capability based security, composability, ...). See Spin [1], Wasmcloud [2], Lunatic [3], etc. My system is based on a distributed Webassembly runtime. The reason for taking inspiration from Kubernetes is making deployment of distributed workloads on that runtime easy. A nice benefit for a Kubernetes alike system is that the equivalent to operators and controllers can be much more light-weight WASM actors that are easier to develop, deploy and scale. [1] https://github.com/fermyon/spin [2] https://github.com/wasmCloud/wasmCloud [3] https://github.com/lunatic-solutions/lunatic

(one of the authors of Spin here.) WIth the disclaimer that this is really early, and we don't have extensive benchmarks yet, there are a few things we are tracking for HTTP workloads (you can see the actual benchmark apps here — https://github.com/fermyon/spin/tree/main/crates/http/benche..., and the rendered results here — https://fermyon.github.io/spin-benchmarks/criterion/reports/): - the response times — here are some benchmarks for requests that simulate 1 ms of work — https://fermyon.github.io/spin-benchmarks/criterion/reports/... - the "cold" startup time — https://fermyon.github.io/spin-benchmarks/criterion/reports/... Another disclaimer is that we have not focused on optimization work at all, so we expect to make significant improvements over the next few months.

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" w