WebAssembly (Wasm) dávno opustil prohlížeč. V roce 2026 je to plnohodnotný runtime pro serverové aplikace — od edge functions přes plugin systémy až po bezpečnostně kritické finanční služby. Kompletní průvodce: architektura, WASI 0.2, komponentový model, performance benchmarky a reálné nasazení v českých firmách.

Proč WebAssembly na serveru — a proč právě teď¶

Solomon Hykes, spoluzakladatel Dockeru, v roce 2019 prohlásil: „Kdyby Wasm + WASI existovaly v roce 2008, Docker bychom nepotřebovali.” O sedm let později se jeho predikce naplňuje — ne jako náhrada kontejnerů, ale jako komplementární vrstva tam, kde kontejnery selhávají.

Tři konvergující faktory dělají rok 2026 přelomovým:

• WASI 0.2 Preview stabilizován — konečně standardizované rozhraní pro filesystem, síť, hodiny a kryptografii. Každý Wasm modul může komunikovat se systémem přes definované capability-based API, bez přístupu k čemukoli navíc.
• Component Model 1.0 — umožňuje skládat Wasm moduly z různých jazyků (Rust + Python + Go) do jedné aplikace. Každý komponent má přesně definované rozhraní (WIT — WebAssembly Interface Types) a nemůže přistupovat k paměti ostatních.
• Produkční runtime dospěly — Wasmtime 20+, WasmEdge 0.14, Spin 3.x a Fermyon Cloud nabízejí sub-milisekundový cold start, produkční stabilitu a enterprise support.

Architektura Wasm backendu¶

Na rozdíl od klasických kontejnerových architektur, kde každý service běží ve vlastním Docker kontejneru s celým OS layerem, Wasm backend používá sandboxovaný modul — binárku o velikosti stovek kilobajtů až jednotek megabajtů, která startuje za mikrosekundy.

Vrstvy Wasm backend stacku¶

• Wasm Runtime (Wasmtime, WasmEdge, Wasmer) — JIT/AOT kompilátor, memory management, sandboxing
• WASI layer — standardizované systémové volání (soubory, síť, env vars, random, hodiny)
• Component Model — inter-module komunikace, type-safe interface přes WIT
• Application Framework (Spin, wasi-http, Leptos) — HTTP routing, middleware, state management
• Orchestrace (SpinKube, Kubernetes + runwasi, Fermyon Cloud) — scheduling, scaling, deployment

Porovnání: kontejner vs. Wasm modul¶

Vlastnost	Docker kontejner	Wasm modul
Cold start	100 ms – 5 s	0.5 – 5 ms
Velikost image	50 MB – 1 GB	0.1 – 10 MB
Izolace	Linux namespaces + cgroups	Sandboxed linear memory
Portabilita	Linux (+ emulace)	Jakýkoli OS/arch s runtime
Bezpečnostní model	Root by default, capability drop	Zero access by default, explicit grants
Multi-tenancy	Složité (K8s namespaces)	Nativní (modul = tenant)
Jazyková podpora	Jakýkoli jazyk	Rust, Go, C/C++, Python, JS, C#, Zig

WASI 0.2 — systémové rozhraní, které mění pravidla¶

WASI (WebAssembly System Interface) je to, co dělá z Wasm více než jen formát pro binárky. Je to capability-based security model — Wasm modul nemá přístup k ničemu, dokud mu host explicitně nepředá capability.

Prakticky to znamená:

• Modul nemůže číst filesystem, pokud nedostane handle na konkrétní adresář
• Modul nemůže otevřít síťové spojení, pokud nedostane socket capability
• Modul nemůže přistoupit k env proměnným, pokud nejsou explicitně předány
• Žádný modul nemůže „uniknout” ze svého sandboxu — ani exploitem v runtime

Pro enterprise bezpečnost je tohle zásadní skok. Místo modelu „kontejner má přístup ke všemu a my omezujeme” máme model „modul nemá přístup k ničemu a my povolujeme”. Defense in depth v praxi.

WASI 0.2 klíčová rozhraní¶

• wasi:http — HTTP klient a server, streaming bodies, trailers
• wasi:filesystem — sandboxovaný přístup k souborům a adresářům
• wasi:sockets — TCP/UDP, DNS lookup
• wasi:clocks — monotónní a wall-clock čas
• wasi:random — kryptograficky bezpečný RNG
• wasi:cli — stdin/stdout/stderr, env vars, exit codes
• wasi:keyvalue (proposal) — key-value store abstrakce pro state
• wasi:messaging (proposal) — pub/sub, message queues

Component Model — polyglot bez kompromisů¶

Component Model je architektonický průlom, který řeší jeden z nejstarších problémů softwarového inženýrství: jak bezpečně kombinovat kód z různých jazyků.

V tradičním světě máte FFI (Foreign Function Interface) — nebezpečné, křehké, náchylné k memory corruption. Nebo máte microservices — bezpečné, ale se síťovou latencí a serializačním overheadem.

Component Model nabízí třetí cestu:

// WIT definice rozhraní (WebAssembly Interface Types)

package core:[email protected];

interface scoring {

record customer {

id: string,

transactions: list,

risk-profile: risk-level,

}

enum risk-level {

low,

medium,

high,

critical,

}

record transaction {

amount: float64,

timestamp: u64,

merchant-category: string,

}

// Implementováno v Rustu pro performance

score: func(customer: customer) -> float64;

// Implementováno v Pythonu pro ML model

predict-churn: func(customer: customer) -> float64;

}

Rust komponent implementuje score (výpočetně náročná operace), Python komponent implementuje predict-churn (ML inference). Oba běží ve stejném procesu, komunikují přes shared-nothing interface, a ani jeden nemůže přistoupit k paměti druhého.

Performance benchmarky — čísla z praxe¶

Benchmarky jsou vždy kontextově závislé, ale naše měření na typických enterprise workloadech ukazují konzistentní vzorce:

HTTP API (JSON CRUD, 1KB payload)¶

Runtime	RPS (single core)	P99 latence	Paměť/instance
Node.js 22 (Docker)	12 400	8.2 ms	85 MB
Go 1.23 (Docker)	38 200	2.1 ms	22 MB
Rust/Spin (Wasm)	34 800	1.4 ms	3.2 MB
Rust/Axum (Docker)	41 500	1.1 ms	12 MB

Wasm verze Rustu ztrácí ~16 % RPS oproti nativnímu Rustu kvůli sandbox overheadu — ale spotřebuje 4× méně paměti. Při multi-tenant scénáři (stovky instancí) Wasm výrazně vyhrává v TCO.

Cold start (od nuly po první response)¶

Platforma	Cold start
AWS Lambda (Node.js)	180 – 800 ms
AWS Lambda (Java)	2 – 8 s
Kubernetes pod (Go)	500 ms – 3 s
Spin (Wasm)	0.5 – 3 ms
Fermyon Cloud (Wasm)	1 – 5 ms

Sub-milisekundový cold start mění hru pro serverless. Žádné warm-up strategie, žádné provisioned concurrency, žádné cold start penalty. Každý request je de facto „warm”.

Reálné use cases v enterprise¶

Kde Wasm backend skutečně vyniká — ne jako náhrada všeho, ale jako přesný nástroj pro specifické problémy:

1. Plugin systémy a rozšiřitelnost¶

Shopify, Figma, Envoy Proxy a desítky dalších produktů používají Wasm jako plugin runtime. Důvod: zákazník může nahrát vlastní kód, který běží v sandboxu — bez rizika, že poškodí host aplikaci nebo přistoupí k datům jiných zákazníků.

V českém kontextu vidíme adopci v:

• ERP systémy — zákaznické kalkulace, validace, workflow hooky jako Wasm moduly místo embedded skriptů
• API gateway — custom auth, rate limiting, request transformation jako Wasm filtry (Envoy + proxy-wasm)
• SaaS platformy — tenant-specific business logic izolovaná v Wasm modulech

2. Edge computing a IoT¶

Wasm modul o velikosti 500 KB běží stejně na cloud serveru, edge node i embedded zařízení. Pro IoT a průmyslovou automatizaci to znamená:

• Jeden codebase pro cloud i edge — kompilace do Wasm eliminuje arch-specific buildy
• OTA updaty v řádu KB místo MB — push nový Wasm modul, ne celý container image
• Izolace na edge — více tenantů na jednom zařízení bez virtualizace

3. Finanční služby a regulované prostředí¶

Banky a pojišťovny oceňují Wasm kvůli auditovatelnosti a deterministickému chování:

• Wasm modul je hermeticky uzavřený — nemá side effects mimo explicitně povolené capability
• Reprodukovatelné buildy — stejný source → stejná binárka, auditovatelné end-to-end
• Formální verifikace — Wasm bytecode má jednodušší sémantiku než nativní kód, snáz se verifikuje
• Sandboxing bez VM overheadu — důležité pro low-latency trading a risk kalkulace

4. Serverless funkce nové generace¶

Fermyon Cloud, Cloudflare Workers a Fastly Compute@Edge ukazují budoucnost serverless: Wasm jako compute primitive místo kontejnerů. Výhody:

• Žádný cold start problém (sub-ms start)
• Hustější packing — 10× více instancí na stejný hardware
• Nižší cena — méně RAM, méně CPU idle time
• Lepší izolace — každý request v izolovaném Wasm instance

Spin Framework — praktická ukázka¶

Spin od Fermyonu je nejpopulárnější framework pro Wasm backend v roce 2026. Pojďme si ukázat, jak vypadá typická enterprise aplikace:

spin.toml — konfigurace aplikace¶

spin_manifest_version = 2

[application]

name = “core-analytics-api”

version = “1.2.0”

[[trigger.http]]

route = “/api/v1/score”

component = “scoring-engine”

[component.scoring-engine]

source = “target/wasm32-wasip2/release/scoring.wasm”

allowed_outbound_hosts = [“https://db.internal:5432”]

key_value_stores = [“default”]

[[trigger.http]]

route = “/api/v1/predict/…”

component = “ml-inference”

[component.ml-inference]

source = “components/ml_inference.wasm”

allowed_outbound_hosts = [“https://model-registry.internal”]

ai_models = [“llama-3”]

Klíčový detail: allowed_outbound_hosts — Wasm komponent může komunikovat pouze s explicitně povolenými hosty. Žádný modul nemůže „zavolat domů” nebo exfiltrovat data na neznámý endpoint.

SpinKube — Wasm v Kubernetes¶

Pro týmy, které už mají Kubernetes, SpinKube integruje Wasm workloady přímo do K8s ekosystému:

apiVersion: core.spinoperator.dev/v1alpha1

kind: SpinApp

metadata:

name: core-analytics

spec:

image: “ghcr.io/core-systems/analytics:1.2.0”

executor: containerd-shim-spin

replicas: 3

resources:

limits:

memory: “64Mi”

cpu: “500m”

Wasm workloady schedulované jako běžné K8s pody, ale s 10× nižšími resource limity. Stávající monitoring, networking a CI/CD pipeline fungují beze změny.

Bezpečnostní analýza — kde Wasm vyniká a kde ne¶

Wasm sandbox je silnější než většina alternativ, ale není stříbrná kulka:

Silné stránky¶

• Linear memory isolation: Každý modul má vlastní lineární paměť, nemůže přistoupit k paměti hostu ani jiných modulů
• No ambient authority: Žádné implicitní oprávnění — filesystem, síť, env vars vyžadují explicitní grant
• Kontrolovaný control flow: Wasm nemůže provádět arbitrary jumpy — jen strukturované control flow (if/loop/block)
• Typová bezpečnost: Všechny funkce mají explicitní typ, žádné type confusion útoky
• No JIT spraying: Moderní Wasm runtime používají konstantní hardening, eliminující JIT spray vektory

Známá omezení¶

• Side-channel útoky: Spectre/timing attacks jsou stále možné — Wasm sandbox nechrání před mikroarchitekturálními side channels
• Runtime bugy: Bug ve Wasmtime/WasmEdge = potenciální sandbox escape. Mitigace: aktualizace, security audity (Wasmtime prošel formální verifikací klíčových komponent)
• Supply chain: Wasm modul může obsahovat malware — sandbox zabrání přístupu k systému, ale ne zneužití povolených capability (např. exfiltrace dat přes povolený HTTP endpoint)

Migrace existujících služeb — praktický playbook¶

Přechod na Wasm backend není big-bang migrace. Doporučujeme inkrementální přístup:

1. Fáze 1 — Plugin sandbox (týden 1-4): Identifikujte místa, kde běží nedůvěryhodný kód (zákaznické skripty, custom validace). Zabalte je do Wasm sandboxu. Žádná změna architektury, jen lepší izolace.
2. Fáze 2 — Edge functions (týden 4-8): Přesuňte stateless HTTP handlers (API gateway filtry, A/B testing logic, auth middleware) do Wasm. Nasaďte na edge přes Spin nebo Cloudflare Workers.
3. Fáze 3 — Nové služby (měsíc 2-6): Nové microservices budujte v Spin/wasi-http. Běží vedle existujících kontejnerů v K8s přes SpinKube. Stejné networking a monitoring.
4. Fáze 4 — Postupná migrace (měsíc 6+): Vytipujte existující služby s vysokým request volume a nízkým cold start tolerance. Přepište do Wasm. Měřte TCO a latenci.

Jazyková podpora — co funguje v praxi¶

Ne všechny jazyky mají stejnou úroveň Wasm podpory:

Jazyk	WASI 0.2	Component Model	Produkční připravenost
Rust	✅ plná	✅ plná	🟢 Excelentní — first-class target
Go (TinyGo)	✅ plná	⚠️ částečná	🟡 Dobrá — goroutine omezení
C/C++	✅ plná	✅ plná	🟢 Excelentní — Emscripten/wasi-sdk
Python	⚠️ componentize-py	✅ plná	🟡 Dobrá — startup overhead
JavaScript	⚠️ StarlingMonkey	⚠️ experimentální	🟡 Dobrá — specifické runtime
C#/.NET	✅ NativeAOT-LLVM	⚠️ experimentální	🟡 Zlepšuje se rychle
Zig	✅ plná	✅ plná	🟢 Excelentní — zero-overhead

Doporučení pro enterprise: Rust jako primární jazyk pro performance-critical komponenty. Python přes componentize-py pro ML inference a data processing. Go (TinyGo) pro týmy s existujícím Go codebase.

Ekonomika Wasm backendu — TCO analýza¶

Pro 100 microservices s průměrně 500 RPS/service:

Položka	Kubernetes (kontejnery)	SpinKube (Wasm)
Compute (nodes)	12× m5.xlarge	4× m5.xlarge
Měsíční cloud cost	~$4 200	~$1 400
Cold start mitigace	$800 (provisioned capacity)	$0
Celkem/měsíc	~$5 000	~$1 400
Úspora	—	72 %

Hlavní úspora pochází z hustšího packingu (3-4× méně RAM per instance) a eliminace cold start workaroundů. Disclaimer: Reálné čísla závisí na workload profilu — CPU-bound workloady mají menší rozdíl než memory-bound.

Co Wasm backend (zatím) neřeší¶

Upřímný pohled na limitace:

• Stateful workloady: Wasm moduly jsou designované jako stateless. Pro stateful logiku (websockety, streaming, in-memory cache) potřebujete external state management.
• Ekosystém knihoven: Ne každá knihovna kompiluje do Wasm. Specificky: vše co závisí na OS-specific syscalls, FFI do C knihoven, nebo threading (Wasm threads jsou stále experimentální).
• Debugging: Source maps a step-through debugging v Wasm jsou zlepšují, ale stále za nativním vývojářským zážitkem.
• GPU přístup: Pro ML inference potřebujete workaround (host function call do nativního GPU runtime). WASI-nn to řeší, ale je stále ve fázi proposal.
• Velké binárky: Python/JS Wasm moduly mohou být 20+ MB kvůli embedded interpreteru. Pro edge to může být problém.

Budoucnost: kam Wasm backend míří¶

Tři trendy, které sledujeme:

• Wasm + AI inference: WASI-nn a wasi:machine-learning otevřou cestu k sandboxovanému ML inference na edge. Představte si: ML model běží v Wasm sandboxu, nemá přístup k síti, zpracovává data lokálně.
• Wasm jako universal plugin format: Více a více aplikací (databáze, message brokery, API gateway) bude podporovat Wasm pluginy. PostgreSQL s Wasm extensions už existuje (plv8 → pglite → Wasm extensions).
• Decentralizované compute: Wasm portabilita + sandbox umožňuje trustless compute — spuštění cizího kódu na cizím hardware bez rizika. Implikace pro decentralizované cloudy a compute marketplaces.

Wasm backend: ne revoluce, ale evoluce¶

WebAssembly na serveru není náhrada Dockeru ani Kubernetes. Je to nová vrstva v toolboxu — silná tam, kde potřebujete sub-ms cold start, maximální izolaci, polyglot composability nebo hustý multi-tenant packing.

Náš přístup v CORE SYSTEMS: začínáme s plugin systémy a edge functions (nízké riziko, vysoká hodnota), a postupně rozšiřujeme na nové microservices. Existující infrastruktura zůstává — Wasm ji doplňuje, ne nahrazuje.

Chcete prozkoumat Wasm pro váš backend? Domluvte si konzultaci — pomůžeme identifikovat workloady, kde Wasm přinese největší hodnotu.