Rust/WASM Edge Functions contro Cloudflare e Vercel Edge

Un isolato V8 è un contesto di esecuzione JavaScript leggero all'interno dello stesso motore V8: nessun nuovo processo di sistema, nessun nuovo kernel da avviare. Questo è il meccanismo che Cloudflare ha reso pubblico per la prima volta per Workers e che Vercel riutilizza per il suo Edge Runtime. L'obiettivo è lo stesso da entrambe le parti: evitare il costo di un container o di una VM per ogni richiesta.

Un modulo WebAssembly soddisfa la stessa esigenza attraverso un meccanismo diverso. Il bytecode WASM viene eseguito in una memoria lineare limitata, definita dalla specifica stessa. Il modulo ospite non può indirizzarsi al di fuori di quest'area, indipendentemente dalla lingua sorgente (Rust, C, Go...) che ha prodotto il binario. È questo modello che Wasmtime applica nella modalità wasm di Aurabase, descritta di seguito. Per le misurazioni di avvio tra i due meccanismi, vedere il nostro file sui benchmark di avvio a freddo di WebAssembly.

Ciascuna funzione Aurabase contiene un campo runtime che vale "wasm" o "deno". Il motore di invocazione sceglie di conseguenza il percorso di esecuzione:

// Invio in base al runtime: WASM (wasmtime) o Deno (V8 isola tramite edge-runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Proxy per aura-edge-runtime — V8 Isolates (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

La sandbox si basa su tre meccanismi Wasmtime combinati. Un budget della CPU conteggiato in “carburante”: ogni istruzione WASM lo consuma. Un timeout applicato con incrementi epoch: un thread dedicato aumenta l'orologio Wasmtime dopo il ritardo configurato, che interrompe l'esecuzione corrente. Un limite di memoria impostato tramite StoreLimits. I tre terminali vengono configurati quando viene istanziato il motore:

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

// Memoria limitata da StoreLimits, carburante iniziale = max_fuel,
// timeout = incremento dell'epoca dopo timeout_secs (thread dedicato)

Il modulo compilato viene memorizzato nella cache da code_hash: lo stesso binario distribuito non viene ricompilato ad ogni chiamata. Ogni invocazione crea comunque un'istanza di un nuovo Store e di un'istanza. Nessuna fuga di stato da una chiamata all'altra. La superficie esposta al modulo guest rimane volutamente minima, cinque funzioni host in totale: aura.log, aura.get_input, aura.set_output, aura.get_env e uno stub env.abort per la compatibilità AssemblyScript. Al momento nessuna funzione host espone le chiamate di rete in uscita.

Dal punto di vista della distribuzione, la CLI compila il crate localmente prima dell'invio: aura functions new supporta un crate cdylib, aura functions deploy lo compila e quindi lo invia.

# Scaffolding: crea aurabase/functions/<name>/ (Cargo.toml crate-type = cdylib)
aura functions new my-fn

# cargo build --target wasm32-unknown-unknown --release, quindi carica
# POST /v1/functions/:project_id { runtime: "wasm", codice: <wasm in base64> }
aura functions deploy my-fn

I Cloudflare Workers eseguono in modo nativo JavaScript e TypeScript in isolati V8 distribuiti sulla rete globale di Cloudflare. WebAssembly è un cittadino di prima classe fin dall'inizio della piattaforma: un modulo .wasm può essere importato direttamente in un Worker come qualsiasi altro modulo.

Per scrivere un Worker interamente in Rust, il percorso più utilizzato è l'SDK della community workers-rs, che compila il codice in wasm32-unknown-unknown e lo esegue nel runtime Workers. La differenza con la modalità wasm di Aurabase è la superficie disponibile. Un Worker scritto in Rust tramite questo SDK viene eseguito nell'ambiente Workers completo e può quindi chiamare fetch o altri collegamenti di piattaforma. La modalità wasm di Aurabase inizia da una superficie host deliberatamente ridotta (sezione precedente).

Edge Runtime di Vercel esegue anche codice in isolati V8, con un sottoinsieme di API Web standard (fetch, Request/Response, crypto.subtle…) anziché l'ambiente Node.js completo. I moduli del nodo nativo e le toolchain di compilazione arbitrarie non trovano posto lì.

L'oggetto WebAssembly fa parte di questo sottoinsieme: nulla impedisce di caricare un binario .wasm e istanziarlo manualmente da una funzione JavaScript o TypeScript. Ma per quanto ne sappiamo, Vercel non pubblica alcun SDK o CLI ufficiale per scrivere direttamente una funzione Edge in Rust, a differenza di workers-rs sul lato Cloudflare o aura functions deploy sul lato Aurabase. Il percorso resta possibile, ma interamente manuale, senza strumenti dedicati.

Un isolato V8 separa il codice eseguito da un heap dedicato e dal proprio contesto, all'interno dello stesso processo del motore. Si tratta di un meccanismo collaudato, sulla scala di milioni di richieste al secondo su Cloudflare e Vercel, ma che rimane un meccanismo di isolamento del software all'interno di un singolo motore JavaScript.

Il modello WASM isola in modo diverso: ogni istanza riceve una propria memoria lineare, un buffer contiguo al di fuori del quale non è possibile alcun accesso per costruzione del formato binario stesso, indipendentemente dal motore che lo esegue. Nel runtime Aurabase, ogni funzione host che manipola un puntatore fornito dal modulo guest (aura.log, aura.get_env…) riconvalida esplicitamente i limiti prima di qualsiasi accesso alla memoria. Si tratta di un'ulteriore difesa approfondita contro un modulo dannoso o difettoso.

Specifiche di runtime di Aurabase. Colonne Cloudflare e Vercel descritte dall'architettura pubblica documentata di ciascuna piattaforma (isola V8, WebAssembly come destinazione di compilazione).

Calcolo puro, senza chiamate di rete: convalida dello schema, trasformazione dei dati, punteggio, generazione di immagini leggere. La modalità wasm di Aurabase è adatta direttamente, con una rigorosa sandbox di memoria, un budget CPU esplicito e senza dipendenza da un servizio esterno.

Funzione che chiama un'API di terze parti (pagamento, email, webhook in uscita). La modalità deno di Aurabase rimane oggi la scelta predefinita, allo stesso modo in cui un classico Cloudflare Worker o una funzione Vercel Edge si basa su fetch in modo nativo.

Il team ha già investito nell'ecosistema Cloudflare (KV, Sustainable Objects, R2). Rimanere su Workers ha senso; workers-rs ti permette di introdurre Rust gradualmente, senza cambiare piattaforma.

Serve un runtime Rust nativo gestito end-to-end, con una CLI dedicata e lo stesso linguaggio del resto del backend. Questo è l'angolo che documenta nel nostro confronto Wasmtime vs Wasmer, sulla scelta del motore WebAssembly stesso.