What are WebAssembly components? The ultimate guide

What are WebAssembly components?

WebAssembly components play a key role in how runtimes that run within WebAssembly modules are deployed. However, its standardization is still under consideration.

When this component model is perfected, WebAssembly not only expands beyond web browsers and servers, but also allows users to run a variety of applications running within many lightweight modules to thousands of endpoints simultaneously at very high speeds. Now you can deploy it. Through a component interface called WebAssembly System Interface (WASI), you don't have to change an iota of code.

At least that's the theory, but the community is working to get there. At the same time, there is a lot of confusion about what a component is and how it is incorporated into his WebAssembly adoption.

How do WebAssembly and components work together?

Before we dive deeper into what a component is and what it does, let's first explain what WebAssembly is, how its evolution has created the need for a component model, and specifically its relationship to the standard interface WASI. is needed. API to link web assembly modules to components.

WebAssembly is designed for developers to deploy applications written in the language of their choice, enabling simultaneous deployment in a variety of heterogeneous environments. “Different” here means that WebAssembly runs on the CPU and only requires a device, server, etc. that can execute the CPU instruction set.

This means that, in theory, a single deployment of an application within a WebAssembly module should be able to run and update on many different devices, including servers, edge devices, multi-cloud, serverless environments, etc. Masu.

WebAssembly is designed to run applications written in a growing number of languages ​​that can be hosted within modules, wherever there is a CPU capable of executing the instruction set. Now supports Python, JavaScript, C++, Rust, and more.

Different applications written in different programming languages ​​should be able to coexist within a single module, but this feature is still under development.

Essentially, a module filled with microservices should be able to deploy multiple services in different environments and provide application updates without having to reconfigure endpoints.

In theory, you can simply configure your application within the module, so once you're done within the module, you don't have to reconfigure it individually in each environment where the module is deployed. However, this also depends on the finalization of component standards.

How did we get from the web module to the server with the components?

The desire to deploy applications everywhere at the same time, as we are currently observing with Kubernetes and Docker, relies on standardization of the component model.

This model is often compared to Lego blocks. These components interface through WASI, where the web assembly module provides the runtime. These components are stacked and linked into a unified package or unit that makes up the components, leveraging the versatility and power of the various WebAssembly runtimes.

The advantage of this approach is that it is secure, similar to how Kubernetes ensures that components do not share memory, namespaces, or data within namespace allocations. They maintain a closed or sandboxed interface through WebAssembly bot modules.

However, achieving standardization is a challenge. The goal is to allow components to run on any system. This allows web assembly modules to seamlessly interact with components and deploy and run on the CPU instruction set. Although it is configured to do so for modules that conform to the standard, this standard is a work in progress and represents the last mile of WebAssembly's journey.

Component development currently plays an important role in the open source community's efforts to advance WebAssembly. Standard component interfaces are being established in innovative ways, heralding a world of possibilities.

A number of open source projects and research initiatives are contributing to this finalization process. For developers, especially those close to his Kubernetes, the inner workings and mechanics of component development may not be of much interest. They primarily want the end result: the ability to run and deploy applications the way they want them, as WebAssembly and Kubernetes become increasingly integrated.

This may remind you of the 80's and 90's when DOS came out and books were written detailing file exchange, configuration, and DOS commands. However, understanding these complexities was not important to most programmers and software engineers, especially given the dominance of Unix and Linux in software development environments.

What does the component consist of?

In the keynote speech at WasmCon held in September, luke wagner A prominent engineer at Fastly, which relies heavily on WebAssembly for certain services on its edge delivery platform, explained in a nutshell what Wasm components are. It is an emerging, standard, portable, lightweight, finely sandboxed, cross-language and configurable module.

He explained that a component is a module that contains imports, internal definitions, and exports. Imports include elements such as imported functions (such as logging functions) and generally provide information about the I/O that a component provides and its implementation, rather than relying on a fixed set of system calls or a runtime global namespace. Capture dependencies.

The internal definition represents the core code being executed, consisting primarily of embedded Wasm modules, and is where 99% of the bytes reside. Internal definitions can also call imports,” Wagner said.

“Components can further nest other components, making them recursive in nature,” Wagner says. “Finally, export creates the internal definition, and import exposes it to the component's clients by assigning a name and type.”

In the world of containers, the Open Container Interface (OCI) defines a standard for distributable containers. Docker build creates a container from source, Docker run and Kubernetes run and deploy it, and Docker Push and Docker compose handle sharing and configuration, Wagner said.

“The obvious question then arises: Can Wasm be used for this purpose?” Wagner asked. “While this is definitely a standard distributable format, the challenge is that Wasm primarily supports shared memory linking. If you want to link two Wasm modules, you typically want to share memory and You need to pass the composite value through that shared memory, similar to an operating system DLL or shared object.”

However, when two or more Webassembly modules are configured, they must maintain their own separate memory that is not shared, Wagner said. He said there needs to be a way to pass complex values ​​between them and transfer ownership of resources that cannot be copied between them, similar to operating system executables.

Is it possible to wrap a Wasm module in Portable Operating System Interface (POSIX) to create a Wasm executable?

According to Wagner, distributing a single POSIX executable is often not enough. This is because you typically need to distribute a collection of executable files that must work together with configuration files, static assets, and a directory structure. The solution, Wagner said, might be to bundle Wasm modules into containers with Wasm as the core instruction set.

“While this approach may be useful, it does not unlock the exciting new use cases we envision,” Wagner said. “To accomplish that, we need something new: a wrapper around Wasm that allows us to use existing compilers. We're proposing this new concept and calling it a 'component.'

What happens next?

It should be noted that the business model is built thanks to the unique capabilities of WebAssembly, which is highly dependent on the completion of the component model.

Already, some developers are choosing Wasm “to run code that they can't run any other way,” Wagner said.

“This will result in us building a set of reusable tools that will enable the first wave of languages ​​and APIs. But these tools are not tied to just one platform; Because we're using a component model, we're able to tap into this meta-ecosystem and bring in a new wave of platform builders who are getting a lot of functionality that they didn't have before. You don't have to build one,'' Wagner said.

“This could attract a large wave of newer developers who choose Wasm for the ease of reuse and productivity of all reusable components. We could potentially build a whole new wave of tools to build and enable entirely new kinds of developer programming models.”

Due to WebAssembly's unique capabilities, it is important to note that business models are emerging around WebAssembly, many of which rely on perfecting the component model.

As Wagner highlighted, developers are now choosing WebAssembly to “run code where they can't do it any other way.” This prompted the development of a set of reusable tools designed to enable the early stages of the language and API.

Because these tools are not tied to a single platform, they widely adopt component models. As a result, a new generation of platform builders have entered the scene, leveraging this meta-ecosystem and gaining access to a plethora of resources without having to develop from scratch.

As a result, a new wave of developers are drawn to WebAssembly, drawn to the ease of reuse and productivity offered through reusable components. This will lead to the development of a new set of tools for composing applications from components and creating new developer programming models.

What is the current status of these developments?

Wagner said a formal specification with operational semantics, a reference interpreter, and a reference test suite is in the works. The important parts were already implemented during his Wasm using BindGen and Wasm tools. Future milestones, aiming for early next year, include synchronizing components with fully parametric links, values, resources, and handle types.

Subsequent major milestones include adding features and streams to the component model and introducing asynchronous support. “Although this is a difficult step, it streamlines much of the duplicative work. Finally, there are still some pieces left to complete the component model MVP, such as optional imports and exports,” he said. states.

BC Gain is the founder and principal analyst at ReveCom Media. His obsession with computers began in the early 1980s when he hacked his Space Invaders console at a local video arcade so he could play it all day for 25 cents. He then…

B. Read more from Cameron Gain