¿Es WebAssembly viable fuera del navegador?
En resumen, sí.
WebAssembly (Wasm) ha surgido como una tecnología dominante que ha revolucionado el desarrollo web. Desde las primeras demostraciones técnicas, como el popular juego Doom que se ejecuta completamente en el navegador , hasta grandes aplicaciones heredadas como Photoshop que ofrecen una experiencia similar a la de un escritorio en una página web normal, WebAssembly ofrece experiencias completamente nuevas en un programa familiar ya instalado en todas las computadoras personales del mundo.
Wasm fue diseñado para permitir que casi cualquier lenguaje de programación lo soporte independientemente del tipo de procesador que tenga la computadora del usuario, y tiene varias propiedades de seguridad favorables que el navegador utiliza para evitar el acceso no autorizado a los datos o recursos del sistema de un usuario. Resulta que estas propiedades son increíblemente útiles fuera del navegador, particularmente cuando se desea ejecutar código de forma aislada o que es ultraportátil.
La historia de POSIX en Unix
WebAssembly, de forma predeterminada, no tiene acceso a ningún recurso del sistema en el que se ejecuta. Todo es simplemente pura manipulación de ceros y unos, por eso hemos visto que Wasm se utiliza principalmente para tareas computacionalmente pesadas, como decodificar videos o manipular imágenes, en lugar de para el desarrollo de aplicaciones a gran escala. Es relativamente fácil darle a su entorno sandbox de WebAssembly acceso a funcionalidades externas, como información sobre la hora actual o datos almacenados en un archivo, pero exactamente qué API se usan tiende a variar de una aplicación a otra.
Los sistemas Unix experimentaron algo similar a lo que sucede con WebAssembly fuera del navegador. Muchas aplicaciones querían acceder a recursos comunes del sistema, como redes y sistemas de archivos, pero cada sistema operativo tenía una forma ligeramente diferente de hacerlo. Por esta razón, POSIX se estrenó como una interfaz de sistema operativo portátil estándar: todos los sistemas tipo Unix podían adoptar esta interfaz para estandarizar la forma en que los programas se comunicaban con el sistema operativo. Esto también hizo que los programas diseñados para funcionar en un sistema tipo Unix pudieran trasladarse fácilmente para funcionar en otro.
Presentamos WASI, la interfaz del sistema WebAssembly.
Para proporcionar una forma estándar para que los programas WebAssembly se comuniquen con un sistema operativo, nació WASI, la Interfaz del Sistema WebAssembly. WASI se inspiró principalmente en un proyecto llamado CloudABI, que a su vez se inspiró en POSIX. Esto abrió un mundo de oportunidades para que WebAssembly destacara más allá del navegador: los usuarios ahora contaban con todas las propiedades de seguridad y sandbox de WebAssembly, combinadas con APIs inteligentes para acceder a recursos comunes del sistema sin perder por completo las ventajas del sandbox. Naturalmente, nos viene a la mente una tecnología similar: los contenedores. Ninguna discusión sobre este tema se considera completa sin una referencia a una de las publicaciones más profundas y compartidas sobre WASI del cofundador de Docker, Solomon Hykes:
Esa es una afirmación bastante clara. WebAssembly proporciona una forma portátil de empaquetar código que puede ejecutarse de forma segura en cualquier plataforma a velocidades casi nativas, con el beneficio adicional sobre los contenedores de que no es necesario que esté presente ningún sistema operativo. La mayoría de los contenedores que producen los desarrolladores tienen algún tipo de sistema operativo Linux dentro del cual se ejecutan los programas, lo que produce tamaños de contenedores a menudo de cientos de megabytes o varios gigabytes. Los binarios de WebAssembly son código puro, con tamaños a menudo en kilobytes o megabytes de un solo dígito. Parece una locura imaginar un mundo donde en lugar de implementar contenedores en todas partes, los desarrolladores implementen WebAssembly, pero esta realidad ya se está haciendo realidad, con varios proyectos que se desarrollan activamente para ejecutar Wasm en Kubernetes.
WebAssembly del lado del servidor en producción
Varias empresas ya se están beneficiando de Wasm del lado del servidor en producción. Tanto Cloudflare como Fastly cuentan con enormes redes de computación de borde que permiten a los clientes implementar código en todo el mundo, lo más cerca posible de los usuarios. Ambos eligieron estratégicamente WebAssembly para tener binarios pequeños y ultraportátiles con tiempos de inicio rápidos y una sólida capacidad multiusuario. Una empresa emergente, Cosmonic, utiliza redes inteligentes para permitir que los componentes de WebAssembly se comuniquen entre sí sin problemas sin importar dónde se estén ejecutando, ya sea un pequeño dispositivo en la palma de su mano o una máquina que funciona al otro lado del mundo. Otra empresa emergente, Fermyon, utiliza WebAssembly para aumentar masivamente la densidad de carga de trabajo del servidor. El resultado es una reducción drástica de los costos de los servidores y una computación más ecológica para el planeta.
Crecimiento más allá del navegador
En resumen, WebAssembly, aunque inicialmente fue desarrollado para la computación en el navegador, ha seguido mostrando una gran viabilidad fuera del navegador. Su diseño, que soporta varios lenguajes de programación y enfatiza la seguridad, lo convierte en una excelente opción para ejecutar código de forma aislada y lograr portabilidad. La introducción de WASI ha permitido que WebAssembly del lado del servidor florezca, permitiendo a las organizaciones aprovechar Wasm y ofrecer mejores productos al mismo tiempo que son sustancialmente más rentables. El potencial de WebAssembly fuera del navegador no es sólo una idea, sino una realidad creciente para la industria.
Para obtener más información, consulte nuestra publicación de blog anterior, “ Por qué debería interesarle WebAssembly ”.
Además, mira o escucha nuestro podcast “WebAssembly Unleashed” .