proposal to add an Extism runtime

[nilslice]

Extism supports a number of languages quite well, and has a low-level interface which could be adapted to the Reqeuest/Response pattern of wws.

Essentially, the wws HTTP server layer would:

1. Handle incoming request
2. Copy fully buffered HTTP body as string/[u8]
3. Pass it to Extism.plugin.call("request", body)
4. Use the return value from that call as the Response body

Then any Extism plugin could work as a worker. The plugin would only need to export a request function for wws to call, reading the input Request, and setting the output as the Response.

Since wws is in Rust, our Rust SDK would be the implementation path: https://extism.org/docs/integrate-into-your-codebase/rust-host-sdk/

And then any of our official PDKs (in 7 languages) could be used to write wws Workers:
https://extism.org/docs/concepts/pdk/

If there is interest, maybe we can collaborate on this. Thanks!

[Angelmmiguel]

Hello @nilslice,

Thank you for opening the issue! Extism is a cool project (already knew about it 😄). Unfortunately, I believe that replacing our internal engine to use Extism won't fit with the wws goals.

Then any Extism plugin could work as a worker. The plugin would only need to export a request function for wws to call, reading the input Request, and setting the output as the Response.

The idea behind wws is to bring the benefits of WebAssembly to existing serverless projects. Extism supports many languages, although all of the source code must be compiled to wasm in advance. This is something we're trying to avoid so developers don't need to introduce any new toolchain in their current environments.

For compiled languages, this is expected. However, for interpreted languages, developers are not used to compile and we want to avoid that step.

And then any of our official PDKs (in 7 languages) could be used to write wws Workers:
https://extism.org/docs/concepts/pdk/

Apart from that, this approach gives wws the flexibility to support new languages "on-demand". You have a sneak peak about this on #63 🙂.

For this reason, I would say that we don't plan to support different engines for now. I will ping you back in case we extend it in the future.

Thank you for being open to collaborate. I will keep an eye on Extism!

[nilslice]

Hey @Angelmmiguel - thanks for the response :)

I should clarify:

Unfortunately, I believe that replacing our internal engine to use Extism won't fit with the wws goals.

I didn't mean to imply that this would replace the engine, but rather add another runtime option. Just like you currently have options for Native and JavaScript, one could exist for Extism.

But I understand if it doesn't fit with the bigger picture goals -- just figured it could be a nice way to jumpstart lots more language support for wws.

I'll take a look at #63. Keep up the good work!

[Angelmmiguel]

Thanks for the clarification @nilslice!

I didn't mean to imply that this would replace the engine, but rather add another runtime option. Just like you currently have options for Native and JavaScript, one could exist for Extism.

Oh I see! Since Extism provides its own WebAssembly runtime (Wasmtime), I thought on it as a way to replace our current implementation. Sorry for the missunderstanding!

About Native and JavaScript files, they prepare the worker source code and configure any extra requirement in the WASI context. Then, the context goes back to the Wasmtime runtime defined in the worker.rs file.

Currently, those files are deprecated as the idea is that runtimes configure themselves via metadata. The end goal is to avoid having to release a new version if we add a new language and anyone can configure their own ones.

I'll take a look at #63. Keep up the good work!

Likewise! I will keep in mind Extism, and I'll definitely contact you in case it fits here or in other project 😄