Rust/WASM Edge Functions vs. Cloudflare und Vercel Edge

Ein V8-Isolat ist ein leichter JavaScript-Ausführungskontext innerhalb derselben V8-Engine: keine neuen Systemprozesse, kein neuer Kernel zum Starten. Dies ist der Mechanismus, den Cloudflare erstmals für Worker veröffentlicht hat und den Vercel für seine Edge Runtime wiederverwendet. Das Ziel ist auf beiden Seiten dasselbe: die Kosten für einen Container oder eine VM für jede Anfrage zu vermeiden.

Ein WebAssembly-Modul erfüllt denselben Bedarf durch einen anderen Mechanismus. Der WASM-Bytecode läuft in einem begrenzten linearen Speicher, der durch die Spezifikation selbst definiert wird. Das Gastmodul kann keine Adressen außerhalb dieses Bereichs ansprechen, unabhängig von der Quellsprache (Rust, C, Go…), die die Binärdatei erstellt hat. Es ist dieses Modell, das Wasmtime im wasm-Modus von Aurabase anwendet, wie unten beschrieben. Informationen zu Startmessungen zwischen den beiden Mechaniken finden Sie in unserer Datei zu WebAssembly-Kaltstart-Benchmarks.

Jede Aurabase-Funktion trägt ein runtime-Feld, das einen Wert von "wasm" oder "deno"hat. Die Aufruf-Engine wählt den Ausführungspfad entsprechend aus:

// Versand nach Laufzeit: WASM (wasmtime) oder Deno (V8 isoliert über Edge-Runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Proxy für Aura-Edge-Runtime – V8-Isolate (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

Die Sandbox basiert auf drei kombinierten Wasmtime-Mechanismen. Ein CPU-Budget, das als „Kraftstoff“ gezählt wird: Jeder WASM-Befehl verbraucht es. Ein in Epochenschritten angewendetes Timeout: Ein dedizierter Thread erhöht die Wasmtime-Uhr nach der konfigurierten Verzögerung, wodurch die aktuelle Ausführung unterbrochen wird. Ein über StoreLimitsfestgelegtes Speicherlimit. Die drei Terminals werden konfiguriert, wenn die Engine instanziiert wird:

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);

// Speicher begrenzt durch StoreLimits, anfänglicher Kraftstoff = max_fuel,
// timeout = Epocheninkrement nach timeout_secs (dedizierter Thread)

Das kompilierte Modul wird von code_hashzwischengespeichert: Die gleiche bereitgestellte Binärdatei wird nicht bei jedem Aufruf neu kompiliert. Jeder Aufruf instanziiert dennoch ein neues Store und eine neue Instanz. Es gibt keine Statuslecks von einem Anruf zum nächsten. Die dem Gastmodul ausgesetzte Oberfläche bleibt bewusst minimal, insgesamt fünf Hostfunktionen: aura.log, aura.get_input, aura.set_output, aura.get_env und ein Stub env.abort für AssemblyScript-Kompatibilität. Derzeit stellen keine Hostfunktionen ausgehende Netzwerkaufrufe zur Verfügung.

Auf der Bereitstellungsseite kompiliert die CLI Ihre Kiste lokal, bevor sie Folgendes sendet: aura functions new erstellt ein Gerüst für eine Kiste cdylib, aura functions deploy kompiliert sie und sendet sie dann.

# Gerüst: erstellt aurabase/functions/<name>/ (Cargo.toml crate-type = cdylib)
aura functions new my-fn

# cargo build --target wasm32-unknown-unknown --release, dann hochladen
# POST /v1/functions/:project_id { Laufzeit: „wasm“, Code: <wasm in base64> }
aura functions deploy my-fn

Cloudflare-Worker führen JavaScript und TypeScript nativ in V8-Isolaten aus, die über das globale Netzwerk von Cloudflare verteilt sind. WebAssembly ist seit Beginn der Plattform ein erstklassiger Bürger: Ein .wasm-Modul kann wie jedes andere Modul direkt in einen Worker importiert werden.

Um einen Worker vollständig in Rust zu schreiben, wird am häufigsten das Community-SDK workers-rsverwendet, das den Code zu wasm32-unknown-unknown kompiliert und in der Workers-Laufzeit ausführt. Der Unterschied zum wasm-Modus von Aurabase ist die verfügbare Oberfläche. Ein über dieses SDK in Rust geschriebener Worker läuft in der vollständigen Workers-Umgebung und kann daher fetch oder andere Plattformbindungen aufrufen. Der wasm-Modus von Aurabase beginnt mit einer bewusst reduzierten Hostoberfläche (vorheriger Abschnitt).

Die Edge Runtime von Vercel führt auch Code in V8-Isolaten aus, mit einer Teilmenge der Standard-Web-APIs (fetch, Request/Response, crypto.subtle…) anstelle der vollständigen Node.js-Umgebung. Native Node-Module und beliebige Kompilierungs-Toolchains haben dort keinen Platz.

Das WebAssembly-Objekt ist Teil dieser Teilmenge: Nichts hindert Sie daran, eine .wasm-Binärdatei zu laden und sie manuell aus einer JavaScript- oder TypeScript-Funktion zu instanziieren. Aber unseres Wissens veröffentlicht Vercel kein offizielles SDK oder CLI, um eine Edge-Funktion direkt in Rust zu schreiben, im Gegensatz zu workers-rs auf der Cloudflare-Seite oder aura functions deploy auf der Aurabase-Seite. Der Weg bleibt möglich, aber vollständig manuell und ohne spezielle Tools.

Ein V8-Isolat trennt den von einem dedizierten Heap ausgeführten Code und seinen eigenen Kontext innerhalb desselben Engine-Prozesses. Es handelt sich um einen bewährten Mechanismus mit einer Größenordnung von Millionen von Anfragen pro Sekunde bei Cloudflare und Vercel, der jedoch weiterhin ein Software-Isolationsmechanismus innerhalb einer einzelnen JavaScript-Engine bleibt.

Das WASM-Modell isoliert anders: Jede Instanz erhält ihren eigenen linearen Speicher, einen zusammenhängenden Puffer, außerhalb dessen durch die Konstruktion des Binärformats selbst kein Zugriff möglich ist, unabhängig von der Engine, die ihn ausführt. In der Aurabase-Laufzeit validiert jede Hostfunktion, die einen vom Gastmodul bereitgestellten Zeiger (aura.log, aura.get_env…) manipuliert, die Grenzen vor jedem Speicherzugriff explizit erneut. Dies ist eine zusätzliche Tiefenverteidigung gegen ein bösartiges oder fehlerhaftes Modul.

Aurabase-Laufzeitspezifikationen. Beschriebene Cloudflare- und Vercel-Spalten aus der dokumentierten öffentlichen Architektur jeder Plattform (isoliert V8, WebAssembly als Build-Ziel).

Reine Berechnung, ohne Netzwerkaufrufe: Schemavalidierung, Datentransformation, Bewertung, einfache Bildgenerierung. Der wasm-Modus von Aurabase ist direkt geeignet, mit einer strikten Speicher-Sandbox, einem expliziten CPU-Budget und ohne Abhängigkeit von einem externen Dienst.

Funktion, die eine Drittanbieter-API aufruft (Zahlung, E-Mail, ausgehender Webhook). Der deno-Modus von Aurabase ist auch heute noch die Standardauswahl, genauso wie ein klassischer Cloudflare Worker oder eine Vercel Edge Function nativ auf fetch angewiesen ist.

Das Team hat bereits in das Cloudflare-Ökosystem (KV, Langlebige Objekte, R2) investiert. Es macht Sinn, bei den Arbeitern zu bleiben; Mit workers-rs können Sie Rust schrittweise einführen, ohne die Plattform zu wechseln.

Benötigen Sie eine native Rust-Laufzeit, die durchgängig verwaltet wird, mit einer dedizierten CLI und derselben Sprache wie der Rest des Backends. Dies ist der Blickwinkel, den in unserem Wasmtime vs. Wasmer-Vergleichauf die Wahl der WebAssembly-Engine selbst dokumentiert.