Hacker News Reader

Comment by eins1234 | Hacker News Reader

Instantiating a runtime in microseconds is deeply exciting!

Though after skimming through the docs, I'm still left wondering a few things:

- 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?)

- 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 request data to wasmtime modules? Haven't been able to find anything in the docs about this.

- What would it take to build a multitenant web service where customer code is isolated using wasmtime, like the one like described in the post?

View on HN

These are good questions! Here's some answers from the corner of the world I know best as a Wasmtime contributor at Fastly:

1. Spidermonkey.wasm is the basis of Fastly's JavaScript on Compute@Edge support. We have found it to be faster than QuickJS. The source code is here: https://github.com/fastly/js-compute-runtime.

2. Fastly Compute@Edge is built on wasmtime. You can develop web services for it in Rust, JS, and Go: https://developer.fastly.com/learning/compute/

3. Fastly's multi-tenant platform is closed source, but our single-tenant local development platform, which also uses wasmtime under the hood as well, is open source: https://github.com/fastly/viceroy. It isn't a big leap to make viceroy multi-tenant: Wasmtime provides everything you need, and all Viceroy would have to do is dispatch on e.g. HTTP host header to the correct tenant. Our multi-tenant platform is closed source because it is very specialized for use on Fastly's edge, not because the multi-tenant aspect is special.

> We have found it [spidermonkey.wasm] to be faster than QuickJS

Interesting!

Do you have numbers for code size and memory usage perhaps?

Nice, the fact that Fastly is comfortable betting on Spidermonkey.wasm is the vote of confidence I needed to dig in! Also really love seeing how much Fastly is giving back to open source!

> 1. Spidermonkey.wasm is the basis of Fastly's JavaScript on Compute@Edge support.

How difficult is staying up to date with SpiderMonkey's latest or pre-release upstream versions? Do have to maintain your own SpiderMonkey patches to make upstream work for you?

We worked with Igalia to upstream the SpiderMonkey patches required to build for wasm32-wasi. We point to a fixed version (see: https://github.com/fastly/spidermonkey-wasi-embedding) which we haven't updated for a minute.

> - 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 request data to wasmtime modules? Haven't been able to find anything in the docs about this.

There are a lot of choices for this. None I would consider mature, but some leads:

- https://github.com/deislabs/wagi

- https://suborbital.dev/

- https://github.com/fermyon/spin

They handle the passing of data between host and guest for you. Your module, written in a language that compiles down to wasm, is evaluated against the request. They make host functionality, such as the ability to make other network calls, available to your module as needed.

> - What would it take to build a multitenant web service where customer code is isolated using wasmtime, like the one like described in the post?

See suborbital linked above. Not much. This is the primary current use case for server side wasm.

This is super helpful. Thank you so much! Will start digging into these right away.

> > What would it take to build a multitenant web service where customer code is isolated using wasmtime, like the one like described in the post?

> See suborbital linked above.

For a real world example of someone using Suborbital's platform for exactly that, see https://avenue.so/blog/avenue-launches-custom-filters-transf...

It is indeed early days, but we're pretty confident that the opportunity is real. Take webhooks. With webhooks, your customers have to bring and manage their own infrastructure. That's a pain in the ass. Everywhere that supports webhooks should also support Just Running My Damn Code. Like with GitHub Actions.

How does GitHub do it? Simple: They're owned by Microsoft. GitHub can bury the problem in an ungodly deluge of cheap virtual machines from their sister company, Azure.

You aren't owned by Microsoft, so how will you Just Run Some Code? You're going to use WebAssembly. Specifically, in a year or two, you're going to integrate some sort of off-the-shelf commodity product that's powered by WebAssembly.

Suborbital is one shot at what that future might look like. We'll be talking more about this in the next few weeks. And it's not just us: a lot of the serverside WebAssembly folks will be at Cloud Native WASM Day at KubeCon next month... say hello if you're there!

In what use cases can user-provided wasm realistically replace webhooks? It seems to me that in plenty of cases, you'd end up needing something like webhooks anyway. For instance, I use Stripe, and I implement their webhook to handle completed checkouts. My webhook implementation needs to update my database, send email using my email service provider credentials, etc. I doubt that running my own wasm code on Stripe's infrastructure would make things simpler. But I'd like to learn more on use cases where user-provided wasm really would be better.

Reply on news.ycombinator.com