wasmedge: add support for WasmEdge engine.

[q82419]

Hi,

Here's the maintainer of the WasmEdge runtime.
This pull request implements the WasmEdge supporting for the proxy-wasm with the newest WasmEdge release version (0.8.2).
For this first version, we provides the interpreter mode of WASM runtime, and the AOT mode supporting for proxy-wasm is still work in progress.
Please feel free to review this pull request and give us some advices if there's issues, bugs, or incomplete implementations.
Thank you.

Resolves #97

[mathetake]

Thank you for submitting this!

[q82419]

Please help to link with the issue 97, thanks.

[mathetake]

Please help to link with the issue 97, thanks.

you can do that by putting the comment in the description like resolves #97:) (See https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)

[PiotrSikora]

@q82419 this is still failing to build.

[q82419]

Hi @PiotrSikora ,
We've clear the boost issue, but still have trouble at handling the spdlog dependency.
Do you have suggestions for adding the spdlog dependency with bazel for the find_package in cmake?
How do I copy or symbolic link the whole spdlog dependency archive when building the wasmedge target?
Thanks.

[q82419]

Hi @PiotrSikora ,

We choose to use our pre-built shared library instead. Thanks.

[PiotrSikora]

Hi @PiotrSikora ,

We choose to use our pre-built shared library instead. Thanks.

Hi @q82419, unfortunately, this isn't acceptable solution. Proxy-Wasm C++ Host is used in products where supply chain security is a big concern, so we cannot rely on prebuilt artifacts from untrusted sources. We need to figure out a way to build Boost / WasmEdge from sources in Bazel.

[q82419]

Hi @q82419, unfortunately, this isn't acceptable solution. Proxy-Wasm C++ Host is used in products where supply chain security is a big concern, so we cannot rely on prebuilt artifacts from untrusted sources. We need to figure out a way to build Boost / WasmEdge from sources in Bazel.

Hi @PiotrSikora ,

Thanks for the feedback.
We're now preparing for the 0.9.0 release now, and will update the PR to resolve this. Thanks.

[q82419]

Hi @PiotrSikora ,

We've updated the WasmEdge runtime to 0.9.0 and resolved the mentioned issues.
For the cloneability and the compiled sections, we'll work for supporting in the future.
Please let us know if there's any issue. Thanks.

[PiotrSikora]

For the cloneability and the compiled sections, we'll work for supporting in the future.

That's fine, thanks!

[PiotrSikora]

It looks this is a custom branch that bundles boost and spdlog, which means that updating this runtime without your help might be tricky in the future. What's the plan for those commits? Do you intend to merge them into master branch or is the plan to keep them forever in a development branch?

[q82419]

We'll keep the branch, and merge the master into that branch for each official release.
For the 0.9.0 release, we pushed the proxy-wasm/0.9.0 tag and use the tag in this PR.

[PiotrSikora]

Apologies for the delay, I had to cleanup our CI before accepting new engines, otherwise we'd be evicting cache on each PR run. We should be good to go now, so could you merge master and resolve the conflicts? Thanks!

Also, could you explain what's the advantage of WasmEdge over the existing engines that we support? Currently, we have V8 (fast JIT), Wasm Micro Runtime (fast interpreter), Wasmtime (Cranelift), WAVM (LLVM JIT/AOT), and it's unclear what use case does WasmEdge address, and why users should select WasmEdge over any of the existing eninges.

[q82419]

Apologies for the delay, I had to cleanup our CI before accepting new engines, otherwise we'd be evicting cache on each PR run. We should be good to go now, so could you merge master and resolve the conflicts? Thanks!

Also, could you explain what's the advantage of WasmEdge over the existing engines that we support? Currently, we have V8 (fast JIT), Wasm Micro Runtime (fast interpreter), Wasmtime (Cranelift), WAVM (LLVM JIT/AOT), and it's unclear what use case does WasmEdge address, and why users should select WasmEdge over any of the existing eninges.

Hi @PiotrSikora ,

WasmEdge has the following advantages over all Wasm runtimes, including V8:

1. WasmEdge supports some non-standard but necessary extensions for cloud-native environments. For example, it supports non-blocking network sockets, WasmEdge-bindgen for complex para passing, and Tensorflow / AI inference. They may not be important for a proxy embedded runtime right now, but they could expand the types of applications your developers might want to try.
2. In a service mesh environment, the developer might want to use Wasm in both the proxy and the microservice. WasmEdge is the runtime that provides the best integration with various k8s distributions. In fact, WasmEdge is itself an OCI container that can be managed by container tools- neither node nor other wasm runtime is a container.
3. Through the AOT compiler, WasmEdge is one of the fastest WebAssembly runtimes on the market.
4. WasmEdge provides excellent support for JavaScript, including ES6 and NPM modules, async networking, the fetch API, React SSR, and even mixing Rust code with JS code.
5. WasmEdge is written in C++, and hence has better (in our view) support for different OSes and language SDKs.
6. It is often a good idea to support multiple runtimes because each project might have different roadmaps, adoption, and community. For example, WasmEdge is a CNCF project working with a lot of cloud-native projects. Other Wasm runtimes might be focused on the browser or IoT devices.

[PiotrSikora]

WasmEdge has the following advantages over all Wasm runtimes, including V8:

1. WasmEdge supports some non-standard but necessary extensions for cloud-native environments. For example, it supports non-blocking network sockets, WasmEdge-bindgen for complex para passing, and Tensorflow / AI inference. They may not be important for a proxy embedded runtime right now, but they could expand the types of applications your developers might want to try.
2. In a service mesh environment, the developer might want to use Wasm in both the proxy and the microservice. WasmEdge is the runtime that provides the best integration with various k8s distributions. In fact, WasmEdge is itself an OCI container that can be managed by container tools- neither node nor other wasm runtime is a container.
3. WasmEdge provides excellent support for JavaScript, including ES6 and NPM modules, async networking, the fetch API, React SSR, and even mixing Rust code with JS code.

None of that matters when embedding WasmEdge's engine part (without extra runtime APIs) into Proxy-Wasm.

3. Through the AOT compiler, WasmEdge is one of the fastest WebAssembly runtimes on the market.

Do you have any data behind this (compared to V8, WAMR, Wasmtime, WAVM, etc.)?

5. WasmEdge is written in C++, and hence has better (in our view) support for different OSes and language SDKs.

I'd argue that C, C++, and Rust all have pretty good support, so this isn't a differentiator.

6. It is often a good idea to support multiple runtimes because each project might have different roadmaps, adoption, and community. For example, WasmEdge is a CNCF project working with a lot of cloud-native projects. Other Wasm runtimes might be focused on the browser or IoT devices.

That's definitely true, and I'm greateful for you working on adding WasmEdge to Proxy-Wasm.

However, I still don't know when I should recommend WasmEgde over V8/WAMR/Wasmtime/WAVM to Proxy-Wasm users? What's the benefit?

[juntao]

Hi, This is Michael Yuan from WasmEdge. :)

For the points 1 and 2 below: I think the bigger picture is that people are increasingly using WebAssembly as a runtime for microservices themselves, in addition to the data plane. It simplifies development and deployment if the entire system uses the same WebAssembly runtime with the same extensions, SDKs, and toolings. On this front, WasmEdge with its support for async networking sockets, cryptography, and Kubernetes, is a compelling choice of WebAssembly across the proxies and the microservices.

For point 3, please see WasmEdge performance benchmarks: https://github.com/WasmEdge/WasmEdge/blob/master/README.md#performance

For point 4, wouldn't it be nice to program traffic rules using JavaScript? ;)

Cheers!
Michael

WasmEdge has the following advantages over all Wasm runtimes, including V8:

1. WasmEdge supports some non-standard but necessary extensions for cloud-native environments. For example, it supports non-blocking network sockets, WasmEdge-bindgen for complex para passing, and Tensorflow / AI inference. They may not be important for a proxy embedded runtime right now, but they could expand the types of applications your developers might want to try.

2. In a service mesh environment, the developer might want to use Wasm in both the proxy and the microservice. WasmEdge is the runtime that provides the best integration with various k8s distributions. In fact, WasmEdge is itself an OCI container that can be managed by container tools- neither node nor other wasm runtime is a container.

4. WasmEdge provides excellent support for JavaScript, including ES6 and NPM modules, async networking, the fetch API, React SSR, and even mixing Rust code with JS code.

None of that matters when embedding WasmEdge's engine part (without extra runtime APIs) into Proxy-Wasm.

3. Through the AOT compiler, WasmEdge is one of the fastest WebAssembly runtimes on the market.

Do you have any data behind this (compared to V8, WAMR, Wasmtime, WAVM, etc.)?

5. WasmEdge is written in C++, and hence has better (in our view) support for different OSes and language SDKs.

I'd argue that C, C++, and Rust all have pretty good support, so this isn't a differentiator.

6. It is often a good idea to support multiple runtimes because each project might have different roadmaps, adoption, and community. For example, WasmEdge is a CNCF project working with a lot of cloud-native projects. Other Wasm runtimes might be focused on the browser or IoT devices.

That's definitely true, and I'm greateful for you working on adding WasmEdge to Proxy-Wasm.

However, I still don't know when I should recommend WasmEgde over V8/WAMR/Wasmtime/WAVM to Proxy-Wasm users? What's the benefit?

[PiotrSikora]

LGTM, thanks!