WebAssembly geht über den Browser hinaus: Die Zukunft von Server- und Edge-Anwendungen

Als WebAssembly (Wasm) 2017 zum ersten Mal auf den Markt kam, schien seine Mission klar zu sein: Webentwickler*innen die Möglichkeit zu geben, leistungsstarken Code in einem Browser auszuführen. Aber heute, einige Jahre später, sehen wir etwas Unerwartetes: WebAssembly verlässt schnell seinen ursprünglichen Lebensraum und erobert Server, Edge-Geräte und sogar eingebettete Systeme. Was ist los?

Ein Problem, das niemand zu lösen erwartete.

Stellen Sie sich die typische Architektur einer modernen Cloud-Anwendung vor. Sie haben Microservices in verschiedenen Sprachen: Go, Node.js, Python, Rust. Jeder von ihnen benötigt eine eigene Laufzeitumgebung, eine Reihe von Abhängigkeiten und eine spezifische Konfiguration. Die Bereitstellung wird zu einer Herausforderung und die Sicherheit zu einem ständigen Kopfzerbrechen.

Stellen Sie sich nun vor, Sie könnten jeden dieser Dienste in ein einziges, universelles Format kompilieren, das überall mit vorhersehbarer Leistung und eisernen Sicherheitsgarantien funktioniert. Genau das verspricht WebAssembly außerhalb des Browsers.

WASI: Brücke in die reale Welt

Ein Schlüsselmoment in der Entwicklung von WebAssembly war die Einführung von WASI (WebAssembly System Interface), einer standardisierten API für die Interaktion mit dem Betriebssystem. Wenn Wasm der Prozessor ist, dann ist WASI sein Betriebssystem.

// Einfacher HTTP-Server in Rust, kompiliert in Wasm
use wasi::http;

#[no_mangle]
pub extern "C" fn handle_request() -> i32 {
    let request = http::incoming_request();
    let response = http::outgoing_response();
    
    response.set_status_code(200);
    response.body().write(b"Hello from WebAssembly!");
    
    0
}

WASI löst ein kritisches Problem: Wie kann man Wasm-Modulen Zugriff auf das Dateisystem, Netzwerk und andere Systemressourcen gewähren und gleichzeitig das Capability-Based-Sicherheitsmodell beibehalten? Das Modul greift nur auf das zu, was ausdrücklich erlaubt ist, und auf nichts anderes.

Leistung, die überrascht

Einer der Hauptvorteile von WebAssembly auf dem Server ist die Startgeschwindigkeit. Herkömmliche Container können Sekunden starten, der Kaltstart von Lambda-Funktionen wird in Hunderten von Millisekunden gemessen. Wasm-Modul? Mikrosekunden.

Das sind nicht nur schöne Zahlen. Dies ist eine grundlegende Veränderung in der Art und Weise, wie wir über Skalierung denken:

Docker-Container:

• Kaltstartzeit: 1-3 Sekunden

• Volumen: 50-500 MB

• Isolierung: durch Namespace und cgroups

WebAssembly-Modul:

• Kaltstartzeit: <1 ms

• Größe: 1-10 MB

• Isolierung: in die Laufzeit integriert

Fastly berichtet, dass seine auf Wasm basierende Compute@Edge-Plattform Instanzen in 35 Mikrosekunden ausführt. Cloudflare Workers erzielen ähnliche Ergebnisse. Dies eröffnet völlig neue Nutzungsmuster.

Edge Computing: Eine neue Heimat für Wasm

Edge Computing ist der Bereich, in dem WebAssembly wirklich glänzt. Stellen Sie sich einen CDN-Knoten vor, der nicht nur statische Inhalte ausgibt, sondern Ihre Geschäftslogik so nah wie möglich am Benutzer ausführt.

// Cloudflare Worker auf AssemblyScript (kompiliert in Wasm)
export function handleRequest(request: Request): Response {
  const url = new URL(request.url);
  
  // Personalisierung von Inhalten auf Edge
  const country = request.headers.get("CF-IPCountry");
  const content = getLocalizedContent(country);
  
  // A/B-Test
  const variant = Math.random() > 0.5 ? "A" : "B";
  
  return new Response(content, {
    headers: {
      "X-Variant": variant,
      "Cache-Control": "public, max-age=60"
    }
  });
}

Dank des sofortigen Starts und des minimalen Overheads ermöglicht Wasm die Ausführung von Code an Tausenden von Standorten auf der ganzen Welt, ohne dass verrückte Infrastrukturkosten anfallen.

Plugins und Erweiterbarkeit.

Eine der aufregendsten Anwendungen von WebAssembly außerhalb des Browsers sind Plugin-Systeme. Die App muss den Nutzern die Möglichkeit geben, die Funktionalität zu erweitern, aber wie kann man das sicher tun?

Herkömmliche Ansätze erforderten entweder die Ausführung von nicht vertrauenswürdigem Code in einzelnen Prozessen (langsam) oder die Verwendung von eingebetteten Interpretern (eingeschränkt). Wasm bietet einen goldenen Mittelweg:

// Die Host-Anwendung auf Go lädt das benutzerdefinierte Plugin
package main

import (
    "github.com/tetratelabs/wazero"
)

func main() {
    ctx := context.Background()
    runtime := wazero.NewRuntime(ctx)
    defer runtime.Close(ctx)
    
    // Plugin vom Benutzer wird geladen
    plugin, _ := os.ReadFile("user_plugin.wasm")
    mod, _ := runtime.InstantiateModuleFromBinary(ctx, plugin)
    
    // Wir rufen die Funktion mit Ressourcenbeschränkungen auf
    result, _ := mod.ExportedFunction("process_data").
        Call(ctx, data)
}

Dieser Ansatz wird verwendet:

• Envoy - für benutzerdefinierte Traffic-Filter

• Shopify — für benutzerdefinierte Skripte in Shops

• Figma — für Plugins (ja, sowohl auf der Front- als auch auf der Backend-Seite)

Echte Fälle, die beeindrucken

Disney+: verwendet Wasm für die serverseitige Bild- und Videoverarbeitung. Eine Laufzeit – viele Verarbeitungsformate.

Shopify: führt täglich Millionen von benutzerdefinierten Skripten in Wasm aus und verarbeitet die Checkout-Logik für Tausende von Shops.

Cosmonic: Wir haben die gesamte Plattform auf wasmCloud aufgebaut, wo Anwendungen im laufenden Betrieb zwischen Clouds und Edge-Standorten migrieren können.

SingleStore: Wir haben Wasm hinzugefügt, um benutzerdefinierte Funktionen direkt in der Datenbank auszuführen — sicher und schnell.

Herausforderungen und Einschränkungen.

Es ist nicht alles Gold, was glänzt. Server WebAssembly hat seine eigenen Probleme:

Es gibt noch keinen Konsens über WASI. Die Spezifikation entwickelt sich aktiv weiter, verschiedene Laufzeiten unterstützen verschiedene Versionen. WASI Preview 2 verspricht Stabilität, ist aber noch nicht weit verbreitet.

Das Debuggen ist komplizierter. Tools zum Debuggen von Wasm-Code auf dem Server befinden sich noch in der Entwicklung. Es gibt keine üblichen strace, gdb oder Debugger von der Stange.

Bibliotheksökosystem. Viele beliebte Bibliotheken unterstützen noch keine Wasm-Kompilierung oder benötigen Patches.

Produktivität ist nicht immer besser. Bei CPU-intensiven Aufgaben kann Wasm 10-50% langsamer sein als nativer Code. Ein schneller Start macht das nicht immer wett.

Jetzt ist die Zeit zum Experimentieren. Probieren Sie Wasmtime aus, spielen Sie mit Spin, schreiben Sie Ihr erstes Server-Wasm-Modul. Die Zukunft ist schon da, sie ist nur ungleich verteilt.

Kodik – ist nicht nur eine App, sondern dein persönlicher Mentor in der Welt der Programmierung. Er erklärt alles in einfachen Worten, hilft, das Wissen in der Praxis zu festigen und gibt coole Erfolge für Erfolge 🏅

Und wir haben auch warme und freundliche Community im Telegram, wo jeder eine Frage stellen und eine Antwort erhalten kann - ohne Urteil und unnötige Theorie. Gemeinsam lösen wir Probleme, analysieren Fehler und unterstützen uns gegenseitig auf dem Weg zum Ziel.