Add support for WASM Runtime

[runabol]

WebAssembly is a binary instruction format designed for safe and efficient execution on web browsers, but it can also be employed on the server to enhance the performance and security of web applications.

WebAssembly is known for its high-performance characteristics. It offers near-native execution speed, making it potentially a compelling choice as a runtime environment for Tork tasks.

To run WebAssembly on the server-side, we need a runtime environment. There are several runtime options available, such as Wasmer, Wasmtime, and V8 (with the V8 isolates feature).

The goal of this issue is to explore the pros and cons and potential viability of using WASM as an execution runtime implementation for Tork tasks.

[k0pernicus]

Hi,
I would be interested to run WASM binaries through a runtime directly in Tork, principally to run "simple" tasks with no cold boot compared to Docker containers (and avoid the time to pull a big image also) while maintaining good code isolation.

Based on my own experiments it seems wasmtime a better alternative than the others, simply because it is the most up-to-date runtime and has great performance compared to other runtimes.

If you need help on that task I can start working on it, open a PR and we can iterate on a best first solution for Tork.

[runabol]

Tork is definitely designed to support different runtime environments. See https://www.tork.run/runtime

My main concern with wasmtime is that it's written in Rust and requires CGO to make it work which would compromise the portability of Tork as well as introduce compilation and runtime complexities.

Have you looked at Wazero?

[k0pernicus]

Based on your first comment I supposed you wanted to execute in a subprocess the runtime and the WASM binary, and not integrate a library directly in Tork. Sorry for the confusion.
Your comment about wasmtime / CGO makes sense.

I heard about Wazero but never played with it.
I can definitely take a look at it, evaluate it, and make a feedback with a small POC for WASM.

Do you have an opinion about WASI? As an example, do you want to integrate preview1 and preview2, open WITs, ... ?

[runabol]

No actually you bring a great point. No reason we couldn’t run it as an external process as in the case with Docker and Podman. In the Docker runtime I do use the golang client for Docker to talk to the daemon but that turned out to be more problematic than simply calling the docker cli which is why I moved to that approach in the podman implementation.

[k0pernicus]

I actually tried to do that - with the wasmtime library - in another project. The main painful point is the introduction of new features / changements in WASM specifications, which leads to strong modifications of the API most of the time, and sometimes copy-pasting large code blocks to include new features while keeping the old WASM specification(s) for legacy maintenance.

Importing directly the runtime(s) is a less painful point, but then we will have to deal with the output data format, the (sub)process lifetime, etc.

Both can be envisaged, to me it's just a question of “where to set the bar for complexity” in the current architecture.

[runabol]

Yep, your experience with wasmtime is very similar to what I've seen with the docker sdk integration: mismatch between client and server versions, verbose API, and breaking changes between versions. Does wasmtime have a reasonably well defined CLI we can use if we go down that path?

[k0pernicus]

Does wasmtime have a reasonably well defined CLI we can use if we go down that path?

Based on my own experiments since 3-4 years I would say "yes", but of course this might change in the future.

One of the benefit of integrating runtimes is also that:

1. we can integrate at least one of them, and create some specific adapters to CLI arguments if we want to test many of those (and let the DAG owner which one to use)
2. we can switch more easily from one to another if one day the runtime becomes obsolete or deprecated, as it does not depend of an entire library we have to switch internally.

Also the runtimes are not particularly the same altogether: they follow the same WASM specifications but they focus on different features of WASM / WASI or compiler features (JIT, AOT, interpreter, ...) that can be interesting depending on the developer use case.

[runabol]

Yea, I say we start with one of them like you suggested.

Should be fairly easy to register a new runtime.

And then the user will be able to select them on startup. e.g.:

TORK_RUNTIME_TYPE=wasmtime ./tork run standalone

[k0pernicus]

Sounds good to me, I will start a prototype and open a PR when it will be ready for a first review.