Wie Fastly und die Entwickler-Community in das WebAssembly Ökosystem investieren

We built Compute, our new serverless compute environment now in beta, to give developers more power, scalability, and speed at the edge. And we decided to build Compute on WebAssembly. We chose WebAssembly because it's an emerging technology that we believe lays the foundation for what edge computing will become: a more performant and flexible place to deliver websites and applications.

The WebAssembly ecosystem is young but growing fast, and we’ve been collaborating with the community to develop key technologies that unlock WebAssembly’s potential to transform edge computing and beyond. Below, we’ll walk through four important open-source projects we’ve been working on as part of the WebAssembly Community Group and the Bytecode Alliance, as well as overview two more technologies the community is building with Fastly’s support. We hope this illuminates not only where we see things moving directionally, but also inspires you to get hands-on and experiment.

A system interface for WebAssembly

The WebAssembly System Interface (WASI) takes WebAssembly beyond the browser, allowing it to work on any operating system while ensuring portability and security. We’ve been working on both the specification of WASI, an open standard underneath the umbrella of the WebAssembly Community Group, and on an implementation as part of the Bytecode Alliance. This implementation powers both Fastly’s own Lucet and Mozilla’s Wasmtime runtime.

At the very start of the WASI standard, our colleagues at Mozilla wrote a C header file that described the WASI interface, and together we wrote implementations for the host and guest sides of that interface in C, Rust, and AssemblyScript. The reception of WASI from the community was very enthusiastic and soon we had many parties implementing the interface in more languages. We also started the work of revising and expanding the interface to be more flexible, more correct, and expose more capabilities of the underlying system.

As all these changes were underway, we quickly determined that a C header was not the most universal way to specify the standard. We needed something more flexible and expressive that could work with the huge variety of programming languages that were targeting WebAssembly. And, most importantly, we needed to enable code generation to take care of the tedious, error-prone, and security-critical work of maintaining the very lowest-level implementations of an evolving standard.

That’s where the witx file format comes in, which is a machine-readable description of the WASI standard. Its design draws on the WebAssembly text format, and is informed by and evolving alongside related standards proposals like Module Types and Interface Types. We helped develop the canonical witx parser and validator, along with several code generators that power WASI implementations. Witx has become a central part of the WASI standard and is enabling a broad community to propose standard interfaces for cryptography, neural networks, and more.

Witx is now used to generate both interfaces to, and implementations of, the WASI standard for several programming languages.  These include:

• WASI Libc
  This is an implementation of the C standard library, targeting WASI as the system call layer. It was the original reference implementation that launched the WASI standardization effort, but it’s no longer the canonical description. Instead, it looks up the canonical one and generates the header.

• wasi Rust crate
  Generated from witx, this crate provides Rust API bindings to WASI APIs, and enables Rust users to keep up to date with changes to WASI.

• wasi-common Rust crate
  This crate provides a common implementation of WASI host calls in WASI-enabled runtime environments such as Wasmtime and Lucet.

All these tools make it easier for you to use Wasm and WASI with your C and Rust programs, enabling you to use the languages and workflows you’re most comfortable in.

Meanwhile, wig and wiggle are two generations of automated tooling related to witx. wig served as the first attempt at using witx inside wasi-common, while wiggle — a successor to wig that now powers wasi-common — offers better ways of handling security properties.

Both witx and wiggle are taking incremental steps toward implementing the WebAssembly interface types proposal, which will make Wasm even more powerful and portable. Interface types will make it seamless for a WebAssembly module to interoperate with different environments using rich APIs and complex types such as arrays, objects, and strings — without requiring any glue code or extra build steps.

A framework to improve security

When we released Lucet as an open-source project, we hoped that it would be useful beyond just edge computing. One place we’re very proud to see Lucet used for making client-side computation more secure is in Mozilla’s RLBox sandboxing project. 

Firefox uses third-party libraries for decoding audio, images, and video. These libraries are mostly written in C or C++, which are notorious for security vulnerabilities. Mozilla Firefox engineers partnered with researchers at the University of California San Diego, University of Texas at Austin, and Stanford University to create RLBox — a framework for improved web browser security — which is built on our Lucet WebAssembly runtime. The Lucet team at Fastly collaborated with these partners on improvements to Lucet in order to make it useful in more contexts. Together, we have added support for generating Mac OS and Windows object code, and made aspects of the runtime pluggable for integration with RLBox.

RLBox takes a sandboxing approach: it compiles C/C++ code to Wasm code, then uses Lucet’s ahead-of-time compilation model to build Wasm into sandboxed native code that ships as part of Firefox. This means security vulnerabilities found in that piece of code are contained within the WebAssembly sandbox, limiting any exploits to that sandbox. As an added safety measure, data coming out of the sandbox is validated before use.

This sandboxing technology has been integrated into Firefox to boost the browser’s security. RLBox is also available as an open-source project on GitHub, so you can use it as a sandboxing tool to separate third-party libraries from your app code, preventing any security issues found in those libraries from affecting the parts of your codebase that use them. We are proud that Lucet is helping RLBox keep Firefox users safe, and we hope to see RLBox used in more places where untrusted third-party libraries pose a security risk.

A language to make WebAssembly more accessible

TypeScript is a programming language developed by Microsoft as a superset of JavaScript. It extends the language by adding static type definitions to it. But as it is, you can’t run TypeScript on WebAssembly: no compiler exists yet, and aspects of the TypeScript language that are designed for interoperation with JavaScript are very challenging to compile to fast, efficient WebAssembly.

That’s where AssemblyScript comes into play. It’s a close relative of TypeScript designed to work on WebAssembly by compiling the typed subset of TypeScript to WebAssembly. This makes it easier for developers skilled at TypeScript to pick up and learn AssemblyScript, and convert existing TypeScript codebases to AssemblyScript with minimal effort — compared to changing their TypeScript to radically different languages like C or Rust. AssemblyScript also allows JavaScript developers to write WebAssembly modules using tools they’re comfortable with, such as npm and JavaScript bundlers.

We believe AssemblyScript holds a lot of promise, and it’s one of the languages we’re evaluating to be supported by Compute. Fastly engineers are actively working on improving the AssemblyScript compiler and ecosystem. We’re also sponsoring it through Open Collective alongside companies like Shopify, which is building a developer SDK powered by AssemblyScript and Lucet, allowing merchants to create synchronous plugins for Shopify’s commerce platform.

With WebAssembly, the possibilities are endless

Fastly is committed to helping the WebAssembly ecosystem and community flourish. We’re investing in these standards and projects not only to deliver an incredibly powerful, performant, and secure edge compute platform in Compute — but also because WebAssembly is a uniquely promising technology for a wide variety of applications. We’re excited for the continued collaboration ahead with the community as we keep building out the Wasm ecosystem, and will keep you updated as new technologies emerge. With these new WebAssembly-based technologies, we hope that you, too, will discover the power of Wasm — whether that’s through realizing new ideas, or finding better, smarter, and more secure ways to approach your current projects.