Wasmtime versus Wasmer voor productie Edge Functions

WebAssembly heeft al lang een runtime-formaat voor de browser aangewezen. Sinds enkele jaren wordt het ook gebruikt om code in een sandbox uit te voeren op de server of aan de rand: een bytecode die één keer is gecompileerd, draagbaar op elke hostmachine, standaard geïsoleerd zonder een container of een volledige virtuele machine. Wasmtime en Wasmer halen deze extensie uit de browser, beide geschreven in Rust, beide in staat hetzelfde .wasm-bestand uit te voeren.

Wasmtime is een project dat wordt gehost door de Bytecode Alliance, de organisatie die verschillende componenten van het WebAssembly-serverecosysteem beheert, waaronder de Cranelift-compiler. Wasmer is ontwikkeld door Wasmer Inc., een bedrijf dat de runtime als open source publiceert en er aanvullende diensten omheen op de markt brengt (edge-implementatie, tooling). Twee verschillende bestuursmodellen, geen oordeel over de kwaliteit van de code die door de een of de ander wordt geproduceerd.

De rest van dit artikel vergelijkt vier verifieerbare velden, licenties en governance, beschikbare compilers, WASI-standaard en Component Model, beveiligingsmodel, en legt vervolgens, met ondersteunende code, uit waarom Aurabase's Rust-kern Wasmtime draait in zijn Edge Functions-engine.

Wasmtime wordt vrijgegeven onder de Apache-2.0-licentie met LLVM-uitzondering, een tolerante licentie die gebruikelijk is in het compiler-ecosysteem. Het bestuur ervan volgt het Bytecode Alliance-model: verschillende organisaties dragen bij aan het project, geen enkele is eigenaar van het project.

Wasmer wordt gepubliceerd onder de MIT-licentie, wat op papier nog toleranter is, maar de technische leiding blijft geconcentreerd bij één enkele uitgever, Wasmer Inc. Dit is op zichzelf geen fout: veel succesvolle open source-projecten volgen dit model. Het is simpelweg een ander risicoprofiel als uw organisatie gedistribueerd bestuur over meerdere entiteiten waardeert.

Wasmtime compileert in productie via Cranelift, een codegenerator ook van de Bytecode Alliance. De kist documenteert ook een extra compiler, Winch, ontworpen om de compilatietijd te verkorten in vergelijking met Cranelift in gevallen die gevoelig zijn voor opstarten. De Cargo.toml vanaura-functies activeert alleen de cranelift-functie: het is deze compiler, en alleen deze, die elke WASM-module verwerkt die in productie is geladen.

Wasmer volgt het tegenovergestelde pad: drie verwisselbare backends. Singlepass compileert vrijwel onmiddellijk in één keer, ten koste van minder geoptimaliseerde machinecode. Cranelift biedt een uitgebalanceerd compromis. LLVM streeft naar de best mogelijke uitvoeringsdoorvoer, met de langste compilatietijd van de drie. Eén runtime, drie compromisprofielen gekozen tijdens de configuratie.

WASI, de WebAssembly System Interface, standaardiseert de toegang tot bestanden, klokken en het netwerk vanuit een WASM-module, zonder afhankelijk te zijn van de browser. De meest recente versie, WASI Preview 2, is gebaseerd op het Component Model: een mechanisme voor het samenstellen van modules die in verschillende talen zijn geschreven, met gedeelde getypte interfaces in plaats van een binair formaat dat specifiek is voor elke runtime. Zowel Wasmtime als Wasmer werken aan de implementatie van deze standaard, elk in hun eigen tempo.

Wasmer documenteert bovendien WASIX, een extensie die POSIX-primitieven wil dekken die de officiële WASI-standaard nog niet dekt, zoals threads of uitgebreidere netwerkaansluitingen. Dit is geen standaard die wordt ondersteund door de WebAssembly-werkgroep, maar een uitbreiding specifiek voor het Wasmer-ecosysteem.

Beide runtimes isoleren elke module in zijn eigen lineaire geheugen, zonder directe toegang tot het hostsysteem buiten expliciet geïmporteerde functies. Dit is de basis van het WebAssembly-beveiligingsmodel, dat beide projecten gemeen hebben.

Wasmtime stelt ook een native API voor uitvoeringsbeelden beschikbaar, fuel: elke instructie verbruikt een vooraf vastgesteld budget, en de uitvoering stopt correct zodra dit budget is opgebruikt. Met een tweede API, de epoch-onderbreking, kunt u een time-out opleggen zonder de engine tijdens het wachten te blokkeren. Wasmer documenteert zijn eigen mechanismen van meting en geheugenlimieten per exemplaar; Dit artikel heeft ze niet geverifieerd in een repository van derden en deelt ze dus niet figuur voor figuur uit.

Dit is precies wat de aura-functions-service van Aurabase mogelijk maakt, gedetailleerd in de volgende sectie met de daadwerkelijke broncode.

De service aura-functions declareert wasmtime als een productieafhankelijkheid, zonder deactiveringsopmerkingen of configuratie van de dev-afhankelijkheid. Geen enkel bestand in de repository, noch Cargo.toml, noch .rs, vermeldt Wasmer.

# WASM-runtime
wasmtime = { version = "43", features = ["async", "cranelift"] }

De initialisatiecode activeert expliciet brandstof en interrupt per tijdperk, en begrenst vervolgens het geheugen door aanroep met StoreLimits:

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

// door aanroeping:
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);

Alle drie de limieten zijn configureerbaar per omgevingsvariabele, waarbij de standaardwaarden zijn aangevinkt in config/mod.rs: WASM_MAX_MEMORY_MB op 64, WASM_TIMEOUT_SECS op 10, WASM_MAX_FUEL op één miljard eenheden. De time-out wordt op de achtergrond geactiveerd: een tokio::spawn wacht de geconfigureerde duur en verhoogt vervolgens het engine-tijdperk, zonder de huidige uitvoering tijdens het wachten te blokkeren.

De ABI die wordt blootgesteld aan gastmodules blijft opzettelijk minimaal: vier hostfuncties, aura.log, aura.get_input, aura.set_output en aura.get_env, geregistreerd via linker.func_wrap. Het is niet het Component Model, noch WASI Preview 2: het is een intern contract, smaller, ontworpen voor eenmalig gebruik, dat een HTTP edge-functie uitvoert en de JSON-reactie herstelt.

Deze wasm-modus is een keuze per functie, geen globale schakelaar. Het Aurabase-architectuuroverzicht beschrijft het andere pad, de standaard deno-modus, die JavaScript/TypeScript in een aparte service uitvoert. Beide bestaan ​​naast elkaar in dezelfde aura-functions-service.

Bronnen: Cargo.toml en wasm/mod.rs uit de Aurabase-repository, rechtstreeks geverifieerd op 24 augustus 2026. Algemene Wasmtime- en Wasmer-kenmerken overgenomen uit de openbare documentatie van elk project; In deze tabel worden geen benchmarkcijfers van derden opnieuw gepubliceerd.

U start een nieuwe edge-runtime, zonder bestaande afhankelijkheden. Wasmtime, ondersteund door een stichting met meerdere leveranciers, vermindert het risico dat u voor de toekomst van het project afhankelijk bent van één enkele uitgever.

U heeft zeer frequente en kortstondige koude starts. Wasmers Singlepass-backend beantwoordt direct aan deze behoefte, vrijwel onmiddellijke compilatie, ten koste van minder geoptimaliseerde machinecode.

Je hebt POSIX-primitieven nodig die verder gaan dan de huidige standaard WASI. WASIX, de Wasmer-extensie, dekt schroefdraden en verlengde sockets af die WASI Preview 2 alleen nog niet dekt.

U wilt een native beeldmateriaal- en time-out-API, zonder middleware van derden. Wasmtime stelt fuel en epoch rechtstreeks in de krat bloot, precies wat aura-functions mogelijk maakt bij Aurabase.