Solomon Hykes sa i 2019 at dersom WASM og WASI hadde eksistert i 2008, ville Docker ikke vært nødvendig. Syv år senere er utsagnet fortsatt feil i bokstavelig forstand og fortsatt riktig i retning. Containere løste utrulling. Komponenter løser komposisjon.

WebAssembly Component Model -- ferdigstilt som del av WASI 0.2 og i rask modning gjennom 0.3 -- er det manglende kontraktlaget. Det definerer hvordan uavhengig kompilerte moduler eksponerer og konsumerer typede grensesnitt, hvordan disse modulene komponeres uten delt minne, og hvordan kapabilitetsbasert sikkerhet styrer hva hver komponent kan aksessere.

Dette er ikke nok et "Wasm er fremtiden"-essay. Dette er en produksjonsarkitekturguide for team som bygger på edge i 2026.

I. Problemet komponenter løser

WebAssembly-moduler er raske. De er sandkasseisolerte. De starter på mikrosekunder. Men frem til Component Model var de også øyer.

En kjerne-Wasm-modul eksporterer funksjoner med fire numeriske typer: i32, i64, f32, f64. Ingen strenger. Ingen poster. Ingen lister. Ingen feiltyper. Å sende et JSON-dokument fra en JavaScript-vert til en Rust-modul krevde manuell serialisering, pekeraritmetikk, delt lineært minne og et fromt ønske.

Dette skapte tre feilmodi i produksjonssystemer:

  1. Limkodedominans. Team brukte mer tid på serialiseringsgrenser enn på forretningslogikk.
  2. Språklåsing. Praktisk polyglot komposisjon var en konferansedemonstrasjon, ikke en utrullingsrealitet.
  3. Ingen kontraktshåndhevelse. Vert og gjest ble enige om funksjonssignaturer ved konvensjon. Bryt konvensjonen, og du får en felle ved kjøretid.

Component Model eliminerer alle tre. Det introduserer et typet grensesnittdefinisjonsspråk (WIT), en kanonisk ABI for rike typer, og en komposisjonsmodell som lar uavhengig kompilerte komponenter lenkes gjennom delte grensesnitt.

Analogien er ikke mikrotjenester. Analogien er statisk lenking med typesikkerhet på tvers av språkgrenser.

II. WIT: Grensesnittkontrakten

WIT -- WebAssembly Interface Types -- er Component Models IDL. Det definerer pakker, grensesnitt og verdener. Har du skrevet gRPC protobuf-definisjoner eller TypeScript-typedeklarasjoner, vil WIT kjennes kjent. Har du ikke det, vil det kjennes som om noen endelig skrev ned kontrakten som alltid var implisitt.

Et minimalt HTTP-handlergrensesnitt:

package gothar:edge@0.1.0;


interface types {
    record http-request {
        method: string,
        uri: string,
        headers: list<tuple<string, string>>,
        body: option<list<u8>>,
    }



record http-response {
        status: u16,
        headers: list<tuple<string, string>>,
        body: list<u8>,
    }



enum log-level {
        debug,
        info,
        warn,
        error,
    }
}



interface handler {
    use types.{http-request, http-response};
    handle: func(req: http-request) -> http-response;
}



interface logger {
    use types.{log-level};
    log: func(level: log-level, message: string);
}



world edge-service {
    import logger;
    export handler;
}

Tre ting er vesentlige her.

Rike typer krysser grensen. Strenger, poster, lister, options, results, enums, varianter, flagg. Den kanoniske ABIen håndterer serialisering. Komponentforfatteren berører aldri rå pekere.

Verdener definerer kontrakten. En verden deklarerer hva en komponent importerer (kapabiliteter den trenger) og eksporterer (kapabiliteter den tilbyr). edge-service-verdenen over sier: "Jeg trenger en logger. Jeg tilbyr en HTTP-handler." Det er hele kontrakten. Ikke mer. Ikke mindre.

Versjoner er eksplisitte. @0.1.0-suffikset betyr at grensesnitt utvikler seg med semantisk versjonering. Et register kan hoste flere versjoner. Konsumenter pinner til kompatible intervaller. Dette er pakkehåndtering for beregningsenheter.

WIT er ikke Turing-komplett. Det kan ikke uttrykke forretningslogikk. Det uttrykker form. Den begrensningen er egenskapen.

III. Komponenter vs. containere vs. funksjoner

Sammenligningen er viktig fordi team vil spørre "hvorfor ikke bare bruke Docker" og "hvordan skiller dette seg fra Lambda." Begge er rimelige spørsmål.

+-------------------------------------------------------------------+
|                  Sammenligning av utrullingsenheter                |
+-------------------------------------------------------------------+
|                | Container      | Serverless Fn  | Wasm-komponent |
|----------------|----------------|----------------|----------------|
| Kaldstart      | 100ms - 2s     | 50ms - 1s      | <1ms - 5ms     |
| Minnegulv      | 20 - 100 MB    | 128 MB (typ.)  | <1 MB          |
| Isolasjon      | Linux ns/cgrp  | VM/prosess     | Kapabilitets-VM|
| Komposisjon    | Nettverkskall  | Hendelsesutl.  | WIT-grensesn.  |
| Polyglot       | Alle (separat) | Kjøretidsbund. | Alle (delt)    |
| Tetthet        | 10-100/node    | Plattformstyrt | 1000+/prosess  |
| Syscall-tilg.  | Full POSIX     | Begrenset      | Ingen (tildelt)|
| Tilstandsmod.  | Persistent OK  | Flyktig        | Flyktig        |
| Angrepsflate   | Linux-kjerne   | Leverandør-VM  | ~100K LOC VM   |
+-------------------------------------------------------------------+

Nøkkelforskjellen er ikke kaldstart. Det er komposisjonsmodell.

Containere komponerer over nettverket. Tjeneste A kaller Tjeneste B via HTTP eller gRPC. Nettverket er grensesnittet. Latens, serialisering, gjentakelseslogikk og kretsbrytermekanismer er skatten.

Serverless-funksjoner komponerer via hendelsesutløsere. S3 utløser en Lambda som utløser en SQS som utløser nok en Lambda. Hendelsesbussen er grensesnittet. Eventuell konsistens og fan-out-kompleksitet er skatten.

Komponenter komponerer via typede grensesnitt innenfor en enkelt prosess. Komponent A importerer et grensesnitt som Komponent B eksporterer. Den kanoniske ABIen er grensesnittet. Ingen nettverk. Ingen serialisering utover ABIen. Ingen gjentakelseslogikk. Komposisjonen er strukturell, ikke operasjonell.

Dette betyr at en forespørsel på edge kan flyte gjennom en Rust-autentiseringskomponent, en JavaScript-forretningsregelkomponent og en Python-datatransformasjonskomponent -- alle i samme prosess, alle typekontrollert ved komposisjonstidspunkt, alle sandkasseisolert fra hverandre.

Det er nytt. Og det endrer arkitekturen til edge-systemer.

IV. Kjøretidslandskapet

Tre kjøretider er relevante i produksjon i dag. Andre finnes. Disse leverer.

Wasmtime

Referanseimplementasjonen. Vedlikeholdt av Bytecode Alliance. Rust-basert. Støtter full Component Model, WASI 0.2, og ahead-of-time-kompilering. Wasmtime driver Fermyon Spin, SpinKube, og de fleste Kubernetes-integrerte Wasm-arbeidsbelastninger.

Kaldstart med AOT: under et millisekund for små komponenter. Kjøretiden er designet rundt prinsippet om at instansiering skal være billigere enn en HTTP-rundtur.

Cloudflare Workers (workerd)

Ikke Wasmtime. Cloudflares kjøretid er bygget på V8-isolater med Wasm-støtte. JavaScript og TypeScript er førsteklasses. Wasm-moduler kjører inne i isolater sammen med JS. Component Model støttes gjennom Cloudflares jco-verktøy som transpilerer komponenter til JS-kompatible bindinger.

Skala: 300+ datasentre, millioner av utrullede workere, kaldstart på enkeltsiffer-millisekunder. Dette er den største Wasm-utrullingen i produksjon på jorden.

Fermyon Spin

Et rammeverk bygget på Wasmtime spesifikt for komponentbaserte applikasjoner. Spin håndterer ruting, utløserkobling og komponentlivssyklus. Du skriver komponenter. Spin kobler dem.

# spin.toml
spin_manifest_version = 2


[application]
name = "edge-pipeline"



[[trigger.http]]
route = "/api/transform"
component = "transformer"



[[trigger.http]]
route = "/api/auth"
component = "authenticator"



[component.transformer]
source = "target/wasm32-wasip2/release/transformer.wasm"



[component.authenticator]
source = "target/wasm32-wasip2/release/authenticator.wasm"

Hver komponent er uavhengig kompilert, uavhengig sandkasseisolert, og kommuniserer gjennom WIT-grensesnitt. Spin utrulles til Fermyon Cloud, Kubernetes via SpinKube, eller ethvert miljø med Wasmtime.

V. Polyglot komposisjon i praksis

Løftet er reelt, men avgrenset. Her er hva som fungerer i dag.

Rust

Førsteklasses støtte. Verktøyet cargo-component kompilerer Rust-crates til Wasm-komponenter med WIT-bindinger generert ved byggetid via wit-bindgen.

// src/lib.rs
wit_bindgen::generate!({
    world: "edge-service",
});


struct EdgeHandler;



impl Guest for EdgeHandler {
    fn handle(req: HttpRequest) -> HttpResponse {
        let body = match req.method.as_str() {
            "GET" => format!(r#"{{"status":"ok","path":"{}"}}"#, req.uri),
            _ => r#"{"error":"method not allowed"}"#.to_string(),
        };



HttpResponse {
            status: 200,
            headers: vec![
                ("content-type".into(), "application/json".into()),
            ],
            body: body.into_bytes(),
        }
    }
}



export!(EdgeHandler);

Bygg:

cargo component build --release

Resultat: en .wasm-fil som tilfredsstiller edge-service-verdenen. Enhver kjøretid som forstår den verdenen kan hoste den.

JavaScript og TypeScript

ComponentizeJS og Bytecode Alliances jco-verktøykjede kompilerer JavaScript til Wasm-komponenter. JS-motoren (StarlingMonkey) er innebygd i selve komponenten. Overheaden er reell -- komponenten inkluderer en JS-kjøretid -- men for team med eksisterende JS-kodebaser fjerner det omskrivingsbarrieren.

// handler.js
export function handle(req) {
    const data = JSON.parse(new TextDecoder().decode(new Uint8Array(req.body)));
    const transformed = applyBusinessRules(data);


return {
        status: 200,
        headers: [["content-type", "application/json"]],
        body: new TextEncoder().encode(JSON.stringify(transformed)),
    };
}

Kompiler til komponent:

jco componentize handler.js --wit edge-service.wit -o handler.wasm

Den resulterende komponenten implementerer det samme WIT-grensesnittet som Rust-versjonen. For kjøretiden er de utbyttbare.

Python

componentize-py bygger inn en Python-tolk (CPython kompilert til Wasm) og genererer bindinger fra WIT. Tidlig fase, men funksjonelt. Komponentstørrelsen er større (~15 MB mot ~2 MB for Rust) på grunn av den innebygde tolken.

Det praktiske bruksområdet er datatransformasjon og ML-inferens på edge, der Pythons økosystemfordel oppveier størrelseskostnaden.

Komposisjonssteget

Uavhengige komponenter lenkes gjennom wac (WebAssembly Compositions):

wac plug authenticator.wasm --plug transformer.wasm -o composed.wasm

Den sammensatte komponenten tilfredsstiller unionen av importerte grensesnitt og eksponerer unionen av eksporterte grensesnitt. Typefeil fanges ved komposisjonstidspunkt, ikke ved kjøretid. Dette er kompileringstidsgarantien som containere og serverless-funksjoner ikke kan tilby.

VI. Sikkerhet: Kapabilitetsbasert som standard

Component Model arver WASIs sikkerhetsmodell. Det er verdt å si det klart, fordi standarden er det motsatte av hva de fleste utviklere forventer.

En komponent starter med ingenting. Intet filsystem. Intet nettverk. Ingen miljøvariabler. Ingen klokke. Ingen tilfeldig tallgenerering. Ingen DNS-oppløsning. Ingenting.

Kapabiliteter tildeles eksplisitt av verten:

+-----------------------------------------------+
  |  Vertskjøretid (Wasmtime / workerd / Spin)     |
  |                                                |
  |  Tildeler:                                     |
  |    wasi:http/outgoing-handler  (hente URLer)   |
  |    wasi:keyvalue/store         (lese/skrive KV)|
  |    wasi:logging/handler        (sende logger)  |
  |                                                |
  |  Avviser (ved utelatelse):                     |
  |    wasi:filesystem/*           (ingen disk)    |
  |    wasi:sockets/*              (ingen rå nett) |
  |    wasi:cli/environment        (ingen env-var) |
  +-----------------------------------------------+
           |
           v
  +-----------------------------------------------+
  |  Komponent (sandkasseisolert)                  |
  |                                                |
  |  Kan: gjøre HTTP-forespørsler, lese/skrive KV, |
  |       logge                                    |
  |  Kan ikke: aksessere filsystem, åpne sokler,   |
  |            lese env-var, aksessere klokke       |
  +-----------------------------------------------+

Dette er ikke et tillatelsessystem lagt oppå en tillatende kjøretid. Det er en avvis-som-standard-arkitektur der fraværet av et kapabilitetshåndtak betyr at kapabiliteten ikke eksisterer innenfor komponentens univers.

Sikkerhetsimplikasjonene for multi-tenant edge-plattformer er betydelige:

  • Leietakerisolasjon uten prosessisolasjon. Flere komponenter fra ulike leietakere kjører i samme prosess. Hver ser kun sine tildelte kapabiliteter.
  • Ingen rettighetseskaleringsvei. Det finnes intet syscall-grensesnitt å utnytte. Angrepsflaten er Wasm-VMen (~100K kodelinjer i Wasmtime) mot Linux-kjernen (~30M linjer).
  • Reviderbare tillatelser. WIT-verdensdeklarasjonen er et manifest over hva en komponent kan gjøre. Kodegjennomgang av sikkerhetsposisjonen reduseres til å gjennomgå verdensdefinisjonen.

Dette er grunnen til at Shopify kjører handlerkode som Wasm, Figma sandkasseisolerer plugins i Wasm, og Cloudflare stoler på millioner av tredjepartsworkere i delte prosesser. Isolasjonsmodellen er strukturelt sterkere enn containere for upålitelig kode.

VII. Produksjonsmønstre

Teori er billig. Her er tre mønstre vi har utrullet eller evaluert i produksjons-edge-systemer.

Mønster 1: Sammensatt HTTP-pipeline

Forespørsel
    |
    v
  +----------------+     +------------------+     +----------------+
  | Auth-komponent |---->| Transform-komp.  |---->| Ruter-komp.    |
  |  (Rust)        |     | (JavaScript)     |     | (Rust)         |
  |                |     |                  |     |                |
  | Validerer JWT  |     | Anvender forr.-  |     | Ruter til      |
  | Henter ut      |     | regler, omformer |     | opprinnelse    |
  | claims         |     | nyttelast        |     | eller cache    |
  +----------------+     +------------------+     +----------------+
    importerer:            importerer:              importerer:
    - wasi:http            - wasi:logging           - wasi:http
    - wasi:clocks          eksporterer:             - wasi:keyvalue
    eksporterer:           - transform-grensesn.    eksporterer:
    - auth-grensesnitt                              - handler-grensesn.

Alle tre komponentene kjører i en prosess. Komposisjonen defineres ved utrullingstidspunkt. Å erstatte JavaScript-transformatoren med en Python-versjon krever endring av en .wasm-fil, ikke ny utrulling av systemet. WIT-grensesnittet håndhever kompatibilitet.

Kaldstart for hele pipelinen: under 5ms på Wasmtime AOT.

Mønster 2: ML-inferens på edge

En forhåndstrent ONNX-modell kompilert til Wasm via wasi-nn kjører klassifisering på edge. Komponenten mottar en feature-vektor, kjører inferens, returnerer en prediksjon. Ingen modellserver. Ingen container. Ingen GPU krevd for små modeller.

// Forenklet wasi-nn inferenskomponent
fn classify(features: Vec<f32>) -> Result<Prediction, InferenceError> {
    let graph = wasi_nn::GraphBuilder::new(
        wasi_nn::GraphEncoding::Onnx,
        wasi_nn::ExecutionTarget::Cpu,
    )
    .build_from_cache("product-classifier")?;


let context = graph.init_execution_context()?;
    context.set_input(0, wasi_nn::TensorType::Fp32, &[1, features.len() as u32], &features)?;
    context.compute()?;



let mut output = vec![0f32; 10];
    context.get_output(0, &mut output)?;



Ok(Prediction::from_logits(&output))
}

Modellvektene leveres som en separat artefakt. Komponenten håndterer kun inferenslogikk. Minnefotavtrykk: 10-50 MB avhengig av modellstørrelse. Latens: 2-20ms avhengig av modellkompleksitet. For produktanbefalinger, innholdsklassifisering eller svindelscoring på edge eliminerer dette rundturen til opprinnelsesserveren.

Mønster 3: Datatransformasjon fan-out

En enkelt innkommende webhook utløser flere transformasjonskomponenter. Hver transformerer nyttelasten for et ulikt nedstrømssystem. Komponenter deler ingen tilstand. Hver har sine egne kapabilitetstildelinger.

Webhook (JSON)
       |
       v
  +--Fordelingskomponent--+
  |                        |
  +----+-------+-------+--+
       |       |       |
       v       v       v
  +---------+ +------+ +----------+
  | CRM-    | | ERP  | | Analyse- |
  | format  | | XML  | | Parquet  |
  | (Rust)  | | (JS) | | (Python) |
  +---------+ +------+ +----------+
       |       |       |
       v       v       v
  wasi:http  wasi:http  wasi:http
  (POST CRM) (POST ERP) (POST lake)

Tre språk. Tre komponenter. En prosess. Typesikker komposisjon. Uavhengige sandkasser. Python-komponenten kan ikke se CRM-legitimasjonen tildelt Rust-komponenten.

VIII. Ytelse: Hva tallene sier

Benchmarks lyver. Men de lyver på informative måter. Her er hva vi måler og hva vi har observert.

Kaldstart

Kjøretid Modulstørrelse Kaldstart (P50) Kaldstart (P99)
Wasmtime AOT 2 MB 0,3ms 1,2ms
Wasmtime AOT 15 MB 1,1ms 3,8ms
Cloudflare Workers 1 MB ~1ms ~3ms
Spin (Wasmtime) 2 MB 0,5ms 1,5ms
Docker (Alpine) 50 MB 150ms 400ms
AWS Lambda (Node) 30 MB 80ms 300ms

Gapet er strukturelt. Containere starter en OS-abstraksjon. Komponenter instansierer en typet sandkasse. Dette er ulike operasjoner med ulike kompleksitetsgrenser.

Minnetetthet

En Wasmtime-prosess som hoster 1 000 inaktive Wasm-komponenter bruker omtrent 200 MB minne. Samme arbeidsbelastning i containere ville kreve 20-100 GB avhengig av basebilde og kjøretid. Dette er tetthetsfordelen som gjør multi-tenant edge-plattformer levedyktige.

Varmsti-gjennomstrømning

For CPU-bundet arbeid (JSON-parsing, kryptografiske operasjoner, datatransformasjon) når AOT-kompilerte Wasm-komponenter 85-95% av nativ Rust-ytelse. Det gjenstående gapet er kanonisk ABI-overhead ved grensesnittgrenser og fravær av SIMD-autovektorisering i noen kjøretider.

For I/O-bundet arbeid er flaskehalsen vertsgrensesnittet, ikke komponenten. En komponent som gjør wasi:http-kall er begrenset av nettverkslatens, ikke av Wasm-kjøringshastighet.

Den ærlige oppsummeringen: komponenter er ikke universelt raskere. De er raskere å starte, billigere å hoste, og sammenlignbare i stabil tilstand for de fleste edge-arbeidsbelastninger. For langkjørende beregningsintensive tjenester vinner native binærfiler i containere fortsatt på gjennomstrømning.

IX. Komponentregisterets økosystem

Komponenter trenger en distribusjonsmodell. OCI-registre tilbyr den.

warg-protokollen og eksisterende OCI 1.1-artefaktstøtte betyr at Wasm-komponenter kan publiseres til, versjoneres i, og hentes fra de samme registrene som hoster containerbilder. Docker Hub, GitHub Container Registry og Azure Container Registry støtter alle Wasm-artefakter i dag.

# Publiser en komponent til et register
wasm-tools component new transformer.wasm -o transformer.component.wasm
oras push ghcr.io/gothar/transformer:v1.2.0 \
    transformer.component.wasm:application/vnd.wasm.component.v1+wasm


oras pull ghcr.io/gothar/transformer:v1.2.0
spin up --from transformer.component.wasm

Bytecode Alliance-registeret er det fremvoksende fellesskapsregisteret for WIT-pakker og komponenter. Tenk npm eller crates.io, men for komponerbare beregningsenheter. Det er tidlig. Primitivene er på plass. Økosystemtettheten er det ikke.

Det som betyr noe for produksjonsteam: du trenger ikke ny infrastruktur. Dine eksisterende CI/CD-pipelines, OCI-registre og Kubernetes-operatører kan håndtere komponenter. Integrasjonskostnaden er lav.

X. Hva dette ikke løser

Intellektuell ærlighet krever en liste over manglene.

Observerbarhet er umodent. OpenTelemetry-støtte via wasi:observe eksisterer, men er inkonsistent på tvers av kjøretider. Du vil skrive tilpasset instrumentering. Dine eksisterende Datadog-dashbord vil ikke fungere ut av boksen. Budsjetter 2-3 måneder med observerbarhetsinvestering for et produksjonskomponentbasert system.

Feilsøking er smertefullt. Å stå gjennom en sammensatt pipeline av Rust + JS + Python-komponenter krever ulike verktøykjeder for hvert språk. Det finnes ingen samlet debugger. printf-feilsøking er fortsatt den pragmatiske standarden.

Økosystemtettheten er tynn. npm-registeret har 2 millioner pakker. Wasm-komponent-økosystemet har hundrevis. Du vil skrive mer fra bunnen av. Den kostnaden er reell.

Langlevd tilstand er ikke modellen. Komponenter er designet for forespørsel-svar- og hendelsesdrevne mønstre. WebSocket-servere, spilløkker og vedvarende tilkoblingshåndterere er bedre tjent med containere.

GPU-tilgang eksisterer ikke. wasi:nn tilbyr CPU-basert inferens. For GPU-arbeidsbelastninger -- trening, stor modellinferens, videoprosessering -- er containere med NVIDIA-kjøretid fortsatt det eneste alternativet.

Team som ignorerer disse manglene vil feile. Team som planlegger rundt dem vil oppleve at Component Model innfrir sitt kjerneløfte: komponerbar, polyglot, sikker beregning på edge.

XI. Hvorfor dette betyr noe nå

Component Model er ikke en fremtidig spesifikasjon. WASI 0.2 er levert. Wasmtime 21+ implementerer det. Cloudflare støtter komponenter i produksjon. Fermyon Spin 3.0 er bygget helt rundt komponenter. SpinKube kjører dem på Kubernetes.

Adopsjonsinfleksjonen er her av tre grunner:

For det første løste WIT grensesnittproblemet. Før WIT kunne ikke Wasm-moduler dele rike typer. Nå kan de det. Det fjerner den største barrieren for komposisjon.

For det andre konvergerte registerhistorien med OCI. Komponenter distribueres gjennom eksisterende infrastruktur. Ingen nye registerservere. Ingen nye autentiseringssystemer. Ingen nye CI/CD-pipelines.

For det tredje modnet kjøretidsøkosystemet samtidig. Wasmtime, workerd og Spin støtter alle komponenter. Team har valgmuligheter. Innlåsing er lav.

Banen er klar. Nye edge-arbeidsbelastninger i 2026 bør standardisere til komponenter med mindre det finnes en spesifikk grunn til å la være. Grunnene eksisterer -- observerbarhetsgap, GPU-behov, langlevd tilstand -- men de snevres inn.

Avslutning

Det er et avsnitt i Christopher Alexanders The Timeless Way of Building der han argumenterer for at livet i en bygning ikke kommer fra materialene, men fra mønstrene av hendelser som oppstår i den. En bygning som tillater de rette mønstrene består. En som motarbeider dem forfaller, uansett hvor sterke veggene er.

Det samme gjelder for beregningsarkitekturer. Containere ga oss isolasjon. Funksjoner ga oss hendelsesdrevne mønstre. Men ingen av dem ga oss komposisjon -- evnen til å bygge større systemer av mindre, typede, uavhengig forfattede enheter uten nettverksgrensenes skatt.

Component Model gir Wasm den komposisjonshistorien. Det er ikke en erstatning for containere, like lite som et vindu er en erstatning for en vegg. Det er et annet arkitektonisk element, egnet for et annet strukturelt behov. Edge er den strukturen. Polyglotte team som deler typede kontrakter på tvers av språkgrenser, med sikkerhet håndtert ved fravær snarere enn konfigurasjon, og kaldstarter målt i brøkdeler av et millisekund.

Materialene har ankommet. Mønstrene av hendelser vil følge.

Referanser

  1. WebAssembly Component Model Specification. component-model.bytecodealliance.org
  2. WASI 0.2 (Preview 2) Specification. github.com/WebAssembly/WASI
  3. WIT (WebAssembly Interface Types) Format. component-model.bytecodealliance.org/design/wit.html
  4. Wasmtime Runtime. wasmtime.dev
  5. Fermyon Spin Framework. developer.fermyon.com/spin
  6. Cloudflare Workers Component Model Support. blog.cloudflare.com
  7. ComponentizeJS -- JavaScript to Wasm Components. github.com/nickvidal/componentize-js
  8. componentize-py -- Python to Wasm Components. github.com/bytecodealliance/componentize-py
  9. wasi-nn -- Neural Network Inference for WASI. github.com/WebAssembly/wasi-nn
  10. OCI 1.1 Artifact Support. github.com/opencontainers/image-spec
  11. SpinKube -- Spin on Kubernetes. spinkube.dev
  12. Alexander, Christopher. The Timeless Way of Building. Oxford University Press, 1979.