Skip to main content
Version: 1.x

Components

Overview​

Components are portable, interoperable WebAssembly binaries (.wasm files) that implement stateless logic. In wasmCloud, components typically enact the core logic of an application (for example, the API for a web application), while leaving abstracted, reusable capabilities such as key-value storage to capability providers.

In wasmCloud usage and documentation, the term "component" simply refers to a standard WebAssembly component. For example, the wash new component command creates a new component that could be executed with any WebAssembly runtime that supports components. The wasmCloud platform provides a way to run components distributedly.

Features of components​

Components may be compiled from a variety of languages including Rust, Go, Python, JavaScript, and more. Because components can be compiled from many different languages and then interact with one another, they enable developers to break down language silos and utilize libraries and tooling in new ways.

Compilation from a variety of languages

Components can compile from a variety of languages and run across architectures. The wash build command can compile components from any language, leveraging language-specific toolchains.

Components are portable, interoperable, and composable:

  • Portable: Because WebAssembly binaries execute against a virtual instruction set architecture (essentially a tiny VM), they are agnostic to architecture and operating system kernel; they run anywhere there is a WebAssembly runtime. Component binaries are typically much smaller than analogous container images, as well—often measured in kilobytes—enabling them to run in resource-constrained environments where even containers aren't practical.
  • Interoperable: Components can interact with one another over high-level APIs regardless of their respective languages of origin, so that a component written in Rust can utilize the functionality of a library from Go.
  • Composable: Multiple components can be combined into a single binary (or dynamically linked at runtime in wasmCloud). This enables developers to build applications as if with construction bricks, satisfying dependencies with other components as needed.

Additionally, components are...

Stateless​

When a component needs state, it uses a provider. Leaving state to providers enables wasmCloud to orchestrate invocations in complex applications without regard to specific instances of components or where they're running.

Secure​

Components are secure by default. Because WebAssembly components that can't use WASI capabilities directly, they are incapable of interacting with any operating system functionality on their own. The only way components can affect their external environment is through the use of a provider. wasmCloud will only allow calls between linked components and providers.

Reactive​

Components follow the principles of reactive programming: they only run when invoked by another entity. An invocation might originate from another component or provider's function call, a message from the wasmCloud host, or a wash call command from the CLI. In turn, components can invoke exposed functions on components, providers, or the host.

Connected by abstractions​

wasmCloud components are loosely coupled with the providers they use for non-functional requirements. A component doesn't communicate with Redis or Cassandra or Consul; instead it communicates with a generalized abstraction over the keyvalue interface.

An interface represents an abstracted functionality. As long as the provider implements the correct interface, it's considered compatible with your component. A component written using the keyvalue interface should be able to work with any key-value store. This decoupling also enables swapping the store at runtime without requiring a rebuild or redeploy. Learn more about wasmCloud's interface support on the Interface page.

Internally single-threaded​

The surrounding environment of the wasmCloud host may have varying levels of concurrency support. This support may differ depending on whether the host is running in a browser, on a constrained device, or in a VM somewhere. However, the code for components should be independent of these conditions and never have to change, even if the surrounding environment adopts a different concurrency model.

Note

While it's nice not worrying about the underlying concurrency model, it's important to understand that single-threaded code has the potential to create bottlenecks. Therefore, when developing message handlers for components, embrace the design of performing small amounts of work in a "get in and get out fast" approach. Divide the work into the smallest bits possible, and perform each bit as fast as possible. This approach maximizes the benefits of external concurrency while still keeping the code simple and synchronous.

Flat in hierarchy​

In a zero trust environment, allowing components to spawn others is a security risk. wasmCloud maintains the horizontal scale of components with an entirely flat hierarchy.

Open standards​

The wasmCloud project is committed to supporting a componentized ecosystem and remains up-to-date with the latest versions of the Wasmtime WebAssembly runtime and WASI 0.2, a set of standard APIs designed to allow WebAssembly components to access external resources in a safe and portable way.

Components are defined according to the Component Model, an open standard governed by the W3C WebAssembly Community Group that describes a layer of specification in addition to that of a core WebAssembly module.

In principle, any language can compile code to a component; the maturity of compilers varies by language, and component tooling is developing rapidly since the release of WASI 0.2 in January 2024. You can find practical tooling for working with components in Useful WebAssembly Tooling.

Keep reading​

Continue to learn more about providers, or...