Live data from Hacker News

Announcing WCGI: WebAssembly and CGI

wasmer.io

21–30 of 121 posts

Re: Announcing WCGI: WebAssembly and CGI

#22

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”

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)

Re: Announcing WCGI: WebAssembly and CGI

#23
post #7

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 hea…

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

I would also mention that, especially in the past, the JVM sandboxing was not great. Which is why Applets were such a problem.

Re: Announcing WCGI: WebAssembly and CGI

#25

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…

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.

Re: Announcing WCGI: WebAssembly and CGI

#26

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…

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 pro…

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.

Re: Announcing WCGI: WebAssembly and CGI

#27

Earlier quoted context omitted.

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?

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 (…

> 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 - they claim their Docker image is 40 MB compressed, whereas Wasmer for amd64 (latest from 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 Starting a fresh VM for every request doesn’t make sense, so this difference wouldn’t matter in real life.

Re: Announcing WCGI: WebAssembly and CGI

#29

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

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.
Post reply on HN