Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Server-Side WASM: Today and Tomorrow

Server-Side WASM: Today and Tomorrow



Connor Hicks explores WASM today, and the capabilities that it will have tomorrow, using the Suborbital Development Platform to illustrate how WASM modules can be used to compose server APIs.


Connor Hicks leads the Product Discovery team at 1Password. He has been fascinated by distributed systems and web service architecture for a long time, which led him to build the Suborbital Development Platform with the goal of enabling developers to build robust web services as easily as possible.

About the conference

QCon Plus is a virtual conference for senior software engineers and architects that covers the trends, best practices, and solutions leveraged by the world's most innovative software organizations.


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, being able to package up your code in this very simple way. Then allow a framework or a platform to deploy those functions onto a cluster that you just don't necessarily need to understand the structure of, and knowing that it will handle taking the various inputs, whether they're events, or HTTP requests, or whatever, and letting the framework schedule these functions. Trigger them as needed. Then handle the output, is a pretty interesting use case for Wasm. It's these modules because they come out so small, they are compiled down to a very small size, it makes a lot of things really easy. You can put them into an S3 bucket, or you can put them into a registry like WAPM, which is Wasmer's WebAssembly package manager. You can use things like that to very easily deploy these bundles to your server, and have your WebAssembly platform or framework, fetch them, deploy them, and then run them seamlessly.

Suborbital Development Platform

I'm going to give a 30 second overview of the suborbital project that I've been working on for the past year or so, and that is combining these three things to allow for this type of workflow. Vektor is an edge router. It handles various different inputs like HTTP requests and events and whatnot, and allows them to be routed to various modules or jobs. Then Hive, the job scheduler can then flexibly and scalably run these functions and manage their execution. Then Grav is a messaging mesh. This is a term that I think I made up, which is really just allowing your message bus to operate in concert with your service mesh rather than having a centralized broker, like most messaging or eventing systems. Grav actually is decentralized, and so it uses your service mesh to facilitate asynchronous communication between nodes in your system, to make sure that your system is scalable, and you're not hitting the pitfalls of various RPC or HTTP communication when you're looking at services.

Put It All Together - Wasm Powered Server Framework

These three things are the building blocks. They're all in beta right now. They've been quite successful. I've seen some really great results out of these three. On their own, they don't allow for what I've just been talking about, which is these easily deployable Wasm module bundles. The new project wasn't quite ready in time for this presentation. Hopefully, there will be an initial alpha release, and that is what I'm calling Atmo. Atmo uses those building blocks of the router, the job scheduler, and the messaging mesh to create that Wasm powered platform or framework that I was alluding to. The goal of Atmo is really to take those Wasm bundles. It'll take your bag of functions, you can really just build any number of functions. Package them together into a bundle, which is essentially just a compressed archive, along with a declarative description of how those functions should interact with the outside world based on different inputs. Then Atmo will use those three building blocks to handle whatever you describe.

The implication here is that you will no longer need to care about Docker images or you'll no longer need to care about scheduling on a container runtime, you can just let Atmo run in your cluster. It will autoscale itself using whatever technology you're running it on, whether it's an autoscaling group, or Kubernetes, or whatever. Then it's designed to intelligently run those functions as described when you deploy them. You can visit to get emails about the project as it updates. That project there,, should be live by the time this conference exists. I'm hoping that I'll be able to have some examples in that repo that you can look at where functions can be very easily composed to build the business logic and the various different workflows that you're used to, with things like Lambda, and recreated in a compelling way that makes sense because of the power of WebAssembly.

Now Go Build with WebAssembly

I hope this triggers some desire to try WebAssembly. It's a really great technology. I've seen some really incredible things built with it. I do believe that five years from now, WebAssembly will be just as prevalent as Docker and whatnot. I think we're really early on in this ride. I think it's really too early to tell exactly what the prevailing method of building with WebAssembly will be just because the ecosystem and the community is so young. I'm really hoping that this gets you a little bit excited at the potential. I think it's going to be very interesting to see how it all unfolds.


See more presentations with transcripts


Recorded at:

Aug 04, 2021