No lo intentes en casa: E/S síncrona en Node.js

Hola a todos. Soy Anna y voy a hablar un poco sobre la IO síncrona en Node.js. Antes de comenzar, ¿quién soy yo? Soy Anna, mis pronombres son ella, ella. Anteriormente formé parte del Comité de Dirección Técnica de Node.js, así que me pagaban a tiempo completo para trabajar en el núcleo de Node.js. En septiembre, me uní al equipo de MongoDB, al equipo de herramientas de desarrollo. Y mi nombre de usuario, si tienen alguna pregunta o quieren contactarme de alguna otra manera, es addalex en Twitter y GitHub, al menos. Y también soy la mamá de estos dos pequeñitos adorables.

Pero, sí, tratemos de recordar, como, el subtítulo de esta charla es no intentes esto en casa. Y, como, ¿por qué no queremos hacer IO síncrona en Node.js? Estoy bastante seguro de que has escuchado que no deberías, pero ¿por qué? Así que aquí tienes lado a lado. En el lado izquierdo tienes la forma clásica síncrona de cargar, de hacer IO, de cargar un archivo desde el disco. En el lado derecho, tienes una forma asíncrona, y en este caso, también podrías decir que es más moderna porque es asíncrona. Al final, estas dos dan el mismo resultado. Y, bueno, ¿por qué no queremos el lado izquierdo? ¿Por qué no queremos que la gente haga lo que está en el lado izquierdo? La razón es el rendimiento. Y antes de entrar en detalles sobre eso, así que, como, si haces una prueba de referencia de fs.refi, intenté hacer eso para esta charla. Lo que esperaría que suceda es que la versión síncrona sea ligeramente más rápida que la versión asíncrona si solo haces una sola llamada porque la versión síncrona solo tiene que ir y leer el archivo y devolver los resultados. Y la versión asíncrona, en realidad tiene que programar eso y luego esperar a que los resultados regresen. Así que, esperaría que la versión asíncrona sea un poco más rápida que la versión síncrona. En primer lugar, al principio eso era cierto, pero eso fue, como, mucho más rápido que en realidad descubrí un error en fs.promises.refi que afectaba el rendimiento. Y después de solucionar eso, no sé, la versión asíncrona es más rápida por alguna razón. Si quieres, siéntete libre de investigar esto y decirme qué está pasando. Pero, sí, en general, eso es lo que esperaría. Pero de todos modos, la gran ventaja es que pueden ocurrir múltiples cosas al mismo tiempo. Esa es la idea general de Node.js. Puedes hacer algo, hacer algo más y esperar a que estas dos cosas sucedan antes de continuar. Y otras cosas también pueden suceder mientras esas operaciones están en curso. Con la forma síncrona, todo sucede uno tras otro. Y mientras tu proceso hace esta carga de archivos, no puede suceder nada más. No JavaScript, no otra IO, nada.

Pero sí, existen excepciones a cuando está bien hacer esto. No deberías. Pero en algunos casos. Entonces, la carga de código requerido y, hasta donde sé, también la importación de ESM, realizan IO síncrona en el sistema de archivos. Para ESM, eso no es algo técnicamente necesario. Y espero que podamos prescindir de eso en algún momento. Pero sí, porque la carga de ESM es asíncrona de todos modos y no necesariamente notarías si el sistema de archivos estuviera ocurriendo de forma asíncrona.

El segundo caso es cuando sabes absolutamente que lo que estás haciendo es lo correcto. Por ejemplo, estás escribiendo una aplicación de línea de comandos donde hay un conjunto muy limitado de cosas que suceden al mismo tiempo y sabes que no está ocurriendo nada más al mismo tiempo. Aún así, te animaría a escribir código asíncrono. Simplemente porque debes seguir esa mejor práctica, incluso si no es estrictamente necesario. Y el tercer caso es cuando necesitas código síncrono por alguna razón. Y eso puede ser porque alguna API o alguna interfaz de usuario expone tu código como síncrono y no tienes otra opción. Y voy a hablar sobre ese último caso aquí. ¿Qué hago actualmente en mi trabajo estos días?

Si alguna vez has trabajado con MongoDB, esto puede parecer un poco familiar. Existe una utilidad de línea de comandos de Mongo donde puedes pasar algo que se parece a una URL y decir, `conéctate a este servidor. Conéctate a esta base de datos`. Y luego obtienes una consola donde puedes ejecutar comandos como en este caso, db.test.find. No importa realmente para el ejemplo que esto sea MongoDB. Esto bien podría ser el cliente de MySQL y el comando podría ser select asterisco from test, básicamente lo mismo.

Entonces, el proyecto en el que estoy trabajando actualmente es en realidad reescribir esto, se llama Mongosh, dependiendo de cómo te guste pronunciarlo. Hace prácticamente lo mismo. Pasas algo similar a una URL y puedes obtener una consola y ejecutar el mismo tipo de comando allí. ¿Por qué estamos haciendo esto? Entonces, Mongo, la antigua consola es básicamente a lo que me he acostumbrado a llamarla. Es una aplicación C++ basada en Spider Monkey, por lo que es una aplicación C++ que utiliza el motor JavaScript de Firefox para ejecutar JavaScript desde la consola. Entonces, lo que estamos escribiendo, esta cosa llamada Mongosh, lo siento por eso, es una aplicación de Node.js. En primer lugar, las aplicaciones JavaScript son un poco más fáciles de mantener. Es simplemente un lenguaje de más alto nivel que C++, por mucho que me guste C++. Node.js ya tiene una gran representación en la que podemos construir, pero no tenemos que escribir todo esto de nuevo. E incluso podemos incrustarlo en aplicaciones Electron y tal vez en páginas web en algún momento.

En realidad, estamos haciendo eso primero. Hay una interfaz gráfica de usuario para MongoDB, que se llama Compass, que también es mantenida por nuestro equipo, y la incrustamos en una aplicación de Electron como un componente de React, lo cual es bastante genial. Pero sí, esta antigua consola, la forma en que funciona es que escribes algún comando como db.test.find, y realiza la IO de forma síncrona, porque no hay un bucle de eventos, nada, no hay Node.js involucrado. No hay razón para hacer algo asíncrono. Pero estamos construyendo sobre el controlador de Node.js. El controlador solo realiza IO de red. No tienes IO de red síncrona en Node. Simplemente no está ahí. Y eso fue complicado porque las personas no deberían tener que saber sobre async/await para poder usar nuestra consola. Las personas han escrito scripts para la antigua consola que idealmente queremos que sigan funcionando tanto como sea posible. Entonces, la pregunta es, ¿cómo hacemos que este método haga algo de forma síncrona? Eso es lo que me inspiró a dar esta charla. ¿Cuáles son los diferentes enfoques que podríamos tomar aquí?

Primero que nada, está la forma fácil de hacer IO síncrona en Node, que son los métodos síncronos. Simplemente están allí. Están en la API. Tienes FS que hace referencia a operaciones de archivo síncronas. Obviamente, no resuelve nuestro caso de uso aquí. Porque no cubre la IO de red. Y eso es lo que nos preocupa principalmente aquí. Así que eso es algo que no es viable para nosotros. Y también, si me preguntas, y esto es solo mi opinión personal, el hecho de que esto sea posible, que estas operaciones como readFileSync y operaciones similares estén allí, no hay una buena razón por la cual FileSystem.io en libuv en la biblioteca subyacente que soporta a Node esté implementado de la forma en que está. No hay una buena razón por la cual no debería funcionar de la misma manera que el acceso a la red o a los flujos de E/S estándar o cualquier otra cosa. Creo que eso es un defecto de diseño y no deberíamos poder tener estas cosas en primer lugar. Obviamente, no van a desaparecer porque millones de personas las están usando. Pero sí.

Entonces, luego... y esto es algo en lo que probablemente no pensarías al intentar hacer IO síncrona en Node... Lo que puedes hacer es escribir código en C, Rust o C++ y compilarlo a Wasm. Básicamente, cualquier cosa que sea compatible con Clang funcionaría aquí.

Y luego puedes usar WASI, que es la Interfaz del Sistema de Web Assembly, que es soportada por Node.js, y usar eso para ejecutar ese código. Y cómo se ve eso en la práctica, entonces, en el lado izquierdo hay un archivo C. No importa realmente lo que hace, pero hay muchas llamadas que comienzan con F, lo que significa file.io. En el lado derecho, tienes el correspondiente JavaScript. Puedes crear estos objetos WASI. En Node.js, son experimentales, y necesitas pasar una bandera para que funcionen, pero están ahí y son soportados. Y usando estos pasos, puedes ejecutar este código en el lado izquierdo, y funcionará completamente de forma síncrona. Creo que esto es algo muy genial de tener, pero también es muy experimental, y actualmente no es muy útil para escribir JavaScript porque si quieres usar esto desde JavaScript, tendrías que actuar como una aplicación WebAssembly, lo que significa serializar todo lo que quieres pasar a una llamada en un búfer de arrays y enrutándolo de vuelta después. Y simplemente no es ergonómico en absoluto. Esto no es algo que queramos hacer. Pero hasta donde sé,

Y ahora, lleguemos a las formas que personalmente me emocionan más. Esto es probablemente mi favorito, porque en este punto está casi listo para producción y tal vez realmente podamos usarlo en el futuro.

¿Qué hacemos? Mezclamos workers con atomics y la razón por la que esto es el símbolo nuclear y no el emoji de átomo es que todos habrían pensado en React.

¿Cómo funciona esto? Veamos un ejemplo. Nuevamente, este es código que se puede ejecutar. El lado izquierdo, el lado del hilo principal, no tiene algunas importaciones. Pero básicamente funciona. Lo que hace el hilo principal, cuando se inicia, es crear un canal de mensajes y un búfer de matriz compartida. Y necesita un búfer de matriz compartida. Llegaremos a eso en un momento. Y luego inicia un worker al que le pasa un lado del canal de comunicación y ese búfer compartido de matriz. Y luego, espera en ese búfer de matriz compartida utilizando atomics.wait. Y en el worker eso sucede cuando se inicia. Bueno, obtiene los data que le envió el hilo principal. Y ejecuta una función asíncrona. Y eso es algo que ya te resulta muy familiar. Probablemente la mayoría de ustedes haya visto NodeFetch en algún momento. Es una API muy buena para cargar solicitudes HTTP. Y también es muy buena para estos ejemplos porque es muy sencillo hacer IO con ella. Aquí son solo tres líneas de código. Entonces, lo que sucede es que lo cargamos. Usamos una forma de buscarlo. Una forma de esperar a que se devuelva todo el cuerpo de la respuesta a nosotros. Obviamente, esto no incluye el manejo de errores. Pero ya sabes, no se hace eso en diapositivas como estas donde el espacio es limitado. Y luego, después de obtener esa respuesta, la enviamos de vuelta al hilo principal y usamos atomic cert notify. Es memoria compartida entre el hilo principal y el hilo del worker. Esto en realidad despierta esa llamada de espera que ocurrió en el hilo principal, que estaba bloqueada. Entonces, nada más progresó en el hilo principal. Todavía estaba esperando en esa línea a que alguien llamara a atomic cert notify en otro hilo.

Y luego, en el hilo principal, revisamos lo que obtuvimos, usamos el mensaje recibido de la API de terceros, que es específico de Node.Jet. Puedes emularlo en la web, pero es un poco más conveniente de esta manera. Y luego mostramos la respuesta.

Esta idea general, creo que es bastante genial. Te permite hacer cosas de forma síncrona si realmente lo necesitas. Y tiene algunas ventajas. Entonces, nuevamente, así es como se ve esquemáticamente. El hilo principal se bloquea y no avanza. No vuelve a su propio bucle de eventos. Simplemente crea un hilo de worker, permite que ese bucle se ejecute y luego espera a que esa respuesta regrese antes de avanzar de alguna manera. Y las grandes ventajas de Node.js son que puedes usar la API completa de Node.js y los paquetes NPM en el worker. Las pequeñas desventajas son que Atomics.wait no está permitido en los hilos principales de los navegadores. Porque si lo estuviera, se vería. Atomics.wait es una llamada de bloqueo que no permite que nada progrese en el hilo principal. Entonces, bloquearía el renderizado, por ejemplo, indefinidamente, lo cual no es algo que debería permitir una página web. Y aún no nos da completamente lo que necesitamos, porque no permite manipular objetos dentro del worker. Entonces, si piensas en el ejemplo de fetch, si hubiéramos querido, por ejemplo, agregar un event listener al objeto de respuesta que vimos allí, no podríamos haberlo hecho fácilmente, porque no hay forma de acceder a estos objetos dentro del worker. Entonces, tendría que haber algún tipo de protocolo RPC que se encargue de eso. Y sí. Generalmente no es muy ergonómico de esa manera. Pero es muy genial. Muy listo para producción. No hubo nada experimental en lo que mostré. Y podrías usar esto, por ejemplo, dentro de un hilo de worker. Entonces, Atomic funciona dentro de los hilos de worker dentro del navegador.

Entonces, la idea es en lugar de tener hilos separados, el bucle de eventos del hilo principal sigue funcionando. Nos da su devolución de llamada. Y dentro de la devolución de llamada o durante el código de inicio, iniciamos un nuevo bucle de eventos, una nueva instancia de Node.js con su propio bucle de eventos en el mismo hilo. Y hasta que hayamos terminado con eso, nada más en el hilo principal avanza. Así que, se me ocurrió, es una pandemia. Estaba un poco aburrido durante las vacaciones. Así que, este es un proyecto que se me ocurrió. Y la idea es, esto es todo lo que necesitas para lograr lo que queremos. Así que creas un trabajador síncrono. Eso es lo que lo llamo porque es como un trabajador en el sentido de que inicia una nueva instancia de Node.js, pero también es como sin multihilo involucrado. Es síncrono.

Entonces, puedes crear una función require dentro de ese node fetch, dentro de ese trabajador que carga node fetch. Y luego tienes algo, tienes una función fetch que solo se ejecuta dentro del trabajador. Y luego puedes hacer cosas geniales como worker.runLoopUntilPromiseResolved y pasarle una promesa que se creó dentro de este trabajador. Puedes hacer eso dos veces para obtener el texto completo y puedes imprimirlo. Y esto también es, nuevamente, un ejemplo ejecutable.

Hay algunas desventajas. Entonces, es como esto es solo Node.js. Actualmente se implementa como un complemento nativo. Entonces, los navegadores no admiten esto. Y creo que si alguna vez quisieran admitir eso, pasarían años hasta que realmente lo lograran. También es solo Node.js 15.5 y superior porque hubo algunas correcciones de errores que necesitábamos implementar en Node.js en primer lugar. Deberías considerar varias cosas, siéntete libre y siéntete animado a probar algunas cosas con esto, pero probablemente sea muy fácil hacer que el proceso se bloquee al usarlo. Pero obtienes la API completa de Node.js, al igual que en los trabajadores, obtienes un control completo del bucle de eventos y puedes acceder a los objetos JavaScript como cualquier otro objeto JavaScript. Creo que eso es bastante genial. Si te lo estabas preguntando, ninguno de estos métodos realmente funciona para el borde de Mongo porque todos tienen inconvenientes, como viste. Lo que realmente hacemos actualmente es, si recibimos una entrada como esta, donde alguien intenta usar el resultado de una llamada asíncrona de forma sincrónica, lo que hacemos es usar Babel para transpilarlo a código asíncrono y eso funciona lo suficientemente bien para nosotros. También tiene algunas desventajas, como que funciona de la mejor manera posible, estamos usando un peso en lugares donde creemos que debería aplicarse y algunas características del lenguaje no son compatibles, pero en general, esto funciona lo suficientemente bien para nosotros en la actualidad. Gracias por escuchar. Subiré las diapositivas pronto y si tienes alguna pregunta o quieres contactarme en algún momento en el futuro, puedes enviarme un mensaje en Twitter. Gracias. Eso es todo. Hola, hola, ¿cómo estás? Estoy bien. Estoy bien. Estamos muy contentos de que te hayas unido a nosotros. Muchas gracias. ¿Qué opinas de los resultados de la encuesta? Honestamente, tengo que pensarlo un poco porque tengo que repasar en mi cabeza para entender exactamente qué significa el sí y el no. Parece que al menos la mayoría de las personas están usando TypeScript y están muy contentas con eso. Sí, noté que la mayoría de las personas están básicamente contentas con lo que están usando. Pero también tenía curiosidad porque sé que a veces las personas tienen opiniones muy fuertes al respecto y no sé, quería tener una idea de lo que realmente piensan las personas.

Interesante, interesante. Veamos algunas de las preguntas para ti. Alguien preguntó, ¿qué optimizaciones hiciste para... oh, ¿qué optimizaciones hiciste para leer archivos SS en Node.js mientras te preparabas para la charla? Correcto. Así que, puedo... puedo compartir... Voy a compartir el enlace en el canal de preguntas y respuestas en Discord, pero básicamente, por alguna razón, la implementación promises.readfile en Node lee archivos en pequeños fragmentos de 16 kilobytes. No había una razón real para hacer eso. Especialmente porque obtenía el tamaño del archivo primero. Y cuando sabes que vas a leer el archivo completo, es mejor asignar un búfer grande que sea lo suficientemente grande para contenerlo en lugar de leer pequeños fragmentos una y otra vez. Y así, eso mejora mucho el rendimiento, simplemente cambiando eso. Eso es genial. ¿Puedes hablar... en tu biografía mencionaste que has sido uno de los principales contribuyentes a NodeJS en los últimos cuatro años. ¿Puedes hablar un poco sobre esa experiencia?