¿Qué es el modelo de componentes de WebAssembly?
WebAssembly, o Wasm para abreviar, ha demostrado ser una tecnología revolucionaria una y otra vez, gracias a su rápida velocidad de ejecución casi nativa, su variedad de opciones de lenguaje de programación y su robusto modelo de sandbox de denegación por defecto. Ya ha tenido un uso enorme en toda la web y ha sido un jugador formidable también en el lado del servidor.
Todo ecosistema en crecimiento necesita una visión de cómo encajan todas las piezas, y ahí es exactamente 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 y las interacciones entre el código WebAssembly y un entorno host. Todo se centra en el concepto de componentes WebAssembly, que son esencialmente módulos Wasm normales con tipos de datos codificados. Estos tipos permiten la generación de código de enlace detrás de escena que hace que los componentes se comuniquen entre sí sin problemas.
El Modelo de Componentes marca el comienzo de una nueva era en el desarrollo de software moderno: los desarrolladores pueden seleccionar componentes de cualquier ecosistema de lenguajes de programación y combinarlos en una sola aplicación. ¿Tienes una aplicación de procesamiento de datos en Python, pero necesitas un analizador eficiente de Rust? Ningún problema. ¿Un equipo de su organización es competente en Go pero otro solo escribe JavaScript? No hay problema alguno: cada equipo puede producir componentes WebAssembly que se componen sin problemas.
Por qué lo necesitamos, técnicamente
WebAssembly enfrenta un problema que hemos visto en casi todas las nuevas plataformas de ejecución de código: ¿cómo compartimos de manera segura y eficiente datos entre unidades de código separadas, potencialmente producidas por cadenas de herramientas de lenguajes de programación completamente diferentes? Generalmente, dos módulos WebAssembly separados podrían hacer lo que hacen muchos sistemas y pasar datos entre ellos como JSON, Protobuf o cualquier otro formato prolífico de intercambio de datos. Serializar y deserializar estos formatos es bastante costoso y, después de todo, dado que los dos módulos que quieren comunicarse entre sí probablemente estén siendo ejecutados por el mismo entorno de ejecución uno al lado del otro y no a través de una red, es posible que la implementación de esto sea mejor.
La lucha radica en la forma en que cada lenguaje de programación representa los datos. Las implementaciones del lenguaje pueden optar por utilizar diferentes codificaciones para cadenas, y un lenguaje puede preferir almacenar datos secuenciales como una matriz mientras que otro puede preferir listas enlazadas. Para permitir que los códigos de diferentes lenguajes se comuniquen entre sí, necesitan acordar un formato común para todos los tipos de datos. Esto se conoce como Interfaz Binaria de Aplicação (ABI). En la práctica, ninguna de ellas coincide. Por lo general, si se desea que un código escrito en un lenguaje se comunique con un código escrito en otro lenguaje, algún pobre desarrollador debe sentarse y escribir con cuidado (y con mucho esfuerzo) el código para traducir entre los dos lenguajes. Requiere un conocimiento profundo de cómo funcionan ambos lenguajes y es excepcionalmente propenso a errores. Algunos ecosistemas lingüísticos han logrado producir herramientas que pueden hacer esto automáticamente, pero incluso así, es solo para idiomas selectos.
Afortunadamente, el Modelo de Componentes define un formato de datos común para todos los lenguajes, conocido como ABI canónico . Para facilitar la tarea, también existe un lenguaje de definición de interfaces llamado Tipos de Interfaz WebAssembly (WIT) para describir las interfaces de los componentes.
El mundo de WIT
Entonces, tenemos todos estos componentes, pero ¿cómo podemos saber dónde podemos usarlos? Después de todo, WebAssembly se ejecuta en muchos lugares (en navegadores web, en servidores, en el borde, en dispositivos pequeños y más), todos con diferentes capacidades. WIT nos trae el concepto de mundos . Un mundo es la interfaz a la que se ajusta un componente: es un conjunto de funciones que un componente puede importar y un conjunto de funciones que el componente exporta. Nos permite razonar sobre los componentes y cómo se componen con bastante facilidad. Aquí está la definición de un componente que vive en el mundo `wasi:cli/command`, que describe los componentes que se ejecutan en una línea de comando de terminal:
Fuente: https://github.com/WebAssembly/wasi-cli , modificado para abreviar
Este componente se preocupa por cuestiones como el sistema de archivos y la aleatoriedad y, al mismo tiempo, tiene flujos de entrada y salida, pero, lo que es más importante, proporciona una función para ejecutar cuando se invoca el comando.
Cualquiera puede definir mundos, pero hay una serie de mundos estándar para componentes que pueden manejar solicitudes HTTP, acceder a dispositivos USB, usar modelos de IA y muchos más por venir. Los entornos de host pueden anunciar qué mundos implementan para que a los desarrolladores les resulte más fácil saber qué componentes funcionan. Dado que los componentes son componibles, también es posible implementar algunos mundos en términos de otros mundos y componer los dos componentes. Por ejemplo, si tiene un entorno de host que implementa un mundo de sockets, pero tiene un componente que desea realizar solicitudes HTTP en un mundo HTTP, puede escribir un componente adaptador que implemente el mundo HTTP usando sockets:
¡Con una composición simple, su componente ahora puede ejecutarse en el mundo de los sockets sin modificaciones! Las posibilidades son infinitas.
El futuro que nos espera
El modelo de componentes es monumental, no sólo para WebAssembly, sino para todos los desarrolladores en todas partes. Esto cambiará fundamentalmente la forma en que los desarrolladores razonan sobre el software y lo desarrollan: ya tiene muchísima utilidad y aún es pronto para empezar. Manténgase atento a los desarrollos que suceden en el ecosistema WebAssembly, ya que estamos seguros de que veremos surgir cada vez más casos de uso atractivos a medida que la adopción continúa aumentando.