WebAssembly, o Wasm para abreviar, ha demostrado una y otra vez ser una tecnología revolucionaria gracias a su rápida velocidad de ejecución, cercana a la nativa, la amplia variedad de lenguajes de programación disponibles y su sólido modelo de aislamiento que deniega el acceso de forma predeterminada. Ya se utiliza de forma generalizada en toda la web y también se ha convertido en un actor destacado en el ámbito de los servidores.
Todo ecosistema emergente necesita una visión de cómo encajan todas las piezas, y ahí es precisamente donde entra en juego el modelo de componentes de WebAssembly. El modelo de componentes es un sistema que facilita las interacciones entre unidades individuales de código WebAssembly, así como entre el código WebAssembly y un entorno anfitrión. Todo gira en torno al concepto de componentes de WebAssembly, que son, en esencia, módulos Wasm convencionales con tipos de datos codificados. Estos tipos permiten generar código de enlace entre bastidores para que los componentes se comuniquen entre sí de forma fluida.
El modelo de componentes inaugura una nueva era en el desarrollo de software moderno: los desarrolladores pueden elegir componentes de cualquier ecosistema de lenguajes de programación y combinarlos en una única aplicación. ¿Tienes una aplicación de procesamiento de datos en Python, pero necesitas un analizador eficiente escrito en Rust? No hay problema. ¿Un equipo de tu organización domina Go, pero otro solo programa en JavaScript? Tampoco hay ningún problema: cada equipo puede crear componentes de WebAssembly que se integren sin complicaciones.
Por qué lo necesitamos desde el punto de vista técnico
WebAssembly se enfrenta a un problema que hemos visto en casi todas las nuevas plataformas de ejecución de código: ¿cómo podemos compartir datos de forma segura y eficiente entre unidades de código independientes, posiblemente generadas por cadenas de herramientas de lenguajes de programación completamente distintos? Por lo general, dos módulos de WebAssembly independientes podrían hacer lo mismo que muchos sistemas y transferirse datos mediante JSON, Protobuf o cualquier otro formato de intercambio de datos ampliamente utilizado. Serializar y deserializar estos formatos resulta bastante costoso y, al fin y al cabo, dado que es probable que los dos módulos que quieren comunicarse se ejecuten en paralelo en el mismo entorno de ejecución, y no a través de una red, esta implementación podría optimizarse.
La dificultad radica en la forma en que cada lenguaje de programación representa los datos. Las implementaciones de los lenguajes pueden optar por utilizar distintas codificaciones para las cadenas de texto, y un lenguaje puede preferir almacenar los datos secuenciales en forma de matriz, mientras que otro puede decantarse por las listas enlazadas. Para que el código escrito en distintos lenguajes pueda comunicarse, estos deben acordar una forma común para todos los tipos de datos. Esto se conoce como interfaz binaria de aplicaciones o ABI. En la práctica, ninguno se pone de acuerdo. Por lo general, si se quiere que un código escrito en un lenguaje se comunique con otro escrito en un lenguaje distinto, algún pobre desarrollador debe sentarse a escribir, con sumo cuidado (y sufrimiento), el código necesario para traducir entre ambos lenguajes. Esto exige un conocimiento profundo del funcionamiento de los dos lenguajes y es extremadamente propenso a errores. Algunos ecosistemas de lenguajes han logrado crear herramientas capaces de hacerlo automáticamente, pero, aun así, solo funcionan con determinados lenguajes.
Afortunadamente, el modelo de componentes define un formato de datos común para todos los lenguajes, conocido como ABI canónica. Para facilitar su uso, también existe un lenguaje de definición de interfaces denominado WebAssembly Interface Types, o WIT, que permite describir las interfaces de los componentes.
El mundo de WIT
Así pues, tenemos todos estos componentes, pero ¿cómo podemos saber dónde podemos utilizarlos? Al fin y al cabo, WebAssembly se ejecuta en multitud de entornos —en navegadores web, servidores, el edge, dispositivos diminutos y muchos más—, cada uno con capacidades diferentes. WIT nos ofrece el concepto de «mundos». Un mundo es la interfaz a la que se ajusta un componente: un conjunto de funciones que el componente puede importar y otro conjunto de funciones que exporta. Esto nos permite razonar con bastante facilidad sobre los componentes y cómo se combinan. Esta es la definición de un componente que pertenece al mundo `wasi:cli/command`, que describe los componentes que se ejecutan en la línea de comandos de un terminal:
Fuente: https://github.com/WebAssembly/wasi-cli, modificado para mayor brevedad
Este componente se ocupa de aspectos como el sistema de archivos y la aleatoriedad, además de disponer de flujos de entrada y salida, pero, sobre todo, proporciona una función que se ejecuta cuando se invoca el comando.
Cualquiera puede definir mundos, pero hay varios mundos en proceso de estandarización para componentes capaces de gestionar solicitudes HTTP, acceder a dispositivos USB, utilizar modelos de IA y muchas otras funciones que están por llegar. Los entornos anfitriones pueden indicar qué mundos implementan para que los desarrolladores sepan fácilmente qué componentes son compatibles. Dado que los componentes se pueden combinar, también es posible implementar unos mundos a partir de otros y combinar ambos componentes. Por ejemplo, si tienes un entorno anfitrión que implementa un mundo de sockets, pero también un componente que quiere realizar solicitudes HTTP en un mundo HTTP, puedes crear un componente adaptador que implemente el mundo HTTP mediante sockets:
¡Con una simple composición, tu componente ya puede ejecutarse en el mundo de los sockets sin ninguna modificación! Las posibilidades son infinitas.
El futuro que nos espera
El modelo de componentes es un avance trascendental, no solo para WebAssembly, sino para todos los desarrolladores del mundo. Cambiará radicalmente la forma en que los desarrolladores conciben y crean software: ya ofrece muchísimas posibilidades y esto no ha hecho más que empezar. Sigue de cerca los avances del ecosistema de WebAssembly, porque sin duda veremos surgir casos de uso cada vez más atractivos a medida que aumente su adopción.
Sobre el autor
Artículos relacionados del blog
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.