WebAssembly encuentra su aplicación más convincente fuera del navegador

Cuando WebAssembly llegó por primera vez a los navegadores principales en 2017, la propuesta era clara: ejecutar código casi nativo sin JavaScript. Los primeros en adoptarlo portaron motores de juegos en C++, intérpretes de Python y bibliotecas de procesamiento de imágenes a la web. Funcionaba, pero los casos de uso parecían de nicho — la mayoría de las aplicaciones web no necesitaban la velocidad de C, y el ecosistema de JavaScript era lo suficientemente profundo como para que WASM rara vez lo reemplazara en el desarrollo típico.

La aplicación más interesante resultó estar fuera del navegador. En los últimos dos años, WebAssembly ha emergido como un runtime creíble para tres contextos del lado del servidor — funciones serverless, sistemas de plugins y edge computing — donde su modelo de seguridad y portabilidad importan más que el rendimiento bruto.

La propiedad que hace diferente a WASM en el servidor

La característica clave es el sandboxing por defecto. Un módulo WASM se ejecuta en un espacio de memoria aislado sin acceso al sistema anfitrión a menos que se conceda explícitamente a través de WebAssembly System Interface (WASI). No puede leer archivos, abrir conexiones de red ni lanzar procesos sin concesiones de capacidad explícitas del anfitrión. Para los navegadores, esto era un requisito de seguridad; para entornos de servidor, es una ventaja arquitectónica.

Compárese con el problema tradicional de los plugins. Cuando se quiere ejecutar código de terceros dentro de la aplicación — un plugin, una extensión, una función definida por el usuario — las opciones históricamente han sido dolorosas. O se confía implícitamente en el desarrollador del plugin y se expone el proceso a cualquier bug o código malicioso, o se ejecutan plugins en un subproceso con toda la sobrecarga de IPC, o se implementa una lista blanca de capacidades compleja que es específica del runtime y difícil de auditar. WASM resuelve esto con una primitiva única: los módulos se ejecutan en su propio sandbox, y se define exactamente qué funciones del anfitrión pueden llamar a través de una interfaz tipada.

Funciones serverless: la ventaja del arranque en frío

Cloudflare Workers fue una de las primeras apuestas en producción de WASM para serverless. Los Workers ejecutan JavaScript y WASM en isolates de V8 en la red de borde de Cloudflare, con la afirmación central de que los tiempos de arranque en frío caen drásticamente porque los módulos WASM no tienen sistema operativo que arrancar. Cloudflare reporta arranques en frío medios por debajo de 5 milisegundos para invocaciones de Workers, en comparación con 100–500ms para funciones Lambda basadas en contenedores.

Fastly adoptó un enfoque similar con su plataforma Compute, que ejecuta exclusivamente WASM y lo posiciona como reemplazo de VCL (Varnish Configuration Language). Los desarrolladores escriben en Rust, Go, JavaScript o cualquier lenguaje que compile a WASM, compilan a un módulo y lo despliegan como un servicio de Fastly — sin contenedores, sin capacidad aprovisionada, sin gestión de arranque en frío.

El framework Spin de Fermyon extiende este enfoque al desarrollo general de aplicaciones. Spin permite construir microservicios que compilan a WASM y se ejecutan sin contenedores ni Kubernetes. Cada función es un módulo que inicia en milisegundos, atiende una petición y termina. Sin pool de contenedores calientes, sin infraestructura de sidecar por función, sin registro de imágenes de contenedor que mantener.

Sistemas de plugins: donde el modelo de seguridad da frutos

Extism es un kit de desarrollo de plugins Open Source que usa WASM para permitir a los desarrolladores incrustar código de terceros de forma segura. En lugar de requerir que los plugins se escriban en el lenguaje anfitrión, Extism permite compilarlos desde cualquier lenguaje que compile a WASM — Go, Rust, Python, JavaScript. El anfitrión define una interfaz tipada pequeña; el plugin solo se comunica a través de esa interfaz. Un plugin con bugs o malicioso no puede escapar del sandbox.

Grafana Labs adoptó este modelo para plugins de backend. Los nuevos tipos de plugins de Grafana se ejecutan como módulos WASM dentro del backend de Grafana, aislados entre sí y del proceso de Grafana. Esto elimina una clase de ataques a la cadena de suministro donde un plugin comprometido obtiene acceso completo al proceso — una preocupación real en un ecosistema con cientos de contribuciones de terceros.

Envoy Proxy añadió soporte de extensiones WASM por la misma razón: un fallo en un módulo WASM no derriba el proceso del proxy ni afecta al tráfico que fluye a través de otras extensiones. Para infraestructura de borde que debe mantenerse activa, este aislamiento de fallos importa más que el rendimiento bruto.

El Component Model: la pieza que faltaba y ahora llega

El desarrollo reciente más importante del ecosistema WASM es el Component Model, introducido en WASI 0.2 a principios de 2024. Antes, los módulos WASM se comunicaban a través de búferes de memoria compartida — de bajo nivel y propensos a errores. El Component Model introduce interfaces tipadas que los módulos pueden implementar y consumir, permitiendo la composición sin memoria compartida.

En términos prácticos, esto significa que se puede definir una interfaz tipada y hacer que los plugins la implementen independientemente de su lenguaje de origen. Un anfitrión Rust puede llamar a un plugin en Python o Go a través de la misma interfaz tipada, con el runtime de WASM manejando la traducción. Esto resuelve el mayor punto de fricción en los sistemas de plugins de WASM: la necesidad de bindings FFI o un runtime compartido.

Bytecode Alliance — Mozilla, Intel, Fastly, Microsoft y Google — ha sido la organización principal que impulsa WASM fuera del navegador. Su runtime Wasmtime es la implementación de referencia para WASI 0.2 y la base de la mayoría de los despliegues en producción.

Limitaciones actuales que vale la pena conocer

WASM fuera del navegador está listo para producción en cargas de trabajo específicas, pero no es universalmente maduro. El threading requiere memoria compartida, lo que entra en conflicto con el modelo de aislamiento que usan la mayoría de los runtimes serverless — así que la mayoría de los despliegues son de un solo hilo, limitando las cargas de trabajo aplicables. WASM GC (garbage collection), que permite que los runtimes de lenguajes gestionados compilen a WASM sin incluir su propio GC, solo llegó a los navegadores principales a finales de 2023 y aún no es ampliamente compatible en runtimes de servidor. La calidad de las toolchains varía significativamente: Rust y Go tienen los targets WASM más maduros; Python y JavaScript funcionan pero con mayor complejidad operativa.

Para desarrolladores que construyen plataformas que aceptan código de terceros — API gateways, herramientas de automatización, productos de observabilidad, marketplaces de desarrolladores — WASM es ahora una opción arquitectónica seria para la capa de plugins. El modelo de seguridad es real, el rendimiento es aceptable para cargas de trabajo acotadas por petición, y el Component Model hace práctica la composición entre lenguajes. Los casos de uso del lado del servidor son donde las propiedades arquitectónicas que hacen interesante a WASM se diferencian más claramente de las alternativas.