Utilizando WebAssembly para dar vida a tutoriales de línea de comandos

Gracias a todos por estar aquí. Estoy muy emocionado de compartir con ustedes parte de mi experiencia utilizando WebAssembly para impulsar tutoriales en la línea de comandos. Soy Robert, cofundador de OM Genomics Labs. Construimos herramientas de software para científicos genómicos. Uno de los problemas que encontramos en la educación de la bioinformática es que, ya sea que estés haciendo tutoriales basados en texto, videos o incluso en persona, hay algunos desafíos que son relativamente específicos de la bioinformática. Uno de ellos es que es muy difícil configurar tu entorno. Y esto es especialmente cierto en la bioinformática, donde muchas de las herramientas tienen dependencias extrañas. Algunas de ellas incluso pueden no proporcionarte binarios para descargar, y tienes que compilar todo desde el código fuente, lo cual es interesante. Y así, es muy difícil para las personas comenzar, pero también es muy aterrador. Si estás definiendo una variable en un tutorial y luego quieres eliminar esa variable y cometes un error, terminas eliminando todos tus datos y no se puede revertir. Y eso es un problema porque la exploración es típicamente la forma en que la mayoría de las personas aprenden, desviándose del tutorial y probando diferentes valores para diferentes parámetros y viendo a dónde los lleva eso. Y en mi opinión, muchas de las soluciones existentes no funcionan. Entonces, típicamente lo que se hace es, digamos al comienzo de un taller, puedes pasar algún tiempo mostrando a los estudiantes cómo instalar dependencias en su máquina local o iniciar máquinas virtuales para instalar las dependencias en un entorno limpio. Y el problema es que se pasa mucho tiempo ya sea en un taller o antes del taller haciendo la configuración. Y especialmente para los científicos, que lo único que quieren hacer es usar las herramientas de línea de comandos. No quieren aprender cómo iniciar máquinas virtuales, configurar infraestructura en la nube. Es mucho tiempo para dedicar a estas cosas. Y aquí es donde entra en juego Sandbox Bio. Esta es una herramienta gratuita que muestra tutoriales de bioinformática. Y aquí estoy mostrando un tutorial no relacionado con la bioinformática solo para que puedas ver algo familiar. A la izquierda está el contenido del tutorial y a la derecha hay una interfaz de línea de comandos integrada. Puedes escribir tus comandos allí y se ejecutarán y no se requiere configuración ni instalación. Todo sucede en el navegador. Entonces, ¿cómo implementar algo así? La forma en que la mayoría de los sitios web de tutoriales funcionan es utilizando contenedores o algún formato similar, donde un nuevo usuario llega al sitio, se inicia un nuevo contenedor pequeño, se le aplican límites y se le permite enviar comandos arbitrarios. Se ejecutan, se muestra el resultado y una vez que no han estado activos durante un tiempo, se apaga el contenedor. Y eso funciona. El problema es que es muy costoso, especialmente si quieres hacer un sitio web de tutoriales gratuito. Casi nunca funciona. Muchos de los sitios web que han utilizado este enfoque en el pasado simplemente limitan cada vez más su nivel gratuito o dejan de ofrecerlo por completo. Y ahí es donde WebAssembly es realmente interesante.

Pero también existe la idea de que puedes ejecutarlo, ya sabes, en el servidor y en dispositivos más pequeños. Y aunque eso es posible, si realmente quieres hacerlo o no es otra cosa que o no es otra pregunta. Hablaremos más sobre eso hacia el final.

También quería ser un poco más práctico aquí acerca de cómo se ve la compilación de algo a WebAssembly, porque se habla mucho de WebAssembly, pero siento que una vez que ves cómo se ve, tienes una mejor idea de lo que significa. Entonces, si tienes un programa en C o C++, típicamente estas son las herramientas que estás utilizando para compilar el código a un programa binario. Y hay un conjunto de herramientas llamado Emscripten, que te ayuda a hacer esta compilación a WebAssembly mucho más fácil de lo que sería de otra manera y te brinda muchas herramientas realmente poderosas. Y te proporcionan envoltorios alrededor de estas herramientas para que puedas compilar cosas a WebAssembly.

Entonces aquí tienes una herramienta simple de bioinformática escrita en C. Si lo compilas a binario, puedes usar GCC y listo. Si quieres compilarlo a WebAssembly, puedes usar el compilador C de Emscripten. Y esto te dará la capacidad de generar un archivo JavaScript, que contendrá algo de código de enlace para ayudarte a administrar el archivo WebAssembly que también genera.

Y entonces, ¿cómo ejecutarías estas cosas? Bueno, en el lado del binario, lo ejecutas en la línea de comandos con los parámetros que deseas. Y en el lado de WebAssembly, Emscripten te proporciona algunas utilidades para, por ejemplo, llamar a la función principal con los mismos parámetros que en la línea de comandos. Pero el problema con WebAssembly es que no siempre es tan fácil. Este fue un ejemplo muy simple, pero digamos que quieres compilar grep a WebAssembly, entonces se ve un poco como un desastre. Y ninguna de estas modificaciones y banderas que tuve que ajustar es realmente intuitiva. Es solo que estás tratando de compilar algo que no fue hecho para WebAssembly. Y hay muchas cosas que WebAssembly no admite y que tienes que ajustar o eliminar en el código original. Y eso es cómo termina viéndose. Hablando de eso, porque seguía encontrando este problema, terminé escribiendo un libro al respecto, describiendo mi experiencia con eso y cómo suelo abordar la compilación de cosas a WebAssembly. Y volviendo a sandbox.bio. Sandbox.bio utiliza WebAssembly para proporcionar esta terminal en el navegador. Y la forma en que funciona es que tienes esta terminal que está alimentada por xtermjs, por lo que simula una línea de comandos. Pero, por supuesto, no realiza ninguna evaluación, por lo que debes tomar la entrada del usuario y... Lo siento. Entonces debes tomar la entrada del usuario, insertarla en un árbol de sintaxis abstracta y luego decidir el orden en el que aplicas los comandos. En este caso, tienes un pipe. Entonces esto ejecutará awk y enviará el resultado a head, y por lo tanto te dará la salida. Lo realmente bueno de ejecutar todo en el navegador es que es muy fácil almacenar el estado del sistema de archivos, al menos temporalmente, en indexedb. Y eso sería mucho más difícil si estuvieras utilizando el enfoque de contenedores, donde por cada usuario debes crear un contenedor. Cuando lo apagas, tendrías que tomar una instantánea del estado y guardarlo en tu cubo de cloud, por ejemplo. Por lo tanto, sería aún más costoso para ti proporcionar eso. Mientras que en el navegador, es muy fácil de hacer. Y lo que acabo de describir, eso es sandbox.bio.v1, donde cada herramienta que quería admitir en el tutorial se compiló a WebAssembly. Pero no quería compilar Bash a WebAssembly, porque eso era muy pesado. Así que terminé compilando algunas herramientas individuales, pero tuve que hacer alguna simulación. ¿Cómo manejo la tubería? ¿O ejecutar trabajos en segundo plano? ¿O variables? Cosas como esas tuvieron que ser simuladas.

Entonces, no admitía todas las comodidades de Bash. Entonces, sandbox.bio.v2, que lanzamos a principios de este año, adopta un enfoque un poco diferente. Ejecuta todo el sistema operativo Debian en el navegador. Y lo hace utilizando una herramienta llamada v86. Esencialmente, es un emulador de CPU, escrito en Rust, y se compila a WebAssembly. Ahora no estás compilando las herramientas individuales a WebAssembly, estás compilando el emulador. Y luego, además de eso, lo que hacemos es, ya sabes, definimos un Dockerfile que tiene todas las herramientas de bioinformática que queremos. Y luego podemos usar v86 para tener esas herramientas disponibles en el navegador. En cuanto a las limitaciones, debido a que estás ejecutando esto en el navegador, solo puedes usar cuatro gigabytes de RAM. Y esta es una limitación de WebAssembly. Por lo tanto, se está trabajando en una versión de 64 bits de WebAssembly, que tendrá muchas más capacidades de RAM. Pero eso no es un problema demasiado grande para los sitios web de tutoriales, donde normalmente no se ejecutan análisis reales. Otra gran limitación es que v86 actualmente solo admite una arquitectura de 32 bits. Por lo tanto, hubo algunas herramientas que requieren una arquitectura de 64 bits que no pudimos obtener en el sandbox, pero la mayoría de las herramientas pudimos obtenerlas. Por lo tanto, fue una mejora bastante grande para la versión 2, donde no tuvimos que pasar tanto tiempo tratando de averiguar cómo compilar cada herramienta a WebAssembly. Y la última limitación es que los tutoriales deben utilizar archivos pequeños. Y esto se debe a que, ya sabes, estás utilizando WebAssembly, y además hay un emulador. Hay muchas capas aquí. Y al utilizar archivos pequeños, te aseguras de que no sea demasiado lento ejecutar Linux en el navegador. Y eso también está bien para los sitios web de tutoriales, porque el objetivo es mostrar cómo se haría algo. No es ejecutar un análisis en tus datos reales.

Entonces, pocos cálculos. El mejor ejemplo de eso es si estás utilizando una biblioteca que te permite diseñar tu interfaz de usuario en Rust y se compila a WebAssembly. Mira, lo entiendo. Eso es muy genial, pero no es realmente práctico. Terminas incrustando mucho HTML y JavaScript extraño en esto, y no está claro cuál es el beneficio. Tu aplicación definitivamente no será más rápida. Quiero decir, si tu interfaz de usuario es tan lenta, debes replantear lo que estás haciendo. Y lo que podrías hacer es analizar solo las partes lentas y reemplazarlas con WebAssembly en lugar de usar WebAssembly para toda la aplicación, lo cual tiene menos sentido. Porque también habrá mucha sobrecarga, especialmente mental, mientras intentas descubrir cómo compilar estas cosas a WebAssembly. Y también, probablemente, otras personas en tu equipo que usan JavaScript no saben cómo usar Rust. Eso es una sobrecarga adicional que no creo que realmente valga la pena. Pero es genial, así que te lo concedo.

Por otro lado, en el extremo opuesto está el exceso de cálculos. Si estás utilizando más de cuatro gigabytes de RAM, por ejemplo, o si necesitas que algo se ejecute al 100% de la CPU durante minutos o incluso segundos, es posible que desees replantear si esa es la experiencia de usuario correcta que deseas brindar. Y tal vez tenga sentido ejecutar esta tarea en la nube.

Por otro lado, lo que he encontrado como el punto óptimo es cuando haces cosas como playgrounds, como lo hace Sandbox Bio, simulaciones a pequeña escala, procesamiento de audio y video, y preprocesamiento de carga. Y esto es algo que he utilizado varias veces, donde si le pides a los usuarios que carguen conjuntos de datos muy grandes, mientras se carga los datos, puedes realizar algunas verificaciones de integridad en los datos. Y esto también se puede hacer en JavaScript, pero en mi caso, muchas de las herramientas para realizar estas verificaciones de integridad estaban escritas en C para bioinformática, por lo que básicamente las llevé a la web con WebAssembly. Pero en general, en mi opinión, WebAssembly es realmente mejor para reutilizar código existente que no está escrito en JavaScript y que deseas llevar a la web, o simplemente agregarlo para obtener mejoras aquí y allá. Es cuando encontré que es más poderoso. Y también vale la pena decir que WebAssembly no es la herramienta que todos los desarrolladores deberían usar. Solo tiene sentido en algunos casos específicos, y si no tiene sentido para tu caso de uso, simplemente diría que no te molestes. Es una tecnología de nicho, eso es seguro. Otra razón por la que no usaría WebAssembly es tratar de reemplazar los contenedores. Y si observas lo que está sucediendo en el mundo de WebAssembly en este momento, verás mucha emoción sobre el uso de WebAssembly fuera del navegador. En algunos casos, algunas personas dirán que WebAssembly va a destruir los contenedores de Docker, lo cual honestamente me confunde un poco.

Cuando estás en el navegador, realmente no tienes opción, ¿verdad? Puedes usar JavaScript o puedes usar WebAssembly. Esas son todas las opciones que tienes. Eso no es cierto en el servidor. Puedes usar cualquier lenguaje que desees en el servidor, a diferencia del navegador. Puedes ejecutarlo en metal desnudo en una VM. Puedes ejecutarlo en funciones serverless. Puedes ejecutarlo en un clúster Kubernetes. Puedes ejecutarlo en tu Macbook si realmente quieres. El punto es que tienes tantas opciones en el servidor que la pregunta entonces es, ¿por qué WebAssembly sería la solución correcta? Y creo que en la mayoría de los casos, probablemente no lo sea. Hay algunos casos en los que podría tener sentido. Por ejemplo, si estás tratando de ejecutar código arbitrario que el usuario te proporciona, si tienes una arquitectura de complementos donde los usuarios pueden darte JavaScript para ampliar tu aplicación en el backend, WebAssembly es genial para eso porque es un sandbox. Es muy limitado en lo que puedes hacer allí. Y creo que eso podría tener sentido. Pero probablemente eso no es lo que la mayoría de los desarrolladores necesitan hacer de todos modos, pero es una buena aplicación. También los encontré útiles en funciones serverless. Si quieres ejecutar código en un lenguaje que aún no es compatible, por ejemplo, eso podría ser una buena aplicación allí. Y si quieres escuchar más de mis pensamientos sobre WebAssembly en el servidor, puedes consultar el podcast ChangeLog, episodio 570. Bien, eso es todo lo que tenía hoy. Si encontraste esto útil, puedes consultar mi libro en levelupwasm.com. Me gusta adoptar un enfoque práctico para WebAssembly, así que te diré cuándo es útil y cuándo debes evitar usarlo. Y si estás interesado, tengo un montón de artículos y videos gratuitos de charlas anteriores que también puedes ver. Muy bien, muchas gracias.