Begriff
WIT (Wasm Interface Type)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Wenn zwei Programme miteinander reden wollen, brauchen sie eine gemeinsame Sprache.
Bei REST APIs ist das OpenAPI (Swagger).
Bei gRPC ist das Protobuf (.proto).
Beim Wasm Component Model ist das WIT (.wit).
Es ist eine einfache Textdatei, die beschreibt:
"Ich biete eine Funktion add(a: u32, b: u32) -> u32 an."
Oder komplexer: "Ich brauche einen Key-Value Store."
WIT ist sprachunabhängig.
Du schreibst dein WIT, und Tools generieren daraus automatisch den Glue-Code für Rust, Python, Go oder JavaScript.
Merksatz: Eine Interface Definition Language (IDL) für das WebAssembly Component Model, die abstrakt beschreibt, welche Funktionen und Datentypen ein Wasm-Modul exportiert oder importiert.
Beispiel calculator.wit:
interface calculator {
add: func(a: u32, b: u32) -> u32;
}
Dann: wit-bindgen rust calculator.wit.
Das generiert Rust-Code, den du nur noch ausfüllen musst.
Kein manuelles Parsen von Bytes mehr!
1. Resources
WIT unterstützt "Resources" (Handles).
Das ist wichtig für objektorientierte APIs.
resource file { read: func() -> string; }.
Der Host gibt dem Wasm einen Handle auf die Datei. Das Wasm kann nur diesen Handle nutzen, aber nicht direkt auf die Datei zugreifen (Capability-based Security).
2. Semver
WIT-Pakete können versioniert werden (wasi:[email protected]).
Das ermöglicht stabile Interfaces und Upgrades, ähnlich wie npm packages.
1. Canonical ABI & Memory Management
Wenn ein Wasm-Modul (Gast) einen String an ein anderes (Host/Gast) übergibt, gibt es ein Problem: Die Sprachen haben unterschiedliche Speicherlayouts.
WIT nutzt die Canonical ABI (Application Binary Interface).
Hierbei wird festgelegt, wie Pointer, Längen-Angaben und komplexe Typen im linearen Wasm-Speicher abgelegt werden. Der Standard definiert sogar, wer den Speicher wieder freigibt (cabi_realloc / cabi_free).
Das klingt nach kleinlichem Detail, ermöglicht aber erst die "Sprach-Agnostik": Ein Rust-Modul kann einen Python-String empfangen, ohne dass beide Sprachen voneinander wissen müssen.
2. World Files
Ein WIT-File enthält oft ein world-Statement.
Das ist wie eine "Bauanleitung" für eine ganze Komponente.
world my-service { import wasi:logging; export run; }.
Es definiert die komplette Umgebung, in der das Wasm leben wird. Man kann so Profile erstellen: Eine "Cloud-World" hat Zugriff auf HTTP und Datenbanken, eine "Embedded-World" vielleicht nur auf Sensoren.
Tools wie wasm-tools compose können dann verschiedene Komponenten anhand ihrer Worlds zusammenstecken, fast wie LEGO-Steine.
3. Die Entwicklung von WASI (WebAssembly System Interface)
WIT ist das offizielle Werkzeug, mit dem der neue WASI Preview 2 Standard geschrieben wurde.
Anstatt (wie in Preview 1) starre System-Calls wie in Linux (fd_read, fd_write) zu nutzen, definiert WASI jetzt alles über WIT-Interfaces.
Das erlaubt eine fein-granulare Rechtevergabe (Component-based security). Ein Wasm-Modul kann das Interface wasi:http haben, aber kein wasi:filesystem. Man kann ihm also das Recht geben, ins Internet zu funken, aber verbieten, Dateien zu lesen – und das wird zur Kompilierzeit/Instanziierung garantiert.
Quick-Check
Wie Header-Files?
Ja, wie.hin C, aber viel mächtiger, weil es binär-inkompatible Sprachen (Python und Rust) verbindet.Performance?
WIT-Aufrufe sind extrem schnell (Nanosekunden), weil sie im gleichen Prozessraum stattfinden. Viel schneller als Netzwerk-Aufrufe (gRPC).Standard?
Wird von der Bytecode Alliance (Mozilla, Fastly, Microsoft) entwickelt. Ist Teil des W3C-Standardisierungsprozesses.