Many projects start out as small and manageable elegant, homogeneous monoliths in which all components are developed on a common technical basis. However, as project size and complexity increase, subfields emerge that differ in their technical basis. This may be due to changed requirements, priorities of development teams, or integration of third-party software.
Advertisement
Microservices are often considered to bring salvation: software is divided into manageable, independent units that communicate with each other through platform-independent network protocols. Each microservice can be written in its own programming language and use appropriate libraries and third-party components. Although this breaks down technological diversity, it significantly increases overall complexity. Simply calling a function in another microservice becomes an adventure.
It would be great if there were a technology that would make it possible to connect components written in different programming languages without microservices and without any compromise in terms of security, performance and portability. This is exactly the goal of the combination of WebAssembly and WASI, the Web Assembly System Interface.
WebAssembly goes beyond the browser
WebAssembly (Wasm) is a binary instruction language for stack-based virtual machines, originally designed to run applications in the browser at near-native speed. However, Wasm is much more than just a browser technology: at its core, it provides a standardized way to compile code in a compact and platform-independent form, so that the result can be executed on multiple runtime environments, even beyond the browser. Can go. A key advantage of WebAssembly is that it is designed as an assembly language for the cloud and web that runs securely in a sandbox. Sandbox isolation ensures that code does not get uncontrolled access to system resources or other connected components.
Developers can write Wasm modules in multiple programming languages. The resulting bytecode is independent of the source language and runs on all common platforms using the Wasm runtime environment such as Wasm or Wasmar. However, in practice, the implementation of Wasm varies in different programming languages. Some have their finger on the pulse and support the latest developments, others are a little behind. Probably the best programming language for WebAssembly is Rust. Almost all major Wasm tools and libraries are written in Rust and the language provides excellent features for creating Wasm modules. Rust’s focus on security, performance, and portability fits well with the needs of WebAssembly.
WebAssembly System Interface
In addition to Wasm as a basis for platform-independent, secure and executable code, an interface is needed that allows this code to securely interact with the host in the form of an operating system, browser or cloud environment and resources provided by the host. Allows for conversation. , This is where the WebAssembly System Interface (WASI) comes into play. WASI defines a standardized API for system calls that allows WASI modules to use basic functions such as file system access or network communications without sacrificing sandbox security.
While Wasm has long been available in a stable version, WASI is still in development. Versions Preview 0 and Preview 1 already enable basic system calls like file access. The challenge for WASI is that the interface cannot be built on a robust component model. At the lowest level, Wasm knows only basic data types such as numbers and pointers, but does not know structured data types or any elements such as strings. To exchange such data types across WASM module boundaries or with WASI, the corresponding data must be stored in WASM’s linear memory and pointers must be exchanged. The caller and the call recipient must agree on a common data layout. At its core, Wasm does not include any mechanism for describing interfaces between such data structures and Wasm modules.
came into existence to replace it Wasm Component Model As a sub-project. Its goal is to create a standard with related tools for efficient interaction of separately compiled Wasm modules, which can be written in different programming languages. Language (Wasm Interface Type (WIT for short) Serves to describe interfaces between components (export and import).
WASI arrived at the beginning of the year with version 0.2 An important milestone. Update 0.2.1 followed in AugustThe most important feature of the new preview version 0.2 is that it is based on the component model. WASI has published Wasm components with which you can access the functions of the corresponding host. WASI 0.2 currently includes two categories of components (such categories are called worlds in WIT):
wasi-cli(Command-line interface): This world provides stuff like file access, environment variables, random numbers, and sockets for CLI programs.wasi-http:This world consists of functions for HTTP around requests and responses.
More worlds will follow. The upcoming version 0.3 of WASI has the motto async, which means it should enable asynchronous operations.
Combination of WASI and Rust
If Go is the language of the world of containers, then Rust is the language of the world of modules. So it’s no surprise that it didn’t take long for Rust to take its first steps toward supporting WASI 0.2. early may Rust version 1.78 was released With significant innovations in interaction with WASI.
The first innovation is to rename the compilation target wasm32-wasi In wasm32-wasip1P1 stands for Preview 1 and indicates that it is WASI version 0.1. Anyone who has already developed wasm modules with Rust and WASI 0.1 will need to adapt their projects. There is time until the release of Rust version 1.84 in January 2025. Until then, we will slowly say goodbye wasm32-wasi With warnings from the stable version of Rust 1.81. Warnings and errors appear first in the nightly version. Details can be found in the Rust blog,
a war target wasm32-wasip2Building Wasm components for or with WASI 0.2 does not yet exist. However, there is that cargo parameters cargo component ), which temporarily fills this gap. This already allows to reference Vaas components in Cargo.toml in the same way as external crates.
cargo component Creates Rust bindings automatically based on the definition of the interface. The command is an intermediate step towards fully integrating Wasm components into Rust until the cargo itself works with it.
