WASI preview 3: adopción y casos reales

Actualizado: 2026-05-03

WASI preview 3 se estabilizó oficialmente a finales de 2025, después de más de dos años de trabajo sobre las bases que preview 2 dejó en 2024. Llegar aquí costó más de lo que la comunidad esperaba, y durante un tiempo parecía que el proyecto se había atascado en discusiones sobre async y modelo de componentes. Al arrancar 2026 con un estándar publicado y varios runtimes con soporte sólido, toca evaluar qué ha cambiado en la práctica y qué casos reales han empezado a moverse.

Puntos clave

• Preview 3 añade lo que faltaba a preview 2: async nativo, streams bidireccionales bien definidos y concurrencia entre componentes con semántica especificada.
• Ya no hay que elegir entre portabilidad y async: un componente con async se ejecuta en wasmtime, WasmEdge, JCO y los principales runtimes comerciales sin cambios.
• Los casos de producción que mejor funcionan: API gateways con lógica compleja y plugins de extensión para aplicaciones SaaS.
• WASI Cloud estabilizó su primera versión oficial: el mismo componente Wasm habla sobre AWS, Azure, Google Cloud o backend auto-alojado cambiando solo el adaptador.
• Roces que persisten: soporte irregular en runtimes comerciales más allá de wasmtime, WasmEdge y Spin; tiempos de inicio en frío todavía por encima de binarios nativos; depurado más torpe.

Qué trae preview 3 que faltaba en preview 2

Preview 2 ya era un estándar perfectamente usable para muchos casos. Aportaba interfaces para filesystem, redes, aleatoriedad, reloj y manejo de entorno, todo sobre el modelo de componentes introducido en 2024. Pero había tres carencias que limitaban adopción en escenarios avanzados:

1. Ausencia de async nativo — los casos que necesitaban concurrencia seria acababan o fuera de WASI con runtimes propios, o con soluciones ad-hoc que rompían la compatibilidad.
2. Falta de streams bidireccionales bien definidos — limitaba la implementación portable de protocolos como WebSocket o gRPC.
3. Limitaciones en la interacción entre componentes concurrentes — no había suficiente especificación para construir arquitecturas donde varios componentes colaboran mediante mensajes asíncronos.

Preview 3 resuelve estas tres carencias de forma coordinada. El modelo async es ahora parte del propio estándar, con primitivas para futures, streams y cancelación que encajan naturalmente en el modelo de componentes. Con preview 3, un componente que usa async se ejecuta en wasmtime, WasmEdge, JCO (para navegador) y en los principales runtimes comerciales sin cambios.

Runtimes maduros y casos en producción

Wasmtime (Bytecode Alliance) alcanzó soporte completo de preview 3 con su versión 26 en noviembre de 2025. WasmEdge lo hizo en enero de 2026 con su versión 0.15. Spin de Fermyon incorporó preview 3 en su versión 3.5 a inicios de año. Estas tres bases cubren la mayoría de casos reales que veo hoy en producción.

Caso práctico 1: API gateway con Spin 3.5 — Una empresa que necesitaba lógica compleja de enrutado, transformación de peticiones y políticas de autorización específicas ha reemplazado su anterior gateway NGINX con scripts Lua por un conjunto de componentes Wasm en Spin. La razón principal no fue rendimiento (el NGINX era suficiente) sino mantenibilidad: los componentes Wasm se pueden escribir en Rust, TypeScript o Go con el modelo que prefieras, testear aisladamente, versionar de forma independiente y desplegar sin reiniciar el proceso principal. Preview 3 fue necesario porque las políticas más complejas requerían llamadas asíncronas a servicios externos durante la evaluación de autorización.

Caso práctico 2: plugins de extensión para aplicaciones SaaS — Varios productos que históricamente permitían extensiones mediante JavaScript sandbox han movido su arquitectura a componentes WebAssembly. Las razones: los plugins Wasm son más rápidos, más seguros (sandbox nativo del runtime) y portables entre lenguajes. Preview 3 fue clave aquí porque muchos plugins necesitan hacer llamadas HTTP o acceder a APIs internas con patrones async, y preview 2 obligaba a trucos torpes o a funciones bloqueantes que degradaban rendimiento.

El ecosistema de componentes y bibliotecas

Más allá del estándar, el ecosistema de componentes precompilados se ha enriquecido. WASI Cloud —la familia de interfaces estandarizadas para servicios en la nube: colas, blobs, KV, pub/sub, LLM— estabilizó su primera versión oficial con preview 3 integrado. Esto permite construir aplicaciones portables entre proveedores: el mismo componente Wasm que habla WASI Cloud funciona sobre AWS, Azure, Google Cloud o un backend auto-alojado, con solo cambiar el adaptador.

Las herramientas de construcción también han mejorado:

• Cargo component para Rust.
• jco para JavaScript y TypeScript.
• El ecosistema Go con tinygo o el compilador oficial WebAssembly.

Todos producen componentes preview 3 con herramientas maduras, errores decentes y documentación que ya no es solo el README del repo.

Las bibliotecas de componentes reutilizables son el paso siguiente. Ya existen componentes estándar para parseo JSON, cliente HTTP, cliente Postgres, serialización Protobuf, cifrado con libsodium y muchos más. Componerlos dentro de una aplicación es tan sencillo como declarar dependencias en el manifest y dejar que el linker resuelva la composición. Este modelo permite reutilizar lógica entre lenguajes de forma natural: un componente compilado desde Rust lo consume sin fricción un componente escrito en TypeScript, sin FFI.

Un ejemplo mínimo con Spin y async

Un patrón común es una pequeña API web que consume servicios externos con concurrencia. El siguiente fragmento muestra cómo queda en Spin 3.5 con Rust y WASI preview 3:

use spin_sdk::http::{Method, Request, Response, Router};
use spin_sdk::http_component;
use futures::future::join_all;

#[http_component]
async fn handle_request(req: Request) -> anyhow::Result<Response> {
    let urls = vec![
        "https://api.one.example/status",
        "https://api.two.example/status",
        "https://api.three.example/status",
    ];

    let fetches = urls.iter().map(|u|
        spin_sdk::http::send::<_, Response>(Request::new(Method::Get, u)));

    let results = join_all(fetches).await;
    let healthy = results.iter().filter(|r| r.is_ok()).count();

    Ok(Response::new(200, format!("{} de {} saludables", healthy, urls.len())))
}

Este fragmento habría sido imposible en preview 2 sin trucos fuera de la especificación. En preview 3 es sintaxis natural, con concurrencia real entre peticiones HTTP, y se ejecuta en cualquier runtime compatible sin código específico. Esta ergonomía es lo que ha desbloqueado casos que llevaban dos años esperando.

Dónde sigue habiendo roces

No todo es color de rosa:

• Soporte preview 3 en runtimes comerciales más allá de los mencionados sigue siendo irregular. Algunos proveedores de edge computing que adoptaron temprano preview 2 están tardando más de lo esperado en migrar, lo que obliga a compilar para la versión más vieja si se quiere portabilidad máxima. La mayoría estabilizará durante el primer semestre de 2026.
• Tiempos de inicio en frío siguen siendo peores que con binarios nativos. Para cargas que requieren latencia muy baja en invocaciones puntuales, Wasm sigue añadiendo unos pocos milisegundos en startup. Para cargas de larga duración esto no importa, pero para microservicios invocados miles de veces por minuto con SLO agresivos, hay que medir.
• El depurado sigue siendo más torpe que el de binarios nativos. Las trazas de pila en componentes Wasm son menos legibles, los depuradores visuales son más limitados y la instrumentación de bajo nivel requiere más esfuerzo.

Cuándo compensa adoptar

Para un equipo que se esté planteando Wasm en producción, conviene distinguir tres escenarios:

1. Casos donde Wasm aporta valor claro y no urgente: plugins para productos SaaS, funciones en edge computing, lógica embebida en aplicaciones mayores. Aquí vale la pena arrancar ya con preview 3, sabiendo que la curva inicial es notable pero el retorno a medio plazo es sólido.

2. Casos de sustitución de arquitecturas existentes que funcionan bien: si tienes contenedores Docker con microservicios sanos, reemplazarlos por componentes Wasm raramente compensa. El coste de migración y de reentrenar al equipo normalmente supera las ganancias en densidad o en tiempo de arranque. Cambia solo si hay una razón operativa concreta.

3. Casos donde la promesa de Wasm resuelve un problema real: portabilidad entre servidor, edge y navegador sin reescribir; ejecución de código de terceros con garantías de aislamiento; escalas donde densidad por máquina importa mucho. Aquí Wasm con preview 3 es la opción técnica más sólida y adoptarla es decisión estratégica acertada.

Conclusión

La lectura honesta de preview 3 es que WebAssembly ha alcanzado por fin la madurez que prometía desde 2019. Preview 2 ya permitía casos interesantes, pero preview 3 cierra el círculo con async, streams y composición concurrente. El ecosistema está empezando a florecer de verdad, con runtimes maduros, bibliotecas reutilizables y casos de producción demostrables. No es sustituto universal de contenedores ni de funciones serverless propietarias. Pero para los nichos donde sus ventajas son reales —portabilidad extrema, aislamiento fuerte, densidad— es buen momento para dejar de esperar y empezar a usarlo, con la expectativa de que el estándar es estable, los runtimes son compatibles y el tooling permite productividad genuina.

La adopción de Wasm también tiene implicaciones para la arquitectura de agentes: cuando un sistema distribuido como el que describe WASI preview 3 para edge necesita componentes portables entre múltiples runtimes, los protocolos de comunicación como A2A ofrecen el canal estándar para que esos componentes coordinen trabajo.