Plugin Systems and Extensibility

37.1 Why Wasm for Plugins?

Safe: plugins can't crash the host (traps are contained) or access unauthorized resources.

Polyglot: plugin authors choose their language. Portable: one artifact for every OS/CPU. Resource-limited: fuel, memory caps, timeouts.

37.2 Real-World Examples

Envoy/Istio (proxy-wasm filters), Zellij (terminal multiplexer plugins), Lapce/Zed (editor extensions, Zed uses the Component Model), Figma plugins (QuickJS in Wasm sandbox), Microsoft Flight Simulator add-ons, SingleStore/ScyllaDB/libSQL (UDFs in Wasm), Redpanda Data Transforms, Open Policy Agent (Rego → Wasm), Extism-based apps, Shopify Functions, Minecraft mods (experimental), VS Code extensions (Wasm component support), Kubernetes admission controllers (Kubewarden).

37.3 Extism (Universal Plugin Framework)

// Plugin (Rust PDK)
use extism_pdk::*;

#[plugin_fn]
pub fn greet(name: String) -> FnResult<String> {
    Ok(format!("Hello, {name}!"))
}

# Host (Python SDK); SDKs exist for Go, JS, Rust, Java, .NET, Ruby, PHP, Elixir...
import extism
with extism.Plugin(open("plugin.wasm", "rb").read(), wasi=True) as plugin:
    print(plugin.call("greet", b"Ana").decode())

37.4 Designing a Plugin API

Define the API in WIT (the Component Model) or as a stable core-Wasm ABI. Version it. Give plugins minimal capabilities. Limit memory and CPU. Provide host functions for logging, config, and state. Validate inputs from plugins. Cache compiled modules. Offer PDKs for popular languages.