5 ms·

This is really great! What I'm really look forward to trying is the server side WebAssembly: https://unit.nginx.org/configuration/#configuration-wasm https://un

This is really great! What I'm really look forward to trying is the server side WebAssembly: https://unit.nginx.org/configuration/#configuration-wasm https://unit.nginx.org/configuration/#configuration-wasm. Huge potential!

eterps 3y ago
What specifically are you looking forward to?
- ilovefood 3y ago
  I've been tinkering quite a bit with WasmCloud and WasmEdge lately, for some data workloads (scraping, ingesting, apis etc) mainly as an excuse to learn WebAssembly. What I want to see for myself is how Unit compares to those for this reduced scope (api's/services) and how fast I can be productive with it. This could be a good starting point for a lot of new applications, kind of an "airflow (the data orchestration thing) on Webassembly". So main points are performance (is it good enough) and developer experience (is it easy to maintain/change). Nothing really ground breaking, just trying out stuff.
drawfloat 3y ago
What’s the advantage of server side WebAssembly over just running a Rust/whatever application?
- politelemon 3y ago
  My limited understanding from various blog posts is that you can still get the benefits of a container, but much faster startup/runtimes. As in WASM provides performance very close to native.
- pseudosavant 3y ago
  Security isolation too. I am using a WASM-based image processing pipeline for handling user submitted images. Much safer than trying to run a binary (Imagemagick, ffmpeg, etc) written in an unsafe language. In my case, the WASM does not have access to anything outside the sandbox.
  - imhoguy 3y ago
    Have you compared how much performance overhead has such sandbox in comparison to native (Linux) binary? Especially video processing. I just wonder if WASM app can even benefit from SSE4 or AVX instructions.
- e12e 3y ago
  As siblings have mentioned: sandboxing. You don't need your language/runtime to support arm/other to run same compile artifact on arm32, arm64, power5 and amd64 - compile to wasm once, run anywhere (nginx unit would still need to support your target). Your runtime theoretically don't need is support - compile to wasm, run on FreeBSD/arm. You can compile your c microservice to wasm, and your rust microservice, and your c++ microservice to wasm - and deploy them sandboxed via the same stack - reducing complexity (note that another option is to deploy via nginx unit - different way to reduce complexity).

eterps 3y ago

What specifically are you looking forward to?

ilovefood 3y ago
I've been tinkering quite a bit with WasmCloud and WasmEdge lately, for some data workloads (scraping, ingesting, apis etc) mainly as an excuse to learn WebAssembly. What I want to see for myself is how Unit compares to those for this reduced scope (api's/services) and how fast I can be productive with it. This could be a good starting point for a lot of new applications, kind of an "airflow (the data orchestration thing) on Webassembly". So main points are performance (is it good enough) and developer experience (is it easy to maintain/change). Nothing really ground breaking, just trying out stuff.

drawfloat 3y ago

What’s the advantage of server side WebAssembly over just running a Rust/whatever application?

politelemon 3y ago
My limited understanding from various blog posts is that you can still get the benefits of a container, but much faster startup/runtimes. As in WASM provides performance very close to native.
pseudosavant 3y ago
Security isolation too. I am using a WASM-based image processing pipeline for handling user submitted images. Much safer than trying to run a binary (Imagemagick, ffmpeg, etc) written in an unsafe language. In my case, the WASM does not have access to anything outside the sandbox.
- imhoguy 3y ago
  Have you compared how much performance overhead has such sandbox in comparison to native (Linux) binary? Especially video processing. I just wonder if WASM app can even benefit from SSE4 or AVX instructions.
e12e 3y ago
As siblings have mentioned: sandboxing. You don't need your language/runtime to support arm/other to run same compile artifact on arm32, arm64, power5 and amd64 - compile to wasm once, run anywhere (nginx unit would still need to support your target). Your runtime theoretically don't need is support - compile to wasm, run on FreeBSD/arm. You can compile your c microservice to wasm, and your rust microservice, and your c++ microservice to wasm - and deploy them sandboxed via the same stack - reducing complexity (note that another option is to deploy via nginx unit - different way to reduce complexity).