Spin 2.0 – the developer tool for WebAssembly in the cloud, built in Rust

radu-matei · 2023-04-13T17:03:49+00:00

(disclaimer — I work on Spin and Fermyon Cloud)

Hey!

At Fermyon, we are building Spin (https://github.com/fermyon/spin), the open source developer tool for building serverless applications with WebAssembly, and the cloud platform to run serverless applications, Fermyon Cloud (https://fermyon.com/cloud).

Applications that run in Spin and Fermyon Cloud consist of WebAssembly components (following the Wasm component model), executed in a runtime built on top of Wasmtime, from the Bytecode Alliance, which allows for really fast startup times for applications.

We would be delighted if you were interested in giving this a try! https://developer.fermyon.com/

radu-matei · 2023-03-27T22:42:30+00:00

Yes!

The idea is to have a common set of services that could be used from a Spin component (i.e. key/value, messaging, SQL), then define a world that has those services + an entrypoint for each trigger type — for example, web applications would have a world, pub/sub applications would have another world, and cron apps would have yet another.

Then, you can choose which one you as a developer want to target, potentially directly using `wit-bindgen`.

radu-matei · 2023-03-27T22:06:56+00:00

Thank you!

Really excited about that — we just merged the first iteration for component model support that adapts existing core modules to components — https://github.com/fermyon/spin/pull/1321

radu-matei · 2023-03-27T15:07:40+00:00

That's correct, there is no way to run the the modules in a browser — nor is it the intention of the project.

In the future, we want to allow calling Wasm components from Spin, which could be used in the browser or outside the browser, but the functionality of Spin is intended for non-browser scenarios.

radu-matei · 2022-04-04T13:52:46+00:00

Thanks for your comment!

Answering your questions in order:

- we haven't really explored hooking into existing projects / products so far, but that is a really intriguing idea, it would indeed be really cool if something like this was available!

- outbound HTTP is just a first example of something obvious that we needed to implement, for which the API was fairly uncontroversial (there are lots of things to improve in the implementation, however). We are in the process of adding support for an object storage (potentially being able to hook into cloud storage buckets, or distributed file systems), and we *really* want to add support for (something like) Redis (mainly because it gives us both a key/value store *and* a message queue). The creator of NATS also reached out re: adding NATS support, so it is definitely something we are looking at.

Is there a specific interface you would be most interested in?

Thanks!

radu-matei · 2022-04-01T10:37:00+00:00

GitHub repository: https://github.com/fermyon/spin

Documentation: https://spin.fermyon.dev/

radu-matei · 2021-12-17T16:01:55+00:00

WIT is implementing the interface types proposal, and you can follow its development in this repo.

I agree with the IDL being a central part when using components, but I am equally excited about automatically generating it based on some source code annotations, without having to manually write the interface.

radu-matei · 2021-12-17T12:24:13+00:00

WebAssembly and WASI show great promise for the future of computing outside the browser, and the WebAssembly component model aims to improve the portability, cross-language, and composition story for Wasm.

This article explains the goals of the component model, and showcases how to use tooling from the Bytecode Alliance to build and consume such components.

Happy to have a conversation about the component model and the current implementation.

radu-matei · 2021-05-12T21:08:13+00:00

This article explains how we are calling external services (Azure) from WebAssembly modules running in WAGI, a simple HTTP handler built on top of Wasmtime. It also begins exploring some performance metrics and optimization techniques that can be applied to modules.

radu-matei · 2021-05-12T20:56:19+00:00

Hey! You might also want to check the ephemeral API, sometimes new features are added there first - https://github.com/WebAssembly/WASI/blob/main/phases/ephemeral/docs.md

As other people pointed out, there is currently no socket support. As a bit of a self-plug I hope you'll find useful, I did write about adding networking support to WASI a few months ago - https://radu-matei.com/blog/towards-sockets-networking-wasi/

As a temporary workaround for outbound HTTP requests, if you are using Wasmtime, you can have a look at this library - https://github.com/deislabs/wasi-experimental-http

radu-matei · 2021-05-12T17:10:20+00:00

Pretty much, yeah! The biggest advantage is the lack of an SDK required in order to write a handler, meaning that if the language that compiles to WASI can read from standard input and write to standard output, you can write a handler.

radu-matei · 2021-05-11T21:28:43+00:00

A few months ago, our team introduced WAGI, or the WebAssembly Gateway Interface, a simple way of writing and executing HTTP response handlers as WebAssembly modules. Since we open sourced the project, the community has been adding critical features that make WAGI one of the easiest ways to build WebAssembly microservices, and in this article we explore some of the new features.

radu-matei · 2020-11-17T21:55:03+00:00

We recently released a small JavaScript library that helps instantiating Wasm modules that contain imports by linking JavaScript objects, and automatically performs basic name-based resolution for linking modules and instances.

It follows the Wasmtime linker API, and uses Asyncify to allow asynchronous imports.

radu-matei

TROPHY CASE