wasmCloud
wasmCloud copied to clipboard
wasmCloud
Implement support for WasmEdge
WasmCloud could support multiple alternative wasm runtimes to take advantage of the unique features and performance characteristics of each.
I would like to propose that WasmCloud add support for the WasmEdge Runtime through WasmEdge's Rust SDK.
https://github.com/WasmEdge/WasmEdge/tree/master/bindings/rust
If there is anything we could do to help. Please let me know. Thanks.
At the moment we use the wasmex library that is a wrapper around wasmer. We've always had the notion of adding multi-engine support back into wasmCloud, but I'm wondering whether it makes sense for us to add engine choice at the wasmCloud level or perhaps at the wasmex level. Thoughts @tessi ?
Likely the biggest obstacle in our way is to provide https://github.com/rusterlium/rustler bindings on top of WasmEdge in order to take advantage of the Rust SDK.
As @autodidaddict mentioned this is one of the main reasons we chose wasmex for our engine wrapper at this stage.
Thanks for the explanation. I think that perhaps supporting WasmEdge from wasmex would indeed be the right path.
How can we help here? :)
Hey everyone,
thanks for tagging me here. I haven't looked much in to WasmEdge yet, but support the idea of having multiple WASM backends (there is also https://github.com/bytecodealliance/wasmtime to be mentioned as a potential backend). IMO, a wrapper for a new backend should not be too much work if we copy concepts liberally from wasmex.
From what I see, these WASM backends are similar enough to extract a common API that works for all of them. Maybe having one specific wrapper around each backend (wasmer, WasmEdge, wasmtime), and a meta-package unifying them all under that common API is a good idea. wasmCloud (and others) could then link against that common API and switch between the underlying backends.
Having a separate package for each backend would allow us to develop each backend-wrapper adapted to the speed of its backend and cater for (experimental) features specific to a single backend. It would give us more room for experimentation and we can split maintenance a little better.
Currently, work and life throws a lot of tasks at me. So the time I can spend in open source dev is very limited. I can't be the person coding all this. However, I'm open for more maintainers in wasmex and am happy to help planning integration of wasmex in a meta-wrapper if you like that plan.
What do you think? Feel free to open an issue on the wasmex repo and we can plan there (to not broaden the scope of this issue too much).
Hey @juntao, it's been a little while! With the effort that @tessi recently just put into refactoring from wasmer to wasmtime, I think implementing wasmedge as well would really require the largest effort in writing the custom NIF. Are you aware of any efforts here? I just don't want this issue to go too stale 🙂
Hey! sorry @juanto
Wasm and with it all the different wasm engines is just moving to fast for me to maintain multiple engines. I just can't do that besides family and day job. If you or someone wants to give it a try, I'd be happy to give you an intro into the problem space and wasmex code base :)
Hey! sorry @juanto
Wasm and with it all the different wasm engines is just moving to fast for me to maintain multiple engines. I just can't do that besides family and day job. If you or someone wants to give it a try, I'd be happy to give you an intro into the problem space and wasmex code base :)
You've been putting in amazing effort. I don't think anybody would expect you to support swapping in and out of "all the engines"
You've been putting in amazing effort. I don't think anybody would expect you to support swapping in and out of "all the engines"
1000% agree and this is in no way a slight towards wasmex. The wasmex project and its fearless leader (tessi 😄) is fantastic
No worries! Let me try to give a status update.
We have recently worked with several companies and projects to support WasmEdge together with wasmtime. The process is typically to replace wasmtime's GO or Rust SDKs with WasmEdge's. Those APIs are fairly similar. We have done it many times -- we are actually thinking about creating an abstract API on top of those SDKs to support easy switching. ;)
The typical reasons to support both runtimes are:
1 Supply chain security -- since wasmtime and WasmEdge are based on completely different tech stacks (Rust + Cranelift vs C++ + LLVM), they are unlikely to be affected by the same bugs.
2 Additional features provided by WasmEdge such as web service, database, AI inference, Kubernetes / Docker and JavaScript support.
Of course, I understand different projects have different priorities. I am not that familiar with the Erlang / Elixir ecosystem but would love learn more to understand how we can better support it! 🙏🙏🙏
😊 thanks everyone! didn't mean this to be hunting for compliments 🙈
we are actually thinking about creating an abstract API on top of those SDKs to support easy switching
sounds very interesting especially if it's not a vendor lock-in and well maintained and on-par with wasmtime! I probably continue the port to wasmtime first and investigate further steps from there.
I [...] would love learn more to understand how we can better support it!
Is there anything specific you'd like to know? Feel free to reach out on twitter or @tessi on the elixir slack for wasmex-specifics and a more real time'ish chat and to not sidetrack this issue any further :)
We've done a whole lot of reorganization around how we're running Wasm engines, and I think for now we're going to proceed with support for wasmtime as the engine under wasmCloud. As soon as we get to rethinking pluggable / replaceable engines, I'd love to consider putting wasmedge as one of those engines