Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> - 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.



> > 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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: