Hacker News new | ask | show | jobs
by MobiusHorizons 1358 days ago
What is the actual problem this is trying to solve? Are there programming languages it was previously hard to write web apps in? Do people not like setting up nginx?

From my understanding the benefit of wasm on the server side is generally that you get the sandboxing inherent in the VM. Why would you want that in the context of Apache? Are people planning on running untrusted code?

If mod_wasm is designed to address any of those issues (which are touched on only briefly in the article), it would be nice for it to describe how using wasm improves over other techniques one might use to solve those problems like using containers or VMs for encapsulating the execution environment.

8 comments

Two types of developers I guess. ¯\_(ツ)_/¯

I think this has a bright future ahead:

* wasm has a lot of traction, just yesterday I wrote a first test on deploying wasm to cloudflare workers (the latency when the deployed function was really low)

* apache httpd is still one of the most used http servers in the wild

So, I think it's just a natural fit.

wasm will be huge, btw, if you haven't noticed that you haven't been paying attention.

Running WebAssembly modules in Apache http server allows devs to run many different languages by targetting Wasm. This includes interpreted languages like the Python example from the article.

With the WebAssembly sandboxing capabilities you're getting a high level of isolation without adding overhead to the system. VMs and Containers require to run more complex environment for runnning the code. And even you're running trusted code, sandboxing is still relevant as vulnerabilities in source code can let attackers gain unexpected privileges.

mod_wasm was created to bring these benefits to Apache. We found this project interesting as this expands the Apache capabilities while keeping things secure :)

I understand that, but was it really hard to deploy web apps in any of those languages before? Granted, you wouldn’t use Apache to run them, but the current reverse proxy through nginx method seems much better in terms of complexity and performance than wasm + Apache. Am I missing something?
About complexity / effort, there are multiple things to take into consideration. In the case of deploying an application, in Wasm the complexity is on the compilation side. However, once you have your app compiled into Wasm, it's a portable binary you can move anywhere. For other apps, you may need to deploy source code, install the required dependencies in the remote environment and configure it.

It's true that Wasm lacks of the tooling and ecosystem than other apps have. You can find infinite tutorials about how to deploy a Python app. You will find a few for publishing a Wasm module.

And about performance, you are right. Currently Wasm introduces a performance penalty, although the different runtimes are working hard on it. The other side of this is that you gain an extra isolation layer that improves the security. By default, an application won't be able to access any resources on the system.

Said this, WebAssembly is still in the early stages. mod_wasm is a way to bring this technology to a well-known web server. However, it is not meant to start moving all your workloads now as it's still not mature enough :)

One of the reasons PHP gained so much traction was because it is very easy to deploy and run, no dependency hell. WASM is self-contained and has the same property.
Now it is the battle of keeping the zillions of JavaScript packages vs PHP packages up … to … date.

I think WASM may have bigger problems with external vulnerability assessment team identifying those modules by version that got broken.

WASM is the wrong level of the software stack to check for outdated versions, that's the host language's package manager's job.
Wrong? There isn’t a right or wrong about this.

It is often the job of vulnerability assessment team to get down to the root of the misbehaving components, WASM or not.

Yes there is. Fixing WASM for anything but VM holes is like changing your CPU because your Login screen accepts "password" as valid for every user name.
Until you encounter a misbehavin’ module.
I don't think they're different issues in terms of solution, important, of course.
Think in the minimum container you need to run some Python code (>300MB?). Now, compare that to just the Python interpreter compiled into Wasm (25MB). If you need deploy that into different nodes, that's a huge difference.

Also, Wasm modules don't have cold-starts as containers.

Regarding running untrusted code, ask the folks at AWS, Azure or Google Cloud dealing with that...

There are lots of languages with wasm compilers now and not all of them are commonly used for web development. For example, C / C++ is not really used for web development. It's used for a lot of servers of course. But deploying native code to run on a web server is risky. With this you could sandbox it. Likewise with Go or Rust. Both of those are used for web development of course so maybe not the most logical choice to deploy that in Apache.

However, the number of languages that support wasm is growing rapidly and this is a language neutral solution that should work for all of them.

One advantage wasm and wasmtime have over containers and vms is that it's a very low latency thing to fire up. It's very fast. That's why it's so popular for edge computing as well. And it also makes it very suitable for use in an apache module. I guess you could do an Apache module that fires up a docker container to execute some code but that sounds like it would have a bit of overhead. It would not surprise me if somebody already built something like that.

Anyway, this gives people more places to run wasm code. Not a bad thing. This might actually become a nice way to implement some way of implementing some kind of self hosted "serverless" type thing to run lambda functions in the form of wasm blobs. Just one of many things you could do with this.

> Do people not like setting up nginx?

I don’t.

But I’m just cranky… apache httpd works well for me and I don’t feel the need for nginx.

I'm not sure, other than "I can do that too" kind of things... I would probably lean towards Deno, Cloudflare's worker runtime and wasmer all before this.
"Are people planning on running untrusted code?"

I run code that I pull from GitHub, PyPI and NPM every day. I'd feel a whole lot more comfortable running it in a WASM sandbox. People ship bugs!