Inicialmente el propósito de WebAssembly(wasm) era poder superar varias de las limitaciones de los navegadores, tanto las que dependían del navegador como las que dependían de javascript, que es el único lenguaje que los navegadores interpretan. Sin embargo, poco a poco fue evidente que wasm podía ofrecer mucho más que eso, y se despertó el interés por poder ejecutar código en wasm fuera del navegador. Una de las opciones para lograrlo es Wastime, que será el tema de este post.
Wasmtime es un ambiente de ejecución independiente para WebAssembly(wasm), usa WASI(WebAssembly System Interface) y el Component Model, traducido como Modelo de Componente, creado y mantenido por Bytecode Alliance para ejecutar código compilado en wasm fuera del navegador web, se puede usar desde la línea de comando, o en una de las numerosas bibliotecas que existen para diferentes lenguajes de programación. La idea principal detrás de todo esto es lograr una unificación que permita la intercompatibilidad de los componentes producidos, es decir, que el mismo componente pueda ser usado en diferentes sistemas sin necesidad de ninguna modificación.
Puede parecer sencillo, pero así como existen muchos frameworks que hacen lo mismo pero de maneras un poco diferentes y se adaptan mejor o peor al estilo personal de cada individuo, y existen varios runtimes para javascript, tanto dentro como fuera del navegador; también existen varios entornos de ejecución para wasm, y no todos son compatibles con WASI o el Component Model. Además del entorno de ejecución se necesitan herramientas que permitan debuggear, inspeccionar, y distribuir los componentes, entre otras cosas, y por eso se vuelve importante que el entorno de ejecución cumpla con estándares.
WASI, que son las siglas en inglés de WebAssembly System Interface, y sería traducido libremente como Interfaz del Sistema de WebAssembly, define una interfaz pública de wasm con el ambiente que lo está ejecutando, o dicho de otro modo, provee de un modo seguro y portable la posibilidad de usar funciones del sistema operativo como: sistema de archivos, redes, relojes, y generadores de números aleatorios. WASI permite que la abstracción para comunicarse con el sistema operativo no dependa del software escrito en diferentes lenguajes, y que sea posible interactuar sin la necesidad de complejas interfaces específicas para cada caso y que tradicionalmente necesitaban su propia lógica dentro del proyecto y eran expuestas mediante microservicios HTTP.
WASI soluciona el problema de comunicación con el sistema operativo en el que se ejecuta nuestra aplicación, pero aún queda un problema, cómo hacer que dos componentes probablemente escritos en diferentes sistemas operativos se comuniquen, si alguna vez lo han intentado sabrán lo difícil que era, en parte porque diferentes lenguajes de programación usan diferentes abstracciones para los tipos de datos disponibles para el usuario. Los componentes por seguridad funcionan como módulos, que sirven como ambientes de ejecución aislados, y limitan lo más posible la interacción con el mundo exterior.
El Component Model es un protocolo, en el sentido general de la palabra, destinado a resolver este problema, pues define un modo general de exponer las particulares de cada componente, e implicitamente del lenguaje de programación en el que fue escrito, al mundo exterior, es decir, a otros módulos. Esto hace que diferentes módulos con diferentes abstracciones puedan comunicarse y ser usados en conjunto. En el Component Model las definiciones de tipo se realizan en un lenguaje particular llamado Wasm Interface Type, traducido como Tipo de Interfaz de Wasm, y que comúnmente es referido por sus siglas en inglés WIT. WIT es un lenguaje descriptivo que expresa los imports y exports del módulo de tal modo que puedan, junto con otros módulos formar una aplicación coherente.
Hasta hace poco me parecía confusa la diferencia entre WASI y el Component Model, sabía que eran complementarios pero no entendía los límites de cada uno. Un post que es bastante ligero de leer y me ayudo a entender mejor la diferencia es WebAssembly, WASI, and the Component Model (en inglés), parte del blog de Fermyon.
No es fácil entender a la primera los distintos componentes que forman una aplicación wasm, esto puede resultar intimidante en varios niveles, primero puede hacer que sea complicado empezar a trabajar con aplicaciones wasm, porque hasta ahora, aún usando un framework cierta parte de esta complejidad queda expuesta y contamina el proyecto. Por otro lado, siendo una tecnología bastante reciente, al buscar sobre la tecnología terminan por aparecer todos estos términos que confunden y hacen más difícil definir un punto de inicio. Espero que este post sirva para ayudar a estructurar mejor los distintos componentes de una aplicación wasm para quien se inicia en esto.