3 ms·
With 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 persist
by svieira 2y ago
With 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.