Apache httpd is a modular web server that powers 31% of all websites you access every day. One of its most compelling features is the ability to extend it with new modules. Developers can choose among different modules to add or remove features like CGI, TLS, PHP, and many others.
Today, we announce a new Apache module to run WebAssembly modules: mod_wasm. This module opens a new set of possibilities as many languages and projects can run securely in Apache.
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.
* 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.
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.
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.
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.
WASM is still too unapproachable. I've looked into how to build things for WASI/WASM and it seems like you're just dropped into this world of tooling and development practices that I'm sure makes tons of sense to people who are already steeped in the WASM ecosystem but is disorienting for someone new.
WASM really needs some getting started guides that describe what the hell is going on and what the capabilities and limitations are and how to... well... get started.
Totally agree with you. WebAssembly has a lot of potential, but currently the entry barries is quite high and for some use cases, it's not mature enough. As you mention, tooling is unclear, and the ecosystem misses important features such as debugging capabilities.
However, at the same it's an exciting ecosystem for the same reason: there's a lot to explore and improve. Hopefully, these projects we are building gathers the interest from different communities and more people start adding ideas.
And for future ideas, what would you like to be covered in an article about WebAssembly? Thanks!
All the tooling seems geared to outputting "glue code" as typescript or javascript, and I've yet to find any real documentation on if it's even possible to do so for other languages without massive amounts of manual work.
So my initial elation at finding a warm extension for php (wasmer-php), which would let us bolt in secure, sandboxed scripting languages for customer projects... Is now on the back burner as while it can run some example wasm, anything made with wasi or emscriptem is unusable.
I think you need to look at the WASM documentation for specific languages rather than generic wasm. For example Rust has decent documentation for this. The tools and instructions are going to be language specific.
I always found it uber cumbersome to deal with apache to setup different webservers with different domains and different stacks (php, golang, node, etc.) on a linux server.
I’ve been doing it for more than 10 years and I still hate it and I’m still quite lost in the commands I need to run, the folders and files and cfgs I need to maintain.
Am I just a linux noob and this is completely normal user experience?
The biggest problem with Apache httpd is how many awful copy/paste blogs there are out there telling you how to do things on Ubuntu, which has no resemblance at all to actually managing httpd. Everything explains how to use some silly wrapper script like a2enmod to do something when all you really need is to make a symlink or something like that. IMO, the Ubuntu method of managing httpd could easily be responsible for why so many people think nginx is easier.
Use a RHEL based system and manually edit the files yourself. It’s very easy.
Apache itself is eminently manageable on its own; IMO the real issue is how insanely over-complicated and opinionated every distribution makes their configuration.
I tend to discard any given distribution's default configuration for a more simplistic one where httpd.conf is the source of truth. This is very simple for 90% of my use cases, and for the other 10% I can adopt of a "modules-enabled, sites-enabled, conf-enabled, kitchen-sink-enabled" type approach.
I struggle to understand wasm, though I'm interested. What does this part mean?
> Internally, it uses the wasmtime runtime to configure, initialize, and run the Wasm modules.
What is wasmtime? I looked at its page and couldn't figure out what they mean by a wasm runtime. I thought the runtime was in the browser. Wouldn't a user just need to compile and just a binary?
It can be both! Like JavaScript, WebAssembly started in the browser but is now moving to the server-side, too. With JavaScript, the most common serverside runtime is Node.js. With WebAssembly, it's Wasmtime. There are alternatives (like Deno or Bun for serverside JavaScript), but Wasmtime is the main one at the moment.
It is a runtime for wasm. Wasm is not executable in the same way an x86 binary is. It needs to run in a vm. Wasmtime is one such vm. In a browser context that vm is v8.
Easiest comparison is the JVM. You can run Java wherever you have a JVM, be it the browser or the server or a desktop application. WASM is basically the moral equivalent of JVM bytecode, so you need the moral equivalent of the JVM to run it.
While all major browsers have wasm support (the wasm "JVM") as part of their javascript stack, there's also standalone wasm runtimes, with wasmtime being one of those.
It appears to be a language that you compile another language into so that you can get more inception-like while sacrificing performance optimizations of using a native language.
It would still require the host to have the module installed, right? That might come to be common, but it is a requirement that I don't expect everyone to decide to implement
So it requires the nginx Lua module which is then used to load the wasm blobs? what a weird module. So somehow this thing is going through at least 2 or 3 different VMs (LuaJIT + WASI) so that you can eventually run your Python script in nginx...
WASM is basically a way to deliver the old JVM promise of "compiled once, run everywhere, sandbox if needed", with the additional constraint of "close-to-native performance" and "any language can compile down to it". It's a good thing if it delivers on all those promises. And it's especially a good thing if you don't like JS, because it's our best shot at dethroning JS.
I think Cargo and GoReleaser already make this simple enough. Heck, even Alpine Linux has down the process of compiling for multiple architectures for multiple languages. It really isn't that much of a challenge to do so and there are already sandboxing solutions for each operating system. WASM doesn't get rid of JS, it just puts sandboxing into a JS-based engine. The last thing people should want is to run binary blobs in your browsers which is exactly what it does. The same browsers who gladly trade privacy at ever iteration. Might as well just go publish your browsing history online cause that is where this will lead.
Wasm doesn't get rid of JS in the browsers right away (but long-term I suspect that JS is going to be implemented on top of wasm). Wasm itself is not JS-based tho, as evidenced by all the standalone wasm runtimes.
And it's not any more or less transparent than a minified blob of JS.
Well, one the developers are smart enough to create optimized packages for each architecture but instead if they wanted to cater to bad practice JS fans they could create a universal binary.
And portability without recompile or negotiating different delivery for different targets, and being able to run in a common browser that nearly every user connected internet capable device already has.
Today, we announce a new Apache module to run WebAssembly modules: mod_wasm. This module opens a new set of possibilities as many languages and projects can run securely in Apache.