3 ms·
This is not like CGI. Calling it "the new CGI" seems to me like a way to confuse people, since CGI was a response to individual requests and carrying state acro
by smolder 2y ago
This is not like CGI. Calling it "the new CGI" seems to me like a way to confuse people, since CGI was a response to individual requests and carrying state across requests was always extra work. None of this has to do with WASM in particular.
- svieira 2y agoWith CGI the developer of the script could pretend that the-only-thing-which-existed was this request and do all kinds of things that would bring down a persistent process (leak memory, mutate globals, etc.) The problem was that spinning up a process per-request was expensive and slow. Now, with WASM's memory model it becomes possible to have a process that both does all the slow work initialization work once and has the ease-of-reasoning properties of CGI's "a single process for a single request" serving model.
- smolder 2y agoEdit to say: thanks for your answer. I'll preserve the rest since I still think wheels are being reinvented here. Bridging state across requests is not new. If "the new CGI" means more efficiently sharing state between requests, that's a really arbitrary qualifier and is not unique to WASM or serverless or anything like that. The article is myopic, it doesn't take into consideration what is established practice done over and over.
- networked 2y agoWASI CGI is the new CGI. :-) https://codeberg.org/valpackett/caddy-wasm-wcgi https://codeberg.org/valpackett/caddy-wasm-wcgi Sorry, I'll use this rare opportunity to bring up WCGI for Caddy. :-) It is a Caddy web server plugin that runs CGI applications compiled to Wasm, which includes scripting language runtimes. The project isn't mine, and I haven't tried it for anything beyond a "Hello, world!". I think it is a neat hack.