12 ms·

Announcing WCGI: WebAssembly and CGI

148 points by syrusakbary 4y ago

smiletondi 4y ago
This is genuinely exciting - the prospect of running Wordpress without the usual security concerns is a game-changer. WCGI seems like it could really disrupt the server-side development landscape. Can't wait to see what other applications will benefit from this technology!
- smiletondi 4y ago
  Full disclosure, I work at the company behind WCGI, but I truly believe this is a groundbreaking development that will have a significant impact on the industry.
  - la_fayette 4y ago
    Full disclosure, I have only minimal understanding of web assembly, other than using C functions inside a web browser. I run wordpress in a read only docker container, what better security could WCGI bring?
    - syrusakbary 4y ago
      Here are the main differences with the Docker strategy: * If you want it to be usable, you will need to ship it with some mechanism that allows running CGI over http (kind of Apache or Nginx), so your container would be bigger than the Wasmer package * Regarding security: Docker containers needs to rely on hardware virtualization to run securely (via KVM or simlar), aside of a virtualization on the systemcall layer (which depends on the crun layer that you use) Because of that, Docker containers will have the downside of: being able to run only in one chipset/OS, they will be bigger-sized and they would be slower to start up (even if you use state of the art for running them, aka Firecracker, you still get 250ms vs < 1ms with Wasmer)
      - samstave 4y ago
        Im going to ask a very ignorant question ;; Is it possible to spin-up a 'container' or whatever youre calling the VM of a site, for each individual user? So if you have a high security req on data accessible by computers, you spin up an individual container of said site that only serves that user, and is destroyed on exit... so that whatever the user does cannot affect others? ELI5?
        rtml 4y ago
        [dead]
      - Kwpolska 4y ago
        > you will need to ship it with some mechanism that allows running CGI over http (kind of Apache or Nginx) Is wasmer stable and secure enough to be exposed to abuse of the entire Internet? > your container would be bigger than the Wasmer package The first Google hit for "docker php nginx" is https://hub.docker.com/r/trafex/php-nginx https://hub.docker.com/r/trafex/php-nginx - they claim their Docker image is 40 MB compressed, whereas Wasmer for amd64 (latest from https://github.com/wasmerio/wasmer/releases https://github.com/wasmerio/wasmer/releases) is a 80 MB tar.gz (unpacks to 300 MB tar). Even with larger images, like the `wordpress` image (200 MB), the size is neglible. > Because of that, Docker containers will have the downside of: being able to run only in one chipset/OS You probably don’t need to care about architectures other than amd64 and arm64. Both are supported by the trafex/php-nginx and wordpress Docker images. > (even if you use state of the art for running them, aka Firecracker, you still get 250ms vs < 1ms with Wasmer) Starting a fresh VM for every request doesn’t make sense, so this difference wouldn’t matter in real life.
        syrusakbary 4y ago
        > whereas Wasmer for amd64 is a 80 MB tar.gz Wasmer ships everything by default, including 3 compilers (LLVM is the big one!), which adds most of the size. However, the wasmer runtime in headless mode weights only about 2 megabytes. Even more, even if you include only one compiler instead of 3 (just singlepass) it would be in the order of 5-10Mb. Stay tuned, because if you are in macOS/iOS you will see even smaller binary sizes!
    - smiletondi 4y ago
      Another aspect to consider is portability. WCGI, built on open standards like WebAssembly & CGI, allows for easier adoption of security improvements/updates across different platforms & environments. Definitely worth exploring alongside read-only Docker containers!
paulgb 4y ago
I've always loved the simplicity and flexibility of CGI. To check my understanding: since CGI just takes a raw request over stdin and returns a response over stdout, would a WCGI wasm module be compatible with WAGI[1] and vice-versa? [1] https://github.com/deislabs/wagi https://github.com/deislabs/wagi
- syrusakbary 4y ago
  That's right, both WCGI and WAGI are currently compatible! Things might evolve a bit different on the mid term, but let's see what the future holds :)
- cassepipe 4y ago
  To me it has always felt like a underspecified hack but maybe I am talking out of ignorance. (I did read the RFC though( I think it's strange idea to run to get a bunch of arguments that you have to get from the environment and/or the stdin and parse the whole of it and then try to programmatically output it all by printing to stdout. No wonder people have come up with template languages that are html supersets and that work with a preprocessor. I don't use CGI but when I do I like the simplicity of Haserl (Basic template language + any interpreter, lua by default) : https://haserl.sourceforge.net/ https://haserl.sourceforge.net/
- benatkin 4y ago
  Matt Butcher who used to work at Deis, which developed WAGI, and Microsoft after it was acquired, now has a new startup, Fermyon, which has something called Spin which I think uses a new protocol that's different from CGI. https://www.fermyon.com/blog/introducing-spin https://www.fermyon.com/blog/introducing-spin That would make sense, anyhoo. CGI is plain text which I don't think is optimal for this stuff.
  - syrusakbary 4y ago
    Hey Ben, why so many comments spamming Fermyon on this thread? Do you have any relation with them?
joncfoo 4y ago
Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're heading in circles in a lot of ways
- syrusakbary 4y ago
  Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly
  - pookeh 4y ago
    There was a time when JVM ran in the browsers.
    - syrusakbary 4y ago
      Yup, via Java Applets. But they were a pain to use, that's why I intentionally wrote "seamlessly" :P
      - ex3ndr 4y ago
        GWT allowed to run it without applets, also much more efficient than any current stack (since they dont support closure compiler)
        switchbak 4y ago
        I spent years working with GWT, it's not nearly as simple as you describe. It's not running "Java" in the browser, it's compiling down (a subset of) Java to Javascript. That said, GWT was ahead of its time in a lot of ways, but it had warts galore.
__MatrixMan__ 4y ago
I don't understand. Why not just compile to machine code and use plain old CGI?
- VikingCoder 4y ago
  Sandboxing, I believe is the answer. Portability, too, I suppose. Maybe a long-lasting archive format for older binaries...
- jtms 4y ago
  I believe the main selling point is portability and flexibility. Anything written in a language that can be compiled to wasm can now be turned into a web service.
- smiletondi 4y ago
  Platform independence: WebAssembly allows you to compile code once and run it on any platform supporting it, saving time and effort when deploying applications across various servers compared to dealing with platform-specific binaries.
  - jeremyjh 4y ago
    Who is deploying the same backend to multiple architectures?
    - smiletondi 4y ago
      Though many developers may not prioritize deploying the same backend across multiple architectures, the platform independence offered by WebAssembly and WCGI can still be advantageous for migration, development efficiency, and keeping up with changing tech trends(serverless, edge computing)
- rektide 4y ago
  Others have some good reasons to also consider. Also, launching new sandboxes in wasm is supposed to be extremely extremely extremely cheap. Where-as launching a cgi-bin executable- even a very small libcgi based one-has a significant cost, requires a lot of kernel work & context switching. With WCGI making new "processes" is nearly free & you don't have to context switch. A lot of the excitement around wasm in general is that it could potentially enable a communicating-processes model of computing that would be inefficient today. Even current "function as a service" paradigms tend to retain processes, have warm/cold start distinctions. With wasm there is a potential to have requests spawn not just their sandbox, but to create whole graphs of lightweight sandbox/processes. Sometimes you might hear this described as a "Nano-functions" architecture.
deleted 4y ago
[deleted]
0xbadcafebee 4y ago
PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also they make this claim: "Picture running Wordpress and not having to worry about attackers breaking into your system" uh, so, you sprinkled some WASM magic on some code and suddenly several decades worth of security research is obsolete? .....yeah, I'm gonna call bullshit. Compiling code or "running in a sandbox" does not stop attackers from breaking into your system. Might slow them down for a few months while they develop some new attacks.
- kristjansson 4y ago
  edit: this was completely wrong, TFA is talking about server side WASM I think the point is that a simple-enough application can be delievered as WASM and run entirely in the user's browser, so there wouldn't be any server-side system to break into? So one could ship e.g. wordpress + db + content in one bundle, and the user would be none the wiser. A wild claim, and probably self-defeating for anyone who needs to protect their content. Otherwise, the WASM-dust at best moves the security boundry to a different service.
  - ThePhysicist 4y ago
    I don't think that's what they mean, Wordpress is a server-side app with a database backend, I don't think you'd want to ship your entire Wordpress database to the browser.
  - jeremyjh 4y ago
    No, CGI is an interface for backend web servers, this is not about client code.
  - noahtallen 4y ago
    It’s already been done! https://make.wordpress.org/core/2022/09/23/client-side-webassembly-wordpress-with-no-server/ https://make.wordpress.org/core/2022/09/23/client-side-webas... (By my colleague Adam!) I think this experiment becomes interesting thinking about times you really want WordPress to be headless (like demoing a plug-in or theme), but less for serving websites to people. Potentially also useful as a testing development environment. I was surprised at how fast it is, since it basically becomes an SPA.
evntdrvn 4y ago
The amount (and evolution) of acronyms in the WASM space is kinda overwhelming so I might be out to lunch… At the top of the article it says “…compiling them to WASI”, but is that a semantically/technically correct statement? My understanding would be more that it should say something like “compiling them to WASI-compliant WASM” or something. Or can you actually “compile to WASI”
- capableweb 4y ago
  WASI is just WASM outside the browser, it kind of implies what you're saying. It's still WASM, just adhering to a specific interface. Like when you say "HTTP API" you don't necessarily need to change it to "TCP HTTP API" as it's somewhat implied (although maybe a shitty example, as HTTP is starting to appear over more things than just TCP as of late)
  - cobbal 4y ago
    WASI is also WASM inside the browser :), since there's a js/wasm conformance of the interface: https://www.npmjs.com/package/@wasmer/wasi https://www.npmjs.com/package/@wasmer/wasi
pjmlp 4y ago
Hello Java Servlets.
aaronbrethorst 4y ago
"AsseAmbly"?
- dang 4y ago
  Fixed. Thanks!
chrismorgan 4y ago
> Consider the challenge of running PHP programs on servers. We have two primary options: > 1. Wrap the PHP interpreter with a layer that instruments each HTTP call > 2. Use the existing php-cgi program and simply compile it to Wasm > Option 2 is not only faster, but it also enables any web application on Wasmer more efficiently. I’m confused. This seems to be suggesting that php-cgi, which has to initialise the PHP environment every time, would be faster than the likes of php-fpm, which, well, I understand and presume it has significantly less overhead per request, though I’ve never benchmarked it. I have PHP 5.6 installed on my VPS for one old site, and it takes around 27ms to start¹ (compared to under 30μs for just plain `echo`, as a closer indicator of actual process spawn overhead). PHP 8.2 might be faster, but it’s still going to be much slower than `echo`. By simply compiling php-cgi to WASM, it will surely be doing all that initialisation for every request. Because CGI starts everything from scratch for each request, it’s inherently less efficient. In theory you could coordinate a time to snapshot the process/VM/whatever, forking from that point, but that’s not CGI any more. All up, what they’re claiming is so completely contrary to what I would expect (and without any explanation or justification whatsoever), and kinda follows the “dust off something old to laugh at it again” trope, that I’m honestly having to check that it’s not the first of April any more (the article is dated the 6th). So as I say, I’m confused. Option 2 seems very clearly slower and much less efficient, by the very nature of CGI. No one targets CGI (it’s been basically dead for… I dunno, close to twenty years?), because CGI is considerably worse than the alternatives. Can someone enlighten me? Have I missed or misunderstood something? —⁂— ¹ Measured by running this in zsh and reading the “total” figure (across sixteen runs, I got between 2.671 and 3.032 seconds): time ( for i in {0..100}; do php56 <<<'<?="."?>'; done ) The comparative echo test uses `echo -n .` and takes one thousandth as long.
- jeremyjh 4y ago
  To me this seems a little closer to the architecture of AWS Lambda than OG CGI, though that is not a perfect analogy either since this is in a WASM runtime within their server process, rather than a separate process. But the programming interface is a handler function you provide with an interface that looks like this in Rust: `fn handler(request: Request) -> Response ` My understanding is the main function is called only once, and registers that handler. So `main` is where you'd initialize the majority of the environment, and no that is not truly CGI; definitely no process is being created for each request, but it may be the case that this is more like FastCGI where you have a pool of single-threaded runtimes all setup that way that can handle requests. This still seems inefficient compared to a threaded or event polling process that can handle multiple requests concurrently without having to marshall data back and forth, but I'd think it can get closer to that than FastCGI or Lambda do.
thomasjb 4y ago
This looks good, I'd been thinking about putting my little Python program that prints a random line from a textfile onto my Apache server for the internet to enjoy, this ought to enable it nicely. Where would be best to look for examples? The idea of exposing Python via a normal cgi script is terrifying to me
nuc1e0n 4y ago
FastCGI would be better than regular CGI. Spawning and cleaning up processes is expensive.
adamziel 4y ago
Note WordPress has an official WebAssembly build for the browser and Node.js: https://developer.wordpress.org/playground https://developer.wordpress.org/playground https://github.com/WordPress/wordpress-playground https://github.com/WordPress/wordpress-playground Disclosure: I'm the creator This project is different in that it builds PHP to WASI.
benatkin 4y ago
A bit late, there is already Spin from Fermyon

148 points by syrusakbary 4y ago

This is genuinely exciting - the prospect of running Wordpress without the usual security concerns is a game-changer. WCGI seems like it could really disrupt the server-side development landscape. Can't wait to see what other applications will benefit from this technology!

smiletondi 4y ago
Full disclosure, I work at the company behind WCGI, but I truly believe this is a groundbreaking development that will have a significant impact on the industry.
- la_fayette 4y ago
  Full disclosure, I have only minimal understanding of web assembly, other than using C functions inside a web browser. I run wordpress in a read only docker container, what better security could WCGI bring?
  - syrusakbary 4y ago
    Here are the main differences with the Docker strategy: * If you want it to be usable, you will need to ship it with some mechanism that allows running CGI over http (kind of Apache or Nginx), so your container would be bigger than the Wasmer package * Regarding security: Docker containers needs to rely on hardware virtualization to run securely (via KVM or simlar), aside of a virtualization on the systemcall layer (which depends on the crun layer that you use) Because of that, Docker containers will have the downside of: being able to run only in one chipset/OS, they will be bigger-sized and they would be slower to start up (even if you use state of the art for running them, aka Firecracker, you still get 250ms vs < 1ms with Wasmer)
    - samstave 4y ago
      Im going to ask a very ignorant question ;; Is it possible to spin-up a 'container' or whatever youre calling the VM of a site, for each individual user? So if you have a high security req on data accessible by computers, you spin up an individual container of said site that only serves that user, and is destroyed on exit... so that whatever the user does cannot affect others? ELI5?
      - rtml 4y ago
        [dead]
    - Kwpolska 4y ago
      > you will need to ship it with some mechanism that allows running CGI over http (kind of Apache or Nginx) Is wasmer stable and secure enough to be exposed to abuse of the entire Internet? > your container would be bigger than the Wasmer package The first Google hit for "docker php nginx" is https://hub.docker.com/r/trafex/php-nginx https://hub.docker.com/r/trafex/php-nginx - they claim their Docker image is 40 MB compressed, whereas Wasmer for amd64 (latest from https://github.com/wasmerio/wasmer/releases https://github.com/wasmerio/wasmer/releases) is a 80 MB tar.gz (unpacks to 300 MB tar). Even with larger images, like the `wordpress` image (200 MB), the size is neglible. > Because of that, Docker containers will have the downside of: being able to run only in one chipset/OS You probably don’t need to care about architectures other than amd64 and arm64. Both are supported by the trafex/php-nginx and wordpress Docker images. > (even if you use state of the art for running them, aka Firecracker, you still get 250ms vs < 1ms with Wasmer) Starting a fresh VM for every request doesn’t make sense, so this difference wouldn’t matter in real life.
      - syrusakbary 4y ago
        > whereas Wasmer for amd64 is a 80 MB tar.gz Wasmer ships everything by default, including 3 compilers (LLVM is the big one!), which adds most of the size. However, the wasmer runtime in headless mode weights only about 2 megabytes. Even more, even if you include only one compiler instead of 3 (just singlepass) it would be in the order of 5-10Mb. Stay tuned, because if you are in macOS/iOS you will see even smaller binary sizes!
  - smiletondi 4y ago
    Another aspect to consider is portability. WCGI, built on open standards like WebAssembly & CGI, allows for easier adoption of security improvements/updates across different platforms & environments. Definitely worth exploring alongside read-only Docker containers!

paulgb 4y ago

I've always loved the simplicity and flexibility of CGI. To check my understanding: since CGI just takes a raw request over stdin and returns a response over stdout, would a WCGI wasm module be compatible with WAGI[1] and vice-versa? [1] https://github.com/deislabs/wagi https://github.com/deislabs/wagi

syrusakbary 4y ago
That's right, both WCGI and WAGI are currently compatible! Things might evolve a bit different on the mid term, but let's see what the future holds :)
cassepipe 4y ago
To me it has always felt like a underspecified hack but maybe I am talking out of ignorance. (I did read the RFC though( I think it's strange idea to run to get a bunch of arguments that you have to get from the environment and/or the stdin and parse the whole of it and then try to programmatically output it all by printing to stdout. No wonder people have come up with template languages that are html supersets and that work with a preprocessor. I don't use CGI but when I do I like the simplicity of Haserl (Basic template language + any interpreter, lua by default) : https://haserl.sourceforge.net/ https://haserl.sourceforge.net/
benatkin 4y ago
Matt Butcher who used to work at Deis, which developed WAGI, and Microsoft after it was acquired, now has a new startup, Fermyon, which has something called Spin which I think uses a new protocol that's different from CGI. https://www.fermyon.com/blog/introducing-spin https://www.fermyon.com/blog/introducing-spin That would make sense, anyhoo. CGI is plain text which I don't think is optimal for this stuff.
- syrusakbary 4y ago
  Hey Ben, why so many comments spamming Fermyon on this thread? Do you have any relation with them?

joncfoo 4y ago

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're heading in circles in a lot of ways

syrusakbary 4y ago
Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly
- pookeh 4y ago
  There was a time when JVM ran in the browsers.
  - syrusakbary 4y ago
    Yup, via Java Applets. But they were a pain to use, that's why I intentionally wrote "seamlessly" :P
    - ex3ndr 4y ago
      GWT allowed to run it without applets, also much more efficient than any current stack (since they dont support closure compiler)
      - switchbak 4y ago
        I spent years working with GWT, it's not nearly as simple as you describe. It's not running "Java" in the browser, it's compiling down (a subset of) Java to Javascript. That said, GWT was ahead of its time in a lot of ways, but it had warts galore.

__MatrixMan__ 4y ago

I don't understand. Why not just compile to machine code and use plain old CGI?

VikingCoder 4y ago
Sandboxing, I believe is the answer. Portability, too, I suppose. Maybe a long-lasting archive format for older binaries...
jtms 4y ago
I believe the main selling point is portability and flexibility. Anything written in a language that can be compiled to wasm can now be turned into a web service.
smiletondi 4y ago
Platform independence: WebAssembly allows you to compile code once and run it on any platform supporting it, saving time and effort when deploying applications across various servers compared to dealing with platform-specific binaries.
- jeremyjh 4y ago
  Who is deploying the same backend to multiple architectures?
  - smiletondi 4y ago
    Though many developers may not prioritize deploying the same backend across multiple architectures, the platform independence offered by WebAssembly and WCGI can still be advantageous for migration, development efficiency, and keeping up with changing tech trends(serverless, edge computing)
rektide 4y ago
Others have some good reasons to also consider. Also, launching new sandboxes in wasm is supposed to be extremely extremely extremely cheap. Where-as launching a cgi-bin executable- even a very small libcgi based one-has a significant cost, requires a lot of kernel work & context switching. With WCGI making new "processes" is nearly free & you don't have to context switch. A lot of the excitement around wasm in general is that it could potentially enable a communicating-processes model of computing that would be inefficient today. Even current "function as a service" paradigms tend to retain processes, have warm/cold start distinctions. With wasm there is a potential to have requests spawn not just their sandbox, but to create whole graphs of lightweight sandbox/processes. Sometimes you might hear this described as a "Nano-functions" architecture.

deleted 4y ago

[deleted]

0xbadcafebee 4y ago

PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also they make this claim: "Picture running Wordpress and not having to worry about attackers breaking into your system" uh, so, you sprinkled some WASM magic on some code and suddenly several decades worth of security research is obsolete? .....yeah, I'm gonna call bullshit. Compiling code or "running in a sandbox" does not stop attackers from breaking into your system. Might slow them down for a few months while they develop some new attacks.

kristjansson 4y ago
edit: this was completely wrong, TFA is talking about server side WASM I think the point is that a simple-enough application can be delievered as WASM and run entirely in the user's browser, so there wouldn't be any server-side system to break into? So one could ship e.g. wordpress + db + content in one bundle, and the user would be none the wiser. A wild claim, and probably self-defeating for anyone who needs to protect their content. Otherwise, the WASM-dust at best moves the security boundry to a different service.
- ThePhysicist 4y ago
  I don't think that's what they mean, Wordpress is a server-side app with a database backend, I don't think you'd want to ship your entire Wordpress database to the browser.
- jeremyjh 4y ago
  No, CGI is an interface for backend web servers, this is not about client code.
- noahtallen 4y ago
  It’s already been done! https://make.wordpress.org/core/2022/09/23/client-side-webassembly-wordpress-with-no-server/ https://make.wordpress.org/core/2022/09/23/client-side-webas... (By my colleague Adam!) I think this experiment becomes interesting thinking about times you really want WordPress to be headless (like demoing a plug-in or theme), but less for serving websites to people. Potentially also useful as a testing development environment. I was surprised at how fast it is, since it basically becomes an SPA.

evntdrvn 4y ago

The amount (and evolution) of acronyms in the WASM space is kinda overwhelming so I might be out to lunch… At the top of the article it says “…compiling them to WASI”, but is that a semantically/technically correct statement? My understanding would be more that it should say something like “compiling them to WASI-compliant WASM” or something. Or can you actually “compile to WASI”

capableweb 4y ago
WASI is just WASM outside the browser, it kind of implies what you're saying. It's still WASM, just adhering to a specific interface. Like when you say "HTTP API" you don't necessarily need to change it to "TCP HTTP API" as it's somewhat implied (although maybe a shitty example, as HTTP is starting to appear over more things than just TCP as of late)
- cobbal 4y ago
  WASI is also WASM inside the browser :), since there's a js/wasm conformance of the interface: https://www.npmjs.com/package/@wasmer/wasi https://www.npmjs.com/package/@wasmer/wasi

pjmlp 4y ago

Hello Java Servlets.

aaronbrethorst 4y ago

"AsseAmbly"?

dang 4y ago
Fixed. Thanks!

chrismorgan 4y ago

> Consider the challenge of running PHP programs on servers. We have two primary options: > 1. Wrap the PHP interpreter with a layer that instruments each HTTP call > 2. Use the existing php-cgi program and simply compile it to Wasm > Option 2 is not only faster, but it also enables any web application on Wasmer more efficiently. I’m confused. This seems to be suggesting that php-cgi, which has to initialise the PHP environment every time, would be faster than the likes of php-fpm, which, well, I understand and presume it has significantly less overhead per request, though I’ve never benchmarked it. I have PHP 5.6 installed on my VPS for one old site, and it takes around 27ms to start¹ (compared to under 30μs for just plain `echo`, as a closer indicator of actual process spawn overhead). PHP 8.2 might be faster, but it’s still going to be much slower than `echo`. By simply compiling php-cgi to WASM, it will surely be doing all that initialisation for every request. Because CGI starts everything from scratch for each request, it’s inherently less efficient. In theory you could coordinate a time to snapshot the process/VM/whatever, forking from that point, but that’s not CGI any more. All up, what they’re claiming is so completely contrary to what I would expect (and without any explanation or justification whatsoever), and kinda follows the “dust off something old to laugh at it again” trope, that I’m honestly having to check that it’s not the first of April any more (the article is dated the 6th). So as I say, I’m confused. Option 2 seems very clearly slower and much less efficient, by the very nature of CGI. No one targets CGI (it’s been basically dead for… I dunno, close to twenty years?), because CGI is considerably worse than the alternatives. Can someone enlighten me? Have I missed or misunderstood something? —⁂— ¹ Measured by running this in zsh and reading the “total” figure (across sixteen runs, I got between 2.671 and 3.032 seconds): time ( for i in {0..100}; do php56 <<<'<?="."?>'; done ) The comparative echo test uses `echo -n .` and takes one thousandth as long.

jeremyjh 4y ago
To me this seems a little closer to the architecture of AWS Lambda than OG CGI, though that is not a perfect analogy either since this is in a WASM runtime within their server process, rather than a separate process. But the programming interface is a handler function you provide with an interface that looks like this in Rust: `fn handler(request: Request) -> Response ` My understanding is the main function is called only once, and registers that handler. So `main` is where you'd initialize the majority of the environment, and no that is not truly CGI; definitely no process is being created for each request, but it may be the case that this is more like FastCGI where you have a pool of single-threaded runtimes all setup that way that can handle requests. This still seems inefficient compared to a threaded or event polling process that can handle multiple requests concurrently without having to marshall data back and forth, but I'd think it can get closer to that than FastCGI or Lambda do.

thomasjb 4y ago

This looks good, I'd been thinking about putting my little Python program that prints a random line from a textfile onto my Apache server for the internet to enjoy, this ought to enable it nicely. Where would be best to look for examples? The idea of exposing Python via a normal cgi script is terrifying to me

nuc1e0n 4y ago

FastCGI would be better than regular CGI. Spawning and cleaning up processes is expensive.

adamziel 4y ago

Note WordPress has an official WebAssembly build for the browser and Node.js: https://developer.wordpress.org/playground https://developer.wordpress.org/playground https://github.com/WordPress/wordpress-playground https://github.com/WordPress/wordpress-playground Disclosure: I'm the creator This project is different in that it builds PHP to WASI.

benatkin 4y ago

A bit late, there is already Spin from Fermyon