Edge Functions en Rust/WASM face à Cloudflare Workers et Vercel Edge

Un isolate V8 est un contexte d'exécution JavaScript léger à l'intérieur d'un même moteur V8 : pas de nouveau processus système, pas de nouveau noyau à démarrer. C'est le mécanisme que Cloudflare a rendu public le premier pour les Workers, et que Vercel réutilise pour son Edge Runtime. L'objectif est le même des deux côtés : éviter le coût d'un conteneur ou d'une VM à chaque requête.

Un module WebAssembly répond au même besoin par un mécanisme différent. Le bytecode WASM tourne dans une mémoire linéaire bornée, définie par la spécification elle-même. Le module invité ne peut pas adresser en dehors de cette zone, quel que soit le langage source (Rust, C, Go…) qui a produit le binaire. C'est ce modèle que Wasmtime applique dans le mode wasm d'Aurabase, détaillé plus bas. Pour les mesures de démarrage entre les deux mécaniques, voir notre dossier sur les benchmarks de cold start WebAssembly.

Chaque fonction Aurabase porte un champ runtime qui vaut "wasm" ou "deno". Le handler d'invocation choisit le chemin d'exécution en conséquence :

// Dispatch selon le runtime : WASM (wasmtime) ou Deno (V8 Isolates via edge-runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Proxy vers aura-edge-runtime — V8 Isolates (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

Le sandbox s'appuie sur trois mécanismes Wasmtime combinés. Un budget CPU compté en « fuel » : chaque instruction WASM en consomme. Un timeout appliqué par incrément d'epoch : un thread dédié augmente l'horloge Wasmtime après le délai configuré, ce qui interrompt l'exécution en cours. Une limite mémoire posée via StoreLimits. Les trois bornes sont configurées à l'instanciation du moteur :

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);
// Mémoire bornée par StoreLimits, fuel initial = max_fuel,
// timeout = incrément d’epoch après timeout_secs (thread dédié)

Le module compilé est mis en cache par code_hash : un même binaire déployé n'est pas recompilé à chaque appel. Chaque invocation instancie malgré tout un Store et une instance neufs. Aucun état ne fuit d'un appel à l'autre. La surface exposée au module invité reste volontairement minimale, cinq fonctions hôtes au total : aura.log, aura.get_input, aura.set_output, aura.get_env et un stub env.abort pour la compatibilité AssemblyScript. Aucune fonction hôte n'expose d'appel réseau sortant à ce jour.

Côté déploiement, la CLI compile votre crate localement avant l'envoi : aura functions new scaffolde un crate cdylib, aura functions deploy le compile puis l'envoie.

# Scaffolding : crée aurabase/functions/<name>/ (Cargo.toml crate-type = cdylib)
aura functions new my-fn
# cargo build --target wasm32-unknown-unknown --release, puis upload
# POST /v1/functions/:project_id { runtime: "wasm", code: <wasm en base64> }
aura functions deploy my-fn

Cloudflare Workers exécute nativement du JavaScript et du TypeScript dans des isolates V8 répartis sur le réseau mondial de Cloudflare. WebAssembly y est un citoyen de première classe depuis les débuts de la plateforme : un module .wasm peut être importé directement dans un Worker comme n'importe quel autre module.

Pour écrire un Worker entièrement en Rust, la voie la plus utilisée est le SDK communautaire workers-rs, qui compile le code vers wasm32-unknown-unknown et l'exécute dans le runtime Workers. La différence avec le mode wasm d'Aurabase tient à la surface disponible. Un Worker écrit en Rust via ce SDK s'exécute dans l'environnement Workers complet, et peut donc appeler fetch ou d'autres bindings de la plateforme. Le mode wasm d'Aurabase, lui, part d'une surface hôte volontairement réduite (section précédente).

L'Edge Runtime de Vercel exécute aussi le code dans des isolates V8, avec un sous-ensemble d'API Web standard (fetch, Request/Response, crypto.subtle…) plutôt que l'environnement Node.js complet. Les modules natifs Node et les toolchains de compilation arbitraires n'y ont pas leur place.

L'objet WebAssembly fait partie de ce sous-ensemble : rien n'empêche de charger un binaire .wasm et de l'instancier à la main depuis une fonction JavaScript ou TypeScript. Mais à notre connaissance, Vercel ne publie aucun SDK ni CLI officiels pour écrire directement une Edge Function en Rust, contrairement à workers-rs côté Cloudflare ou à aura functions deploy côté Aurabase. Le chemin reste possible, mais entièrement manuel, sans outillage dédié.

Un isolate V8 sépare le code exécuté par un tas (heap) dédié et un contexte propre, à l'intérieur du même processus moteur. C'est un mécanisme éprouvé, à l'échelle de millions de requêtes par seconde chez Cloudflare et Vercel, mais qui reste un mécanisme d'isolation logicielle au sein d'un moteur JavaScript unique.

Le modèle WASM isole différemment : chaque instance obtient sa propre mémoire linéaire, un tampon contigu hors duquel aucun accès n'est possible par construction du format binaire lui-même, indépendamment du moteur qui l'exécute. Dans le runtime Aurabase, chaque fonction hôte qui manipule un pointeur fourni par le module invité (aura.log, aura.get_env…) revalide explicitement les bornes avant tout accès mémoire. C'est une défense en profondeur supplémentaire contre un module malveillant ou buggé.

Colonnes Aurabase vérifiées dans services/aura-functions/src (23 août 2026). Colonnes Cloudflare et Vercel décrites à partir de l'architecture publique documentée de chaque plateforme (isolates V8, WebAssembly comme cible de compilation). Les limites précises de CPU et de mémoire évoluent avec chaque plan tarifaire : elles ne sont pas republiées ici sans mesure datée.

Calcul pur, sans appel réseau : validation de schéma, transformation de données, scoring, génération d'image légère. Le mode wasm d'Aurabase convient directement, avec un sandbox mémoire strict, un budget CPU explicite, et sans dépendance à un service externe.

Fonction qui appelle une API tierce (paiement, email, webhook sortant). Le mode deno d'Aurabase reste le choix par défaut aujourd'hui, de la même façon qu'un Worker Cloudflare classique ou une Edge Function Vercel s'appuient sur fetch nativement.

Équipe déjà investie dans l'écosystème Cloudflare (KV, Durable Objects, R2). Rester sur Workers a du sens ; workers-rs permet d'y introduire du Rust progressivement, sans changer de plateforme.

Besoin d'un runtime Rust natif géré de bout en bout, avec une CLI dédiée et le même langage que le reste du backend. C'est l'angle que documente notre comparatif Wasmtime vs Wasmer, sur le choix du moteur WebAssembly lui-même.