Wasmer 3.2 Released With WebAssembly On RISC-V Support, New WCGI Feature

[phoronix]

Phoronix: Wasmer 3.2 Released With WebAssembly On RISC-V Support, New WCGI Feature

Wasmer as the open-source project focused on providing a "universal WebAssembly runtime" that supports a variety of platforms and architectures is out today with a new feature release...

https://www.phoronix.com/news/Wasmer-3.2

[silverhikari]

there seems to be a link missing at the end to go to the download page for the release. located at "Downloads and more information on today's Wasmer 3.2 release is available from"

[jabl]

WCGI? So we go through all the motions of creating more scalable server architectures (c10k, io_uring etc. etc.), and in the end we come back and reinvent good ole cgi-bin? Except now with a boatload of scaffolding around it, and we call it FaaS? Great, hooray for progress.. ;-)

[ssokolow]

WCGI? So we go through all the motions of creating more scalable server architectures (c10k, io_uring etc. etc.), and in the end we come back and reinvent good ole cgi-bin? Except now with a boatload of scaffolding around it, and we call it FaaS? Great, hooray for progress.. ;-)

The biggest problem with original CGI was the overhead of spinning up and shutting down a whole new process for each request because it was essentially "shell script invokes subprocess" translated to web serving. Judging by the sample code, it looks more like FastCGI or Python's WSGI in that:

1. Your main function does whatever setup you need and then calls cgi::handle(handler)
2. Your handler function takes one Request as an argument and returns a Response as its return value.
3. Once you've compiled your WASM module, you run it in a persistent daemon.

In other words, it looks like the bare bones of the same API shape used by every Request-Response HTTP application framework I've ever used, including Rust ones like actix-web which consistently rank near the top of things like Techempower benchmarks... the server stays running persistently and you provide the function that gets invoked for every request.

As a way to get another layer of server sandboxing beyond "run it in a straitjacket of a systemd config", I'm looking forward to seeing what support APIs grow up around this... especially if they add that nanoprocess idea where each dependency gets compiled into its own WASM module with its own permissions manifest and the WebAssembly loader statically verifies the modules aren't stepping outside them before starting your program running.

[caligula]

As a way to get another layer of server sandboxing beyond "run it in a straitjacket of a systemd config", I'm looking forward to seeing what support APIs grow up around this... especially if they add that nanoprocess idea where each dependency gets compiled into its own WASM module with its own permissions manifest and the WebAssembly loader statically verifies the modules aren't stepping outside them before starting your program running.

This is so much better than heavy weight bloat Java.