WebAssembly 组件模型深度解析：当「一次编写，到处运行」终于成为现实

一、背景：WebAssembly 的「最后一公里」难题

1.1 从浏览器到云原生的跨越

2019年12月5日，W3C 正式宣布 WebAssembly 成为继 HTML、CSS、JavaScript 之后的第四大 Web 标准。这个消息在技术圈引起了不小的震动——终于，我们可以在浏览器里以接近原生的速度运行 C/C++/Rust 代码了。

但 WebAssembly 的野心远不止于此。

从设计之初，WebAssembly 就刻意避免与浏览器绑定。它的设计目标很明确：成为一种通用的、可移植的、安全的、高效的字节码标准。这意味着，WebAssembly 理论上可以在任何地方运行——浏览器、服务器、边缘设备、物联网、甚至汽车嵌入式系统。

然而，理想很丰满，现实很骨感。

1.2 模块隔离的困境

WebAssembly 核心规范定义了一个「模块（Module）」的概念。模块是 WebAssembly 的基本编译单元，它包含：

• 线性内存：一段连续的内存空间，模块独占
• 表（Table）：用于存储函数引用，实现间接调用
• 全局变量：模块级别的状态
• 函数：可执行的代码

问题来了：每个 WebAssembly 模块都是一座孤岛。

;; 模块 A
(module
  (memory (export "memory") 1)
  (func (export "add") (param i32 i32) (result i32)
    local.get 0
    local.get 1
    i32.add
  )
)

;; 模块 B
(module
  (memory (export "memory") 1)  ;; 独立的内存空间！
  (func (export "multiply") (param i32 i32) (result i32)
    local.get 0
    local.get 1
    i32.mul
  )
)

模块 A 和模块 B 各自拥有独立的内存空间，它们无法直接共享数据。如果想让它们协作，你只能：

1. 通过宿主环境中转：JavaScript 或其他宿主语言充当「桥梁」，在两个模块之间拷贝数据
2. 使用共享内存：需要特殊的 SharedArrayBuffer 支持，且存在安全限制
3. 直接合并模块：把多个模块编译成一个，但这失去了模块化的意义

这就像是你有两台电脑，但它们之间没有网络，只能通过 U 盘拷贝文件来交换数据——效率低下，且容易出错。

1.3 类型系统的缺失

更麻烦的是，WebAssembly 1.0 只支持四种基本类型：

• i32：32位整数
• i64：64位整数
• f32：32位浮点数
• f64：64位浮点数

没有字符串、没有结构体、没有数组、没有对象……所有复杂数据类型都需要开发者手动编码成这四种基本类型的组合。

// 你想传递一个字符串？
// 对不起，WebAssembly 只认识数字
// 你得这样搞：

// 方案1：通过线性内存传递
// 1. 在内存中分配空间
// 2. 把字符串写入内存
// 3. 传递内存偏移量和长度
void pass_string(const char* str, int len) {
    // 宿主环境需要知道如何读取这块内存
}

// 方案2：使用 postMessage 风格的序列化
// 把复杂对象序列化成字节流，再反序列化

这种「原始」的数据交换方式，让跨语言、跨模块的协作变得异常痛苦。你不仅要处理内存布局，还要考虑字节序、对齐、生命周期管理……一不小心就会踩坑。

1.4 「最后一公里」的呼唤

WebAssembly 社区很早就意识到了这些问题。2022年，Fermyon 的联合创始人 Matt Butcher 在接受 The New Stack 采访时说：

"WebAssembly 在其他运行时技术方面具有少数小优势。组件模型是最大的不同。这开辟了以前从未存在过的开发途径。公平地说，这对 WebAssembly 是一个重要的存在时刻。"

组件模型（Component Model），就是 WebAssembly 的「最后一公里」——它要解决的核心问题正是：

1. 跨模块通信：让不同模块能够安全、高效地交换复杂数据
2. 跨语言协作：让用不同语言编写的模块能够无缝组合
3. 标准化接口：定义一套通用的接口描述语言，消除「方言」障碍

二、组件模型：架构与核心概念

2.1 从「模块」到「组件」

组件模型在 WebAssembly 核心规范之上，引入了一个新的抽象层：组件（Component）。

┌─────────────────────────────────────────────────────────┐
│                      Component                          │
│  ┌─────────────────────────────────────────────────┐   │
│  │              Component Instance                  │   │
│  │  ┌─────────────┐  ┌─────────────┐              │   │
│  │  │   Core      │  │   Core      │              │   │
│  │  │  Module A   │  │  Module B   │   ...        │   │
│  │  │  Instance   │  │  Instance   │              │   │
│  │  └─────────────┘  └─────────────┘              │   │
│  │         ↑                ↑                      │   │
│  │         └────────────────┘                     │   │
│  │           共享的组件实例上下文                    │   │
│  └─────────────────────────────────────────────────┘   │
│                         ↑                              │
│                    导出接口                             │
└─────────────────────────────────────────────────────────┘

组件是一个容器，它可以包含：

• 多个核心 WebAssembly 模块
• 模块之间的连接关系（导入/导出的绑定）
• 对外暴露的接口定义

关键区别：

2.2 WIT：WebAssembly 接口类型

组件模型的核心创新之一是 WIT（WebAssembly Interface Types）——一种接口描述语言。

WIT 让你能够用一种高级、声明式的方式定义组件之间的接口：

// 定义一个文件系统接口
interface filesystem {
  // 资源类型：文件描述符
  resource file-descriptor;

  // 打开文件，返回文件描述符或错误
  open: func(path: string, mode: open-mode) -> result<file-descriptor, error>;
  
  // 读取文件内容
  read: func(fd: file-descriptor, len: u64) -> result<list<u8>, error>;
  
  // 关闭文件
  close: func(fd: file-descriptor) -> result<_, error>;
  
  // 枚举类型
  enum open-mode {
    read,
    write,
    read-write,
  }
  
  // 记录类型（结构体）
  record error {
    code: u32,
    message: string,
  }
}

// 定义一个 HTTP 处理接口
interface http-handler {
  // 处理 HTTP 请求
  handle: func(request: incoming-request) -> result<outgoing-response, error>;
  
  record incoming-request {
    method: string,
    path: string,
    headers: list<tuple<string, string>>,
    body: option<list<u8>>,
  }
  
  record outgoing-response {
    status: u16,
    headers: list<tuple<string, string>>,
    body: option<list<u8>>,
  }
}

WIT 支持的类型非常丰富：

• 基本类型：u8, u16, u32, u64, s8, s16, s32, s64, f32, f64, bool, char
• 字符串：string
• 列表：list<T>
• 元组：tuple<T1, T2, ...>
• 选项：option<T>（可能存在或不存在）
• 结果：result<T, E>（成功或失败）
• 记录：record { field: type, ... }（类似结构体）
• 变体：variant { case1, case2(ty), ... }（类似枚举或联合类型）
• 资源：resource（有生命周期和所有权语义）

这些高级类型会在编译时自动转换为底层的内存布局和编解码代码，开发者无需关心细节。

2.3 组件的组合

组件模型最强大的特性是组合性——你可以把多个组件嵌套组合成一个更大的组件。

// 定义一个世界（World）——组件的完整接口
world my-app {
  // 导入外部接口
  import filesystem: filesystem;
  import logger: logging;
  
  // 导出对外接口
  export http-handler: http-handler;
}

这个 my-app 组件：

1. 导入 filesystem 和 logger 接口——它依赖这些外部能力
2. 导出 http-handler 接口——它对外提供 HTTP 处理能力

当组件实例化时，运行时会自动将导入的接口绑定到宿主环境提供的实现，并将导出的接口暴露给外部调用者。

┌─────────────────────────────────────────────────────────┐
│                     宿主环境                             │
│  ┌─────────────┐  ┌─────────────┐                      │
│  │ Filesystem  │  │   Logger    │                      │
│  │ Implementation│ │Implementation│                    │
│  └──────┬──────┘  └──────┬──────┘                      │
│         │                │                             │
│         ▼                ▼                             │
│  ┌─────────────────────────────────────────────────┐   │
│  │              my-app Component                    │   │
│  │  import filesystem ────────────────┐            │   │
│  │  import logger ─────────────────────┼─── 绑定    │   │
│  │                                   │            │   │
│  │  export http-handler ──────────────┼─── 暴露    │   │
│  └─────────────────────────────────────────────────┘   │
│                         │                              │
│                         ▼                              │
│                   外部调用者                            │
└─────────────────────────────────────────────────────────┘

2.4 能力导向安全模型

组件模型采用**能力导向安全（Capability-Based Security）**模型。

传统安全模型基于「信任级别」或「权限列表」：某个用户或角色拥有某些权限，可以执行某些操作。

能力导向安全则完全不同：只有显式传入的能力才能被使用。

// 传统模型：检查权限
if user.has_permission("read_file") {
    // 可以读取任意文件
    read_file("/etc/passwd");
}

// 能力导向模型：只能使用传入的能力
fn process_file(fs: &FileSystem) {
    // 只能使用传入的 fs 实例
    // 如果 fs 只能访问 /data 目录，就无法读取 /etc/passwd
    let content = fs.read("/data/config.json")?;
}

在组件模型中，一个组件只能使用它显式导入的接口。如果组件没有导入 filesystem 接口，它就完全无法访问文件系统——无论它多么「想」访问。

这种模型带来了几个重要好处：

1. 最小权限原则：组件默认没有任何能力，必须显式授权
2. 易于审计：只需查看组件的导入声明，就知道它能做什么
3. 沙箱友好：组件的能力完全由宿主环境控制，无法「越狱」

三、实战：用 Rust 构建一个组件

3.1 环境准备

首先，安装必要的工具链：

# 安装 Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# 添加 wasm32-wasi 目标
rustup target add wasm32-wasi

# 安装 wasm-tools（用于处理组件）
cargo install wasm-tools

# 安装 wasmtime（WebAssembly 运行时）
cargo install wasmtime-cli

3.2 定义接口

创建一个简单的计算器组件。首先定义 WIT 接口：

// wit/calculator.wit
package my:calculator;

interface types {
  record calculation-result {
    value: f64,
    expression: string,
  }
  
  variant calculation-error {
    division-by-zero,
    invalid-expression(string),
  }
}

interface calculator {
  use types.{calculation-result, calculation-error};
  
  add: func(a: f64, b: f64) -> calculation-result;
  subtract: func(a: f64, b: f64) -> calculation-result;
  multiply: func(a: f64, b: f64) -> calculation-result;
  divide: func(a: f64, b: f64) -> result<calculation-result, calculation-error>;
}

world calculator-world {
  export calculator: calculator;
}

3.3 实现组件

使用 wit-bindgen 生成绑定代码：

cargo install wit-bindgen-cli

在 Cargo.toml 中配置：

[package]
name = "calculator"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
wit-bindgen = "0.30"

[package.metadata.component]
package = "my:calculator"

实现计算器逻辑：

// src/lib.rs
wit_bindgen::generate!({
    world: "calculator-world",
});

use exports::my::calculator::calculator::{Guest, CalculationResult, CalculationError};

struct CalculatorImpl;

impl Guest for CalculatorImpl {
    fn add(a: f64, b: f64) -> CalculationResult {
        CalculationResult {
            value: a + b,
            expression: format!("{} + {} = {}", a, b, a + b),
        }
    }
    
    fn subtract(a: f64, b: f64) -> CalculationResult {
        CalculationResult {
            value: a - b,
            expression: format!("{} - {} = {}", a, b, a - b),
        }
    }
    
    fn multiply(a: f64, b: f64) -> CalculationResult {
        CalculationResult {
            value: a * b,
            expression: format!("{} × {} = {}", a, b, a * b),
        }
    }
    
    fn divide(a: f64, b: f64) -> Result<CalculationResult, CalculationError> {
        if b == 0.0 {
            return Err(CalculationError::DivisionByZero);
        }
        
        let result = a / b;
        Ok(CalculationResult {
            value: result,
            expression: format!("{} ÷ {} = {}", a, b, result),
        })
    }
}

export!(CalculatorImpl);

3.4 编译与运行

编译为 WebAssembly 组件：

# 编译为 wasm
cargo build --target wasm32-wasi --release

# 转换为组件格式
wasm-tools component new ./target/wasm32-wasi/release/calculator.wasm \
  -o calculator.component.wasm \
  --adapt ./wasi_snapshot_preview1.wasm

使用 wasmtime 运行：

# 查看组件导出的接口
wasmtime component inspect calculator.component.wasm

# 运行组件（需要编写宿主代码）
wasmtime component run calculator.component.wasm

3.5 在 JavaScript 中使用

使用 jco 工具生成 JavaScript 绑定：

npm install -g @bytecodealliance/jco

# 生成 JS 绑定
jco transpile calculator.component.wasm -o ./dist

在 JavaScript 中使用：

import { add, subtract, multiply, divide } from './dist/calculator.js';

// 调用组件函数
const result1 = add(10, 20);
console.log(result1);
// { value: 30, expression: "10 + 20 = 30" }

const result2 = multiply(3.5, 2);
console.log(result2);
// { value: 7, expression: "3.5 × 2 = 7" }

const result3 = divide(100, 4);
console.log(result3);
// { value: 25, expression: "100 ÷ 4 = 25" }

const result4 = divide(10, 0);
console.log(result4);
// { tag: "err", val: { tag: "division-by-zero" } }

四、运行时生态：WasmEdge 与 wasmtime

4.1 WasmEdge：边缘计算的王者

WasmEdge（原名 SSVM）是由 CNCF 托管的 WebAssembly 运行时，专门针对边缘计算和云原生场景优化。

核心特性：

1. AOT 编译：将 WebAssembly 预编译为本地机器码，性能接近原生
2. 轻量级：内存占用仅为标准 Linux 容器的 1/10
3. 扩展 API：支持 WASI、TensorFlow、网络请求、存储等扩展
4. OCI 兼容：可以作为 Docker/Kubernetes 的 runtime

# 安装 WasmEdge
curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | bash

# 运行 wasm 模块
wasmedge run module.wasm

# AOT 编译
wasmedgec module.wasm module.wasm.so
wasmedge run module.wasm.so  # 更快的执行速度

在 Kubernetes 中使用：

# 使用 WasmEdge 作为 runtime
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wasm-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: wasm-app
  template:
    metadata:
      labels:
        app: wasm-app
    spec:
      runtimeClassName: wasmedge  # 指定 WasmEdge runtime
      containers:
      - name: wasm-container
        image: my-wasm-image:latest

4.2 wasmtime：Bytecode Alliance 的官方实现

wasmtime 是由 Bytecode Alliance（Mozilla、Intel、Fastly 等组成的联盟）开发的 WebAssembly 运行时。

核心特性：

1. 完整支持组件模型：最早支持组件模型的运行时之一
2. WASI Preview 2：支持最新的系统接口标准
3. 安全沙箱：严格的沙箱隔离，能力导向安全
4. 多语言嵌入：可作为库嵌入 Rust、Go、Python 等语言

// 在 Rust 中嵌入 wasmtime
use wasmtime::*;

fn main() -> Result<()> {
    let engine = Engine::default();
    let module = Module::from_file(&engine, "module.wasm")?;
    
    let mut store = Store::new(&engine, ());
    let instance = Instance::new(&mut store, &module, &[])?;
    
    let func = instance.get_typed_func::<(i32, i32), i32>(&mut store, "add")?;
    let result = func.call(&mut store, (10, 20))?;
    
    println!("Result: {}", result);
    Ok(())
}

4.3 性能对比

WebAssembly 的优势在短生命周期、高密度部署场景中尤为明显：

• Serverless 函数：毫秒级冷启动，完美匹配 FaaS 场景
• 边缘计算：资源受限设备上的高效执行
• 插件系统：安全隔离 + 动态加载

五、组件模型的应用场景

5.1 云原生应用：替代容器的轻量级方案

WebAssembly 正在成为容器技术的有力补充。

为什么需要替代容器？

容器的本质是进程级隔离 + 镜像打包。这带来了：

• 较重的资源开销（每个容器都需要完整的 OS 依赖）
• 较慢的启动速度（需要启动进程、初始化网络等）
• 较大的攻击面（完整的 Linux 系统调用）

WebAssembly 则是字节码级隔离 + 模块打包：

• 极轻的资源开销（仅运行时 + 字节码）
• 毫秒级启动（直接加载字节码执行）
• 极小的攻击面（仅暴露显式导入的能力）

实际案例：Docker + WasmEdge

# 构建 Wasm 镜像
docker build -t my-wasm-app .

# Dockerfile
FROM scratch
COPY app.wasm /
ENTRYPOINT ["app.wasm"]

# 运行 Wasm 容器
docker run --runtime=io.containerd.wasmedge.v1 my-wasm-app

5.2 边缘计算：IoT 设备上的通用运行时

边缘设备通常资源受限：CPU 性能弱、内存小、存储有限。传统容器方案难以部署。

WebAssembly 的优势：

1. 体积小：单个 wasm 文件通常只有几百 KB
2. 跨平台：同一份 wasm 可以在不同架构（ARM、x86、RISC-V）上运行
3. 安全隔离：第三方代码无法破坏宿主系统
4. 热更新：毫秒级部署，无需重启设备

案例：汽车软件

现代汽车有数十个 ECU（电子控制单元），每个运行不同的软件。传统方案：

• 每个软件单独部署，更新困难
• 不同供应商的软件难以集成
• 安全风险：恶意软件可能危及行车安全

WebAssembly 方案：

┌─────────────────────────────────────────────────────────┐
│                    汽车 ECU                              │
│  ┌─────────────────────────────────────────────────┐   │
│  │              WasmEdge Runtime                    │   │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐           │   │
│  │  │引擎控制 │ │刹车系统 │ │娱乐系统 │  ...      │   │
│  │  │Component│ │Component│ │Component│           │   │
│  │  └─────────┘ └─────────┘ └─────────┘           │   │
│  │       安全隔离，独立更新                          │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

5.3 插件系统：安全且高性能的扩展机制

传统插件系统的痛点：

• 安全问题：插件通常以宿主进程的权限运行，可能造成破坏
• 兼容性问题：插件需要与特定版本的宿主程序匹配
• 语言绑定：插件通常只能用宿主语言编写

WebAssembly 插件系统：

// 定义插件接口
interface plugin {
  // 插件元信息
  get-info: func() -> plugin-info;
  
  // 处理数据
  process: func(input: list<u8>) -> result<list<u8>, error>;
  
  record plugin-info {
    name: string,
    version: string,
    author: string,
  }
}

world plugin-world {
  import host-api: host-api;  // 宿主提供的 API
  export plugin: plugin;       // 插件实现的接口
}

宿主程序可以：

1. 安全加载：插件在沙箱中运行，无法访问宿主的文件、网络等
2. 跨语言：插件可以用任何支持 wasm 的语言编写
3. 热更新：动态加载/卸载插件，无需重启

案例：Nginx Unit 的 Wasm 支持

Nginx Unit 在 1.32.0 版本中支持了 WASI-HTTP 组件模型，可以用 WebAssembly 编写 HTTP 处理逻辑：

// 用 Rust 编写 Nginx 处理逻辑
wit_bindgen::generate!({
    world: "wasi-http/proxy",
});

impl exports::wasi::http::incoming_handler::Guest for Handler {
    fn handle(request: IncomingRequest, response_out: ResponseOutparam) {
        // 处理请求
        let path = request.path();
        let method = request.method();
        
        // 生成响应
        let response = OutgoingResponse::new(200);
        response.set_header("content-type", "text/html");
        response.set_body(format!("<h1>Hello from Wasm!</h1><p>Path: {}</p>", path));
        
        ResponseOutparam::set(response_out, Ok(response));
    }
}

5.4 跨语言协作：打破语言壁垒

组件模型最革命性的能力：让不同语言编写的模块无缝协作。

┌─────────────────────────────────────────────────────────┐
│                    应用组件                              │
│  ┌─────────────────────────────────────────────────┐   │
│  │              业务逻辑层                          │   │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐           │   │
│  │  │  Rust   │ │  Python │ │   Go    │           │   │
│  │  │Component│ │Component│ │Component│           │   │
│  │  │ (计算)  │ │ (AI推理)│ │ (并发)  │           │   │
│  │  └─────────┘ └─────────┘ └─────────┘           │   │
│  │         通过 WIT 接口通信                         │   │
│  └─────────────────────────────────────────────────┘   │
│                         │                              │
│                         ▼                              │
│  ┌─────────────────────────────────────────────────┐   │
│  │              基础设施层                          │   │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐           │   │
│  │  │JavaScript│ │   C++   │ │  Zig    │           │   │
│  │  │Component│ │Component│ │Component│           │   │
│  │  │ (UI)    │ │ (图形)  │ │ (系统)  │           │   │
│  │  └─────────┘ └─────────┘ └─────────┘           │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

每种语言发挥自己的优势：

• Rust：高性能计算、系统编程
• Python：AI/ML 推理、数据处理
• Go：并发处理、网络编程
• JavaScript：UI 交互、事件处理
• C/C++：图形渲染、硬件交互

组件模型通过 WIT 定义统一的接口契约，不同语言的实现只需遵循这个契约即可无缝协作。

六、标准化的进展与未来

6.1 WASI Preview 2：组件模型的落地

2023年，WebAssembly 系统接口（WASI）发布了 Preview 2，正式将组件模型纳入标准。

WASI Preview 2 的核心组成：

1. wasi:cli：命令行程序接口（stdin、stdout、stderr、参数、环境变量）
2. wasi:sockets：网络接口（TCP、UDP）
3. wasi:filesystem：文件系统接口
4. wasi:clocks：时间接口
5. wasi:random：随机数接口
6. wasi:http：HTTP 处理接口

这些接口都以 WIT 格式定义，可以组合成「World」：

// 一个 HTTP 服务组件
world http-server {
  // 导入系统能力
  import wasi:clocks/wall-clock;
  import wasi:random/random;
  import wasi:sockets/tcp;
  
  // 导出 HTTP 处理接口
  export wasi:http/incoming-handler;
}

6.2 Preview 3：异步支持

组件模型的下一个里程碑是 Preview 3，主要添加异步支持。

异步对于 I/O 密集型应用至关重要：

// 异步 HTTP 处理
interface async-http {
  // 异步处理请求
  handle-async: func(request: incoming-request) -> future<outgoing-response>;
  
  // 流式读写
  read-stream: func(stream: input-stream) -> stream<list<u8>>;
  write-stream: func(stream: output-stream, data: stream<list<u8>>) -> future<_>;
}

异步支持将使 WebAssembly 能够高效处理：

• 高并发网络服务
• 流式数据处理
• 事件驱动架构

6.3 生态成熟度

截至 2026 年，组件模型生态的关键项目：

七、总结与展望

7.1 组件模型的核心价值

WebAssembly 组件模型解决了 WebAssembly 的「最后一公里」问题：

1. 跨模块通信：通过 WIT 接口类型系统，实现复杂数据的安全传递
2. 跨语言协作：不同语言编写的组件可以无缝组合
3. 标准化接口：WASI 定义了系统级接口的标准契约
4. 能力导向安全：组件只能使用显式导入的能力，最小权限原则

7.2 与容器的关系

组件模型不是要「取代」容器，而是提供一种互补的选择：

7.3 Ending 定律

Ending 定律说：

"一切可编译为 WebAssembly 的，终将被编译为 WebAssembly。"

组件模型的成熟，让这个定律离现实更近了一步。当跨语言、跨模块的协作不再是障碍，WebAssembly 就能真正成为通用的、可移植的、安全的、高效的软件交付格式。

7.4 开发者应该关注什么

如果你是一名开发者，现在应该：

1. 学习 WIT 接口定义：理解组件模型的核心概念
2. 尝试 wasmtime/WasmEdge：在本地环境中运行组件
3. 关注 WASI 进展：了解系统接口的标准化进程
4. 思考应用场景：你的项目中是否有适合 WebAssembly 的场景？

WebAssembly 组件模型不是「银弹」，但在特定场景下，它确实能带来容器无法匹敌的优势。理解它、尝试它、在合适的场景使用它——这就是 2026 年开发者应该做的。

参考资料：

1. WebAssembly Component Model Specification
2. WASI Preview 2 Announcement
3. WasmEdge Documentation
4. wasmtime Documentation
5. Fermyon: WebAssembly Component Model
6. NGINX Unit Wasm Support