4 Interfacing Wasm with the underlying system

 

This chapter covers

  • Implementing APIs with WASI
  • The new capabilitiews of WASI 0.2
  • Converting a Wasm Module to a Wasm Component
  • Using WASI-Virt to restrict or allow component capabilities
  • Composing Wasm components together

At this point in our exploration of Wasm for server-side development, we have a somewhat clear picture of what Wasm modules and what Wasm components are, together with the differences between the two, as illustrated in figure 4.1.

Figure 4.1 Comparing Wasm modules and Wasm components

Wasm modules are core Wasm—they are what we got from the first implementation of the Wasm spec. A binary format with four basic types and a linear memory block that sets the stage for very quick (near native) and safe (sandboxed) execution of code—be it in a JavaScript engine (on the browser) or in a Wasm runtime (on the server).

Wasm components, on the other hand, build on top of Wasm modules to expand their versatility and make certain interactions much smoother. While Wasm modules are intentionally low-level — giving developers the freedom to build exactly what they need — components take that foundation and add a clear, standardized way for different Wasm programs (or a Wasm program and its host) to talk to each other.

4.1 The WebAssembly System Interface

4.2 What can you build with WASI?

4.2.1 Creating a CLI Application

4.2.2 Creating Libraries

4.2.3 Creating HTTP proxies

4.3 Converting a Wasm module to a Wasm component

4.4 Managing component capabilities

4.5 Composing components together

4.6 Expanding our example project with WASI and composability

4.7 Summary