4 ms·

Recently I enjoyed some "retrofuturistic" development with WASM and CGI. Spin[1], a webserver written in Rust, can execute WASI[2] binaries that speak CGI. You

by grose 4y ago

Recently I enjoyed some "retrofuturistic" development with WASM and CGI. Spin[1], a webserver written in Rust, can execute WASI[2] binaries that speak CGI. You can then deploy it to Fermyon Cloud or your own server and it "just works". It's a wonderful mix of old and new. I used it for PHP (Prolog Home Page): https://github.com/guregu/php https://github.com/guregu/php [1]: https://spin.fermyon.dev/ https://spin.fermyon.dev/ [2]: WASI is a POSIX-ish standard for WASM that gives you all the low level stuff like standard input and output. It includes all the bits and pieces needed for CGI to work.

bmacho 4y ago
It interprets PHP-style commands, hence the name.
IshKebab 4y ago
Kind of feels like the AssemblyScript guys were right - WASI is becoming a standard for WASM modules that foists Unix on Webassembly, including stuff that isn't really portable like symlinks. That makes sense if you want to compile existing software to WASM but that isn't the case here is it?
- grose 4y ago
  This does use existing software. The onus behind this project was to test my port of Trealla Prolog (which was written by someone else) to WASM. Without a Unixy standard environment it would have been a lot harder. In theory, WASI should enable many CGI-like usages of pre-existing software, but in my experience the quirks between the WASI implementations push you towards using nonstandard things anyway. For example, trealla-js is mostly WASI but uses a couple extra imported functions to coordinate calling into JS. If I wanted to let PHP make outgoing requests I'd have to implement Spin's custom nonstandard components. I hope the WASM Components proposal makes this easier in the future. Personally, I might have preferred a more Plan 9-style approach that uses special files to do things like make outgoing connections, purely because it would be trivial to implement client-side as a simple printf vs. integrating wit-bindgen into the build system and all of that. However, I can see many benefits of the strongly typed component model as well. I don't have a strong opinion on the AssemblyScript controversy[1]. I agree that WASI is imperfect, especially in browsers, but I'm also glad that _something_ exists with not-horrible runtime support. WASI was pretty nice to use as someone who just wanted to get a C program running on WASM. [1] https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html
- sitkack 4y ago
  Wasm allows you to consume as much or as little of the API surface area as you want. You are free to construct Wasm modules in whatever way you see fit for your application.

by grose 4y ago

bmacho 4y ago

It interprets PHP-style commands, hence the name.

IshKebab 4y ago

Kind of feels like the AssemblyScript guys were right - WASI is becoming a standard for WASM modules that foists Unix on Webassembly, including stuff that isn't really portable like symlinks. That makes sense if you want to compile existing software to WASM but that isn't the case here is it?

grose 4y ago
This does use existing software. The onus behind this project was to test my port of Trealla Prolog (which was written by someone else) to WASM. Without a Unixy standard environment it would have been a lot harder. In theory, WASI should enable many CGI-like usages of pre-existing software, but in my experience the quirks between the WASI implementations push you towards using nonstandard things anyway. For example, trealla-js is mostly WASI but uses a couple extra imported functions to coordinate calling into JS. If I wanted to let PHP make outgoing requests I'd have to implement Spin's custom nonstandard components. I hope the WASM Components proposal makes this easier in the future. Personally, I might have preferred a more Plan 9-style approach that uses special files to do things like make outgoing connections, purely because it would be trivial to implement client-side as a simple printf vs. integrating wit-bindgen into the build system and all of that. However, I can see many benefits of the strongly typed component model as well. I don't have a strong opinion on the AssemblyScript controversy[1]. I agree that WASI is imperfect, especially in browsers, but I'm also glad that _something_ exists with not-horrible runtime support. WASI was pretty nice to use as someone who just wanted to get a C program running on WASM. [1] https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html
sitkack 4y ago
Wasm allows you to consume as much or as little of the API surface area as you want. You are free to construct Wasm modules in whatever way you see fit for your application.