Server-Side WASM: Today and Tomorrow



Hicks: My name is Connor Hicks. I’m a senior developer at 1Password, in the product discovery team. I’m here to talk about WebAssembly in a way that might not be familiar to some of you, and that is WebAssembly on the server. WebAssembly is traditionally a browser based technology. It actually has quite an interesting potential on the server side. I’m going to talk about server-side Wasm as it is today, and what it could be in the future. We’ll cover Wasm today. We’ll cover Wasm runtimes. We’ll look at Wasm at the edge, which is an interesting set of functionality by a couple of different cloud vendors. Then we’ll talk about Wasm on the server and all the different potential that it has in that context.

Wasm Today – Major Browser Support

Wasm today is something you might be more familiar with, it’s the more traditional context that WebAssembly is talked about, and that is using WebAssembly to compile code that isn’t JavaScript, generally, to be used in the web browser. A great example of this is our 1Password X browser extension, has been using Rust compiled to WebAssembly for a long time. The engine that analyzes your web pages and determines where to fill in your various 1Password items like your logins and your passwords, that’s been a WebAssembly module for quite a while now. We saw an order of magnitude increase in performance when we adopted that method, actually. Some other examples are Blazor, which is a C# way of building web applications. Vugu, which is Go. Yew which is Rust. Qt for Wasm, which is a C++ Library. These are all different languages being used for the same thing via WebAssembly. You can take the native code written in these various languages, compile it down to the common WebAssembly format, and then your browser can run that module. It allows it to interact with the DOM. It allows it to bind to functions and APIs that are available through JavaScript and the other browser APIs. It allows you to run the same code that maybe you have on your server, sharing data types, and all these kinds of things. There are some really fascinating use cases for WebAssembly on the client side. We’re here to talk about WebAssembly on the server.

Runtimes – Wasm outside the Browser

How do you run WebAssembly outside of the browser? You need a runtime. A runtime is an application that runs on the command line or via a static library that allows you to load your Wasm module and run it as if it was just any other program. Wasmer, WasmTime, Wasm3, WAVM, and Lucet, these are some common emerging Wasm runtimes that have been coming out from the community as of late. They’re really starting to build this ecosystem of capabilities to run Wasm anywhere. You could theoretically run them on anything from a massively powered server, down to a Raspberry Pi or an embedded system. This is really great because it decouples Wasm from the V8 runtime and the browser’s cage that it’s been in for a long time. It allows us to add capabilities to Wasm to make it useful on the server.

Wasm at the Edge – Enhancing Services

Wasm at the edge is not a new concept actually, it’s something that has been available for quite a while now. Some examples you may have heard of are Fastly Compute@Edge and Cloudflare Workers, and this has come around because of the performance that has been found in compiling languages to WebAssembly. You’ve been able to take your Rust or C++ code and bring it down to this common format, WebAssembly. Then these cloud providers can actually run these modules in an extremely lightweight manner, right at the edge of their network. In the Cloudflare Worker example, they have data centers all around the world, and so, in less than 30 milliseconds away from any given user, your WebAssembly module can be triggered to modify requests, do caching, do all sorts of different tasks. Because this format is so lightweight, and because the capabilities of the native code are so powerful, there’s unlimited different possibilities that you can use this style of Wasm module. They’ve been adding capabilities steadily for a while now and there’s some very interesting potential going on here.

Community Projects – Server-side Wasm

There’s also a number of very compelling community projects that have been coming out as of late. If you’ve been to some WebAssembly related conferences like WebAssembly Live or the WebAssembly Summit, this past year, there were some really great presentations about a couple of different projects that are being built to make WebAssembly more useful outside of the web browser context. Something like waPC, which is the WebAssembly Procedure Call standard, is adding to the ability for WebAssembly modules and the host code to communicate with each other via procedure calls. While having your module interact with a Go server that is hosting the module, previously may have been pretty difficult just because of the limited memory layout of WebAssembly, waPC simplifies that and provides a standardized method for doing that across FFI communication. They’ve been adding all sorts of different features and language support. I think they support all sorts of different languages like TypeScript and Rust and C++. That’s a really great project.

Then, waSCC is a framework, a project that is allowing for the actor pattern to be implemented using WebAssembly modules. Being able to bind capabilities to your Wasm modules, things like a Redis Cache, or an HTTP server can be dynamically bound to a WebAssembly module. Those capabilities can be controlled very tightly by the host that is running the module. The modules themselves, the code that was written for those modules doesn’t need to be directly aware of them, they can just bind to a set of APIs. It gives you really powerful control over what is running in your server-side code. Then we have things like SSVM, which is a project for running WebAssembly with applications like AI models, and for blockchain applications like smart contracts. This is an emerging project that’s been gaining some steam. I suggest you go check that one out. I think it’s pretty interesting. Then there’s Atmo. The goal of Atmo is to enable a more seamless experience when building WebAssembly modules for the server. It’s going to be making things much easier for developers when wanting to run WebAssembly in a web service type scenario.

How Wasm Can fit into a Server-side System

How can Wasm fit into a server-side system? We’ve been seeing some patterns emerge lately in the server-side development community, which is the desire to simplify, and that is coming in the form of things like Functions as a Service, or serverless technology. There’s AWS Lambda, OpenFaaS the serverless framework, things like that are really designed to make things simpler, again, because things have gotten much more complex in the last 5 or 10 years, with the rise of microservices and whatnot. It’s made things more difficult. Bootstrapping a simple service should not require you to need to understand all sorts of container runtimes and different virtual networking technologies, so the desire to simplify has been around for quite a while. This idea of creating simple, unified function-based applications is something that’s been coming around for quite a while now. I think that Wasm can really help with this goal by building these very tightly constrained, highly composable modules from various languages, really whatever you want, and fitting them together into whatever configuration that you need for your application, is pretty compelling. Allowing some framework or hosted system or platform to really take on all of the complexity and just let you write these functions, that’s going to be a pretty great way to build out different types of services, all the way from the simplest cases, all the way up to more complex and larger typography systems.

Wasm Module Bundles

This idea of Wasm module bundles is something that I’ve been exploring with the Atmo project, and that is the ability to write a whole bunch of standalone, singular functions that each perform a very tightly constrained job. Then being able to describe in a declarative manner, how those different functions should be triggered. Then bundling all of that up into a single thing that can be easily deployed. It’s been pretty interesting and I think it’s very ergonomic from the developer’s perspective but also from the DevOps side,…


Read More:Server-Side WASM: Today and Tomorrow