Wasmtime vs Wasmer per la produzione Edge Functions

WebAssembly designa da tempo un formato runtime per il browser. Da diversi anni viene utilizzato anche per eseguire codice sandbox lato server o all'edge: un bytecode compilato una sola volta, portabile su qualsiasi macchina host, isolato per impostazione predefinita senza contenitore o macchina virtuale completa. Wasmtime e Wasmer portano questa estensione fuori dal browser, entrambi scritti in Rust, entrambi in grado di eseguire lo stesso file .wasm.

Wasmtime è un progetto ospitato da Bytecode Alliance, l'organizzazione che gestisce diversi componenti dell'ecosistema di server WebAssembly, incluso il compilatore Cranelift. Wasmer è sviluppato da Wasmer Inc., una società che pubblica il runtime come open source e commercializza servizi complementari attorno ad esso (edge ​​deployment, tooling). Due modelli di governance diversi, nessun giudizio sulla qualità del codice prodotto dall'uno o dall'altro.

Il resto di questo articolo confronta quattro campi verificabili, licenza e governance, compilatori disponibili, standard WASI e modello di componenti, modello di sicurezza, quindi spiega, con codice di supporto, perché Il core Rust di Aurabase esegue Wasmtime nel suo motore Edge Functions.

Wasmtime è rilasciato sotto la licenza Apache-2.0 con eccezione LLVM, una licenza permissiva comune nell'ecosistema del compilatore. La sua governance segue il modello Bytecode Alliance: diverse organizzazioni contribuiscono al progetto, nessuna ne è proprietaria da sola.

Wasmer è pubblicato sotto la licenza MIT, ancora più permissiva sulla carta, ma la sua direzione tecnica resta concentrata presso un unico editore, Wasmer Inc. Questo non è di per sé un difetto: molti progetti open source di successo seguono questo modello. Si tratta semplicemente di un profilo di rischio diverso se la tua organizzazione valorizza la governance distribuita su più entità.

Wasmtime compila in produzione tramite Cranelift, un generatore di codice anch'esso della Bytecode Alliance. La confezione documenta anche un compilatore aggiuntivo, Winch, progettato per ridurre i tempi di compilazione rispetto a Cranelift nei casi sensibili all'avvio. Il Cargo.toml diaura-functions attiva solo la funzionalità cranelift: è questo compilatore, e solo lui, che elabora ogni modulo WASM caricato in produzione.

Wasmer prende la strada opposta: tre backend intercambiabili. Singlepass viene compilato in un unico passaggio, quasi istantaneamente, al costo di un codice macchina meno ottimizzato. Cranelift offre un compromesso equilibrato. LLVM mira al miglior throughput di esecuzione possibile, con il tempo di compilazione più lungo dei tre. Un unico runtime, tre profili di compromesso scelti in fase di configurazione.

WASI, WebAssembly System Interface, standardizza l'accesso ai file, agli orologi e alla rete da un modulo WASM, senza dipendere dal browser. La sua versione più recente, WASI Preview 2, si basa sul Component Model: un meccanismo per comporre moduli scritti in diversi linguaggi, con interfacce tipizzate condivise anziché un formato binario specifico per ciascun runtime. Sia Wasmtime che Wasmer stanno lavorando per implementare questo standard, ciascuno secondo i propri ritmi.

Wasmer documenta inoltre WASIX, un'estensione che mira a coprire le primitive POSIX che lo standard WASI ufficiale non copre ancora, come thread o socket di rete più completi. Questo non è uno standard supportato dal gruppo di lavoro WebAssembly, ma un'estensione specifica dell'ecosistema Wasmer.

Entrambi i runtime isolano ciascun modulo nella propria memoria lineare, senza accesso diretto al sistema host al di fuori delle funzioni importate esplicitamente. Questa è la base del modello di sicurezza WebAssembly, comune ad entrambi i progetti.

Wasmtime espone anche un'API di metraggio di esecuzione nativa, fuel: ogni istruzione consuma un budget fissato in anticipo e l'esecuzione si interrompe correttamente una volta esaurito questo budget. Una seconda API, l'interruzione epoch, consente di imporre un timeout senza bloccare il motore durante l'attesa. Wasmer documenta i propri meccanismi di misurazione e i limiti di memoria per istanza; Questo articolo non li ha verificati in un repository di terze parti, quindi non li suddivide figura per cifra.

Questo è esattamente ciò che consente il servizio aura-functions di Aurabase, descritto in dettaglio nella sezione successiva con il codice sorgente effettivo.

Il servizio aura-functions dichiara wasmtime come dipendenza di produzione, senza commenti di disattivazione o configurazione della dipendenza dev. Nessun file nel repository, né Cargo.toml né .rs, menziona Wasmer.

# Tempo di esecuzione WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Il codice di inizializzazione attiva esplicitamente il carburante e l'interruzione per epoca, quindi limita la memoria tramite invocazione con StoreLimits:

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);
let engine = Engine::new(&cfg)?;

// per invocazione:
let limits = StoreLimitsBuilder::new()
    .memory_size(self.max_memory_mb as usize * 1024 * 1024)
    .build();
store.set_fuel(self.max_fuel)?;
store.epoch_deadline_async_yield_and_update(1);

Tutti e tre i limiti sono configurabili per variabile di ambiente, con valori predefiniti controllati in config/mod.rs: WASM_MAX_MEMORY_MB a 64, WASM_TIMEOUT_SECS a 10, WASM_MAX_FUEL a un miliardo di unità. Il timeout viene attivato in background: un tokio::spawn attende la durata configurata quindi incrementa l'epoca del motore, senza bloccare l'esecuzione corrente durante l'attesa.

L'ABI esposto ai moduli guest rimane intenzionalmente minimo: quattro funzioni host, aura.log, aura.get_input, aura.set_output e aura.get_env, registrate tramite linker.func_wrap. Non è il Component Model, né WASI Preview 2: è un contratto interno, più ristretto, progettato per un singolo utilizzo, che esegue una funzione edge HTTP e recupera la sua risposta JSON.

Questa modalità wasm è una scelta per funzione, non un interruttore globale. La panoramica dell'architettura Aurabase descrive in dettaglio l'altro percorso, la modalità denopredefinita, che esegue JavaScript/TypeScript in un servizio separato. Entrambi coesistono nello stesso servizio aura-functions.

Fonti: Cargo.toml e wasm/mod.rs dal repository Aurabase, verificate direttamente il 24 agosto 2026. Caratteristiche generali Wasmtime e Wasmer tratte dalla documentazione pubblica di ciascun progetto; nessun dato di benchmark di terze parti viene ripubblicato in questa tabella.

Si avvia un nuovo edge runtime, senza dipendenze esistenti. Wasmtime, supportato da una fondazione multi-vendor, riduce il rischio di dipendere da un unico editore per il futuro del progetto.

Hai avviamenti a freddo molto frequenti e di breve durata. Il backend Singlepass di Wasmer risponde direttamente a questa esigenza, compilazione quasi istantanea, al costo di un codice macchina meno ottimizzato.

Sono necessarie primitive POSIX oltre l'attuale standard WASI. WASIX, l'estensione Wasmer, copre thread e socket estesi che WASI Preview 2 da solo non copre ancora.

Desideri un'API nativa per filmati e timeout, senza middleware di terze parti. Wasmtime espone fuel e epoch direttamente nel crate, esattamente ciò che aura-functions consente ad Aurabase.