El Camino hacia Async Context

Buenos días, ¿cómo están todos? Cuando me invitaron a subir y salir a hablar, estaba pensando en, ya sabes, ¿sobre qué quiero hablar? Sabes, había, sabes, podríamos hablar sobre Node en general, qué está pasando en el proyecto. Y solo quería hablar sobre código.

Entonces, sabes, quiero hablar sobre parte del código que hemos estado escribiendo recientemente, en el que hemos estado trabajando no solo en Node, sino también en Cloudflare Workers y la API de almacenamiento local asíncrono. Si no estás familiarizado con ella, es una de las, ha estado en Node durante un par de años, pero es una de las que no es realmente conocida en términos de lo que hace, cómo funciona. Y una de las cosas que, ya sabes, a medida que comenzamos a trabajar en esto en Workers recientemente como parte de nuestra historia de compatibilidad con Node, intentamos averiguar, ya sabes, cómo se implementa, cómo es el rendimiento de ella y cómo está escrita? ¿Es lo que debería ser? Bien.

Entonces, en Workers, decidimos tomar un enfoque de diseño diferente a cómo funciona debajo de la cubierta y quiero hablar sobre las diferencias entre cómo funciona en Node, cómo funciona en Workers, y hacia dónde van las cosas. Ahora, ya sabes, ese título original de la charla, el Camino al Contexto Asíncrono. El contexto asíncrono es en realidad una nueva API estándar propuesta que cubre el mismo caso de uso que el almacenamiento local asíncrono pero en realidad se va a agregar al lenguaje en sí. Y hablaré un poco sobre eso aquí al final. Entonces, un poco más para mí, como, ya sabes, para aquellos de ustedes que no me conocen he estado involucrado con Node durante varios años. También estoy contribuyendo a CloudFlare Workers. De hecho, estoy en el equipo de tiempo de ejecución de Workers en CloudFlare. No voy a hablar demasiado sobre Workers en sí. Mi colega Matt Alonzo está aquí. Va a mostrar algunos bits y algunos detalles más específicos de Workers. Si estás interesado en eso, te recomiendo que vayas a su charla más tarde. Bien, entonces, comencemos. ¿Qué es el almacenamiento local asíncrono? La documentación de Node nos da esta definición muy útil. Crea una tienda que permanece coherente a través de operaciones asíncronas. Eso es básicamente. Y luego te da un ejemplo. Es una explicación extremadamente inútil de lo que es. Así que vamos a desglosarlo un poco más. Bien, entonces tenemos esta noción de lo que se llama un contexto de ejecución. Esto es cualquier código que se está ejecutando en este momento. Ese contexto de ejecución puede programar una continuación. La continuación es cualquier código que está programado para ejecutarse más tarde. Piensa en un temporizador, o una promesa. Cada vez que adjuntas un then, un catch, un finally a él. Callbacks.

Entonces, cuando estás llamando a la API de FS y esa devolución de llamada asíncrona se ejecuta más tarde. Ya sabes, la continuación es una especie de término genérico para esas cosas que están programadas para ejecutarse más tarde. ¿De acuerdo? Bien. Entonces, mientras se está ejecutando el contexto de ejecución, puede programar cualquier número de estas cosas, ¿verdad? Ya sabes, si estás usando QMicroTask, o promesas, o devoluciones de llamada, o process next take. Todas estas cosas son cosas que el código actual, el código que se está ejecutando puede programar para ejecutar, ya sabes, ya sea solo unos momentos a partir de ahora, más tarde, ya sabes, en algún momento más tarde en la aplicación. Lo que sea. Pero estas cosas pueden acumularse.

El almacenamiento local asíncrono se trata de poder asociar datos contextuales con la programación de esa continuación, ¿verdad? Entonces, cuando se está ejecutando el contexto de ejecución actual, queremos poder establecer un valor de contexto. Y luego, cuando esa función realmente se ejecute más tarde, queremos poder recuperar ese mismo valor exacto, ¿verdad?

Un ejemplo hace que esto sea mucho más fácil de ver. Muy bien. Entonces, en este caso particular, lo que queremos, esta función de registro en la parte superior es nuestro caso de uso. Lo que queremos es poder registrar algo en la console que tenga un identificador de solicitud único. ¿De acuerdo? Entonces, imagina que esto es un servidor. Cada vez que llega una solicitud, queremos crear un ID único para esa solicitud. Y cada vez que tenemos la salida de registro de la console, queremos incluir ese ID único en esa salida. ¿Verdad?

Entonces, la forma en que tenías que hacerlo hasta que existía el almacenamiento local es que esencialmente tenías que pasar ese ID explícitamente a través de todas tus funciones. ¿Verdad? O tenías que adjuntarlo a otra cosa. Probablemente todos hemos visto el caso en que tomas el objeto de solicitud y agregas propiedades y lo pasas a través. Eso es muy bruto. Agregar propiedades arbitrarias al objeto de otra persona que no posees siempre es un poco problemático. ¿Verdad? Y además, tener que pasar esta propiedad a través de cada función, incluso si no la vas a usar, solo para poder tener algo como el registro, es muy engorroso, muy difícil de hacer, especialmente si no controlas ese código. ¿Verdad? Todas esas funciones por las que tienes que pasar, si no controlas eso, lo hace mucho más difícil de hacer. ¿Verdad? Entonces, sabes, esto muestra un poco más de la complejidad aquí. Como, en todas partes a donde va esa cosa, esta función de hacer algo y hacer algo más, no estamos usando realmente el ID allí. La única razón por la que tenemos que pasar eso es para que podamos llevarlo a ese registro. ¿Verdad? Con el almacenamiento local asíncrono tenemos un modelo mucho mejor. ¿Verdad? Podemos crear esta instancia de almacenamiento local asíncrono en un alcance que sea visible para ambos, sabes, servidor y nuestra función de registro. ¿Verdad? Los métodos de hacer algo y hacer algo más no necesitan saber nada sobre este ID. ¿Verdad? Como establecemos, como, sabes, entramos y empezamos a tratar con nuestra solicitud, ¿verdad? Le decimos al ID de la solicitud cuál va a ser ese valor. Esto está configurando un contador que se incrementa en cada solicitud. Y luego llamamos a set timeout. Solo estamos, sabes, simulando actividad asíncrona aquí. Va a esperar un poco de tiempo. Luego, cuando realmente llama a esa función, esa función de hacer algo, que luego hace el registro. Dentro del registro, sacaremos ese valor almacenado del ID de la solicitud y seguiremos desde allí. Entonces, simplifica enormemente cómo pasamos esta información hacia abajo. Como dije, especialmente cuando no controlamos esa API por la que estamos pasando.

¿Verdad? Entonces, si este 'do something' es de algún módulo de terceros arbitrario en NPM que no controlas, pero aún necesitas ese ID pasado a través y en tus registros, el almacenamiento local asíncrono es lo que va a hacer eso posible para ti. ¿Verdad? Te va a permitir obtener esa información. A esto es a lo que nos referimos con permanecer coherente. Está ahí cuando lo necesitas en ese flujo asíncrono. ¿OK?

Podemos establecer varias cosas, ¿verdad? Entonces, este almacenamiento local asíncrono no es solo un valor único. Puedes programar tantas continuaciones como quieras al mismo tiempo, diferentes valores. Cuando se ejecutan, y pueden ejecutarse en cualquier orden, el valor apropiado se devolverá cuando llames a 'als get store'. ¿OK?

Pero, ¿cómo hacemos esto? Desafortunadamente, es un poco complicado en este momento en Node. El almacenamiento local asíncrono se basa en una API llamada async hooks y promise hooks. Hablaremos un poco más sobre eso en un momento. Pero añade un cierto grado de complejidad y pérdida de performance cuando realmente vamos a usar esto. Cada instancia de almacenamiento local asíncrono tiene una clave. Y es una clave oculta dentro de esa instancia que representa esa instancia particular de esa API. Y luego, en cualquier momento dentro de Node, tenemos algo llamado recurso de ejecución actual. Ese es el objeto que representa el código que se está ejecutando en este momento. Entonces, cuando se dispara un temporizador, ese recurso de ejecución actual es un temporizador. Cuando estás lidiando con una promesa, entonces una continuación de promesa, ese recurso de ejecución actual es una promesa. Siempre hay un objeto que representa ese código en ejecución dentro de Node, ¿verdad? Siempre que estableces ese valor, entonces 'als.run', ese 'run', y estamos estableciendo ese valor, lo que hacemos es establecer esa clave de esa instancia al valor que estamos estableciendo. Y ese recurso de ejecución actual mantiene el mapa de todos esos valores. Digamos que tenemos 10 instancias de almacenamiento local asíncrono en nuestra aplicación, en ese recurso de ejecución actual van a haber 10 claves, 10 valores diferentes, ¿verdad? Cada vez que programamos algo nuevo, un nuevo temporizador, una nueva continuación de promesa, cada vez que añades un nuevo 'then', cada vez que creas una nueva promesa, lo que terminamos haciendo ahora es tomar el conjunto completo de esas propiedades y copiarlas al nuevo recurso. Pero piensa en el costo de performance de eso. He lidiado con aplicaciones de producción que han creado decenas de miles de promesas en solo unos segundos. Cada vez que se crea una nueva promesa en este modelo, ese contexto asíncrono aquí, esas claves y valores se copian de un objeto a otro. ¿Verdad? Esa es una operación increíblemente costosa. He visto casos en los que simplemente activar el almacenamiento local asíncrono en una aplicación pesada ha sido una pérdida de rendimiento del 30 al 50%. Y eso es siendo bastante conservador. ¿Verdad? Podemos hacerlo mejor. Como dije, la implementación de Node se basa en async hooks y promise hooks. Async hooks fue originalmente diseñado como una API de diagnóstico. Es una forma de monitorear el ciclo de vida de estos recursos asíncronos que se crean dentro de Node.

Pero es algo muy interno y de bajo nivel. Se descubrió cuando comenzamos a mirar el almacenamiento local asíncrono, como, hey, podríamos usar esto para implementar este modelo. pero el performance de esto es realmente bastante pobre.

Promise hooks es una API incorporada en v8, realmente destinada a ayudar con este tipo de casos de uso. Lo que hace es que configura una serie de callbacks que pueden dispararse cuando se crea una promesa, cuando se resuelve, cuando es simplemente todos los diferentes eventos del ciclo de vida de esa promesa. Pero eso se vuelve increíblemente costoso cuando estás invocando ese código cada vez que creas una promesa, cada vez que resuelves la promesa. Y como dije, las aplicaciones pueden crear decenas de miles, incluso cientos de miles de promesas en solo, ya sabes, unos pocos momentos de tiempo. Así que ese código termina siendo extremadamente costoso de ejecutar cada vez.

Un problema clave aquí es que estamos propagando ese contexto. Estamos copiando esos valores clave de un recurso de ejecución a otro. Cada vez que el recurso es, cada vez que se crea una de esas continuaciones, no cuando el contexto realmente cambia, ¿verdad? Y eso es lo clave porque la información contextual real con la que estás lidiando solo cambia muy, muy raramente, ¿verdad? Solo estás lidiando con unas pocas, unas pocas instancias de estas cosas. Los valores normalmente se establecen una vez durante la, durante esta aplicación. Ya sabes, ahora mismo, cada vez que creamos esas promesas, estamos copiando esos data cada vez y se vuelve muy, muy costoso muy rápidamente.

Así que recientemente implementamos el almacenamiento local asíncrono en los trabajadores de cloud. Esto es algo divertido. En realidad, no vamos a tener una compatibilidad total con Node en los trabajadores, pero sí tendremos cosas como, tendremos cosas como node dot o node colon F o no FS, pero node colon net y node colon crypto, y muchas de estas cosas, estamos usando el especificador de node allí. Es requerido al igual que en Dino. Está allí. Y el almacenamiento local asíncrono es una de las primeras cosas que añadimos. Acaba de ser habilitado, creo que el mes pasado donde está disponible para que todos lo usen. Pero hicimos esto sin usar async hooks o promise hooks. Pero a nivel de API lo que usa el código, es muy compatible con lo que tiene Node, pero lo hemos implementado de una manera completamente diferente.

Entonces, ¿cómo lo hacemos? Introdujimos algo llamado marco de contexto asíncrono. En lugar de almacenar todos esos pares clave-valor en el recurso de ejecución real, lo que hacemos es crear un marco solo cuando los data realmente cambian. Así que inicialmente cuando la aplicación está corriendo, no hay marco. No hemos establecido ningún valor. La primera vez que se utiliza una instancia de ALS, crearemos un marco y estableceremos ese valor y ese marco mantiene ese mapa. El recurso de ejecución solo mantiene una referencia al marco actual. Así que cuando se crea ese recurso, simplemente lo vincularemos al marco que sea actual. Solo creamos nuevos marcos cuando se especifica un nuevo valor.

Por lo tanto, es mucho menos costoso. Solo estamos propagando ese contexto cuando los valores realmente cambian, no cuando se programan las continuaciones individuales. Esto resulta en una mejora masiva de performance. Así es como lo hacemos actualmente en Workers. Así es como quiero hacerlo en Node.

Me salté algunas diapositivas aquí, pero hay un challenge con cómo podemos implementar esto en Node en este momento. Todo esto depende de una nueva API. Es una API que ha estado en V8 durante años que estamos utilizando. Está sin documentar, muy pocas personas realmente saben sobre esta API. Elimina completamente cualquier dependencia de async hooks y promise hooks para que podamos implementar este modelo completo.

El problema es que Chromium también utiliza esta API. La forma en que la API está diseñada actualmente, solo puedes usarla para un propósito a la vez. Si Node fuera solo Node, no dependiera de Chromium en absoluto, solo por sí mismo, estaría bien. Podríamos usarlo. Pero hay cosas como Electron que utilizan tanto Node como Chromium, y están utilizando la misma instancia de V8. Dado que Chromium también está utilizando esta API a su manera, no podemos usarla en Node todavía, hasta que hagamos cambios en V8 para que realmente funcione. El cambio clave que necesitamos para hacer que funcione es permitir múltiples usos de esta API al mismo tiempo, para poder establecer estos datos contextuales y tener múltiples claves. Entonces, es algo que viene. Lo que espero es que más adelante este año, podamos hacer estos cambios en V8, y hacer de esto una mejora significativa de performance en Node, para cualquiera que esté utilizando la API de almacenamiento local asíncrono. En este momento, performance es el problema número uno con el que te vas a encontrar, si estás utilizando esta API. ¿Okay?

Entonces, ¿qué pasa con la estandarización? Esta es una muy buena pregunta. Hace un tiempo, Luca, trabajando en Dino, publicó este comentario en Twitter, me pareció bastante divertido. Vercel tiene, ya sabes, con Next.js, y dijeron que iba a ser totalmente basado en estándares, vamos a utilizar todos los estándares de la plataforma web, pero hey, requiere almacenamiento local asíncrono. El almacenamiento local asíncrono es una API específica de Node, no hay especificación para ello en absoluto aparte del código y la documentation. Porque es una API específica de Node. Pero Vercel lo ha adoptado, otras personas están comenzando a adoptarlo. Entonces, ¿qué se supone que deben hacer estos tiempos de ejecución? ¿Correcto? ¿Dino y workers y Bun, simplemente se van e implementan, siguen la iniciativa de Node e implementan todas las API específicas de Node? Resulta que sí, estamos haciendo eso, ¿verdad? Estamos, ya sabes, pero estamos implementando esa capa de compatibilidad con Node, pero lo que realmente queremos son estándares, es una API estándar para esto. Afortunadamente, TC39 está trabajando en esto. Hay una API de contexto asíncrono que se está desarrollando activamente en este momento. Está en la etapa dos.

Y para dar una idea de cómo va a ser esto, este es el ejemplo con almacenamiento local asíncrono ahora, y así es como cambia con el contexto asíncrono. ¿Correcto? Así que simplemente cambiamos new async local storage a new async context y get store simplemente se convierte en get. ¿Correcto? Va a ser así de simple.

Hay algunas otras, ya sabes, hay algunas otras diferencias de API más pequeñas dependiendo de lo que estés haciendo, pero para el caso de uso más común, este es el alcance del cambio. ¿Okay? Así que muy, muy sencillo. El código QR te envía al repositorio de GitHub donde se está trabajando en esta propuesta. Está en desarrollo activo en este momento. Está en la etapa dos. Se espera que pase a la etapa tres un poco más tarde este año, solo hay muchas preguntas sin respuesta, cosas en las que todavía están trabajando. La mayoría de la API, sin embargo, es estable, pero está en camino de ser añadida pronto.

Si tienes interés en esto, están buscando más aportes sobre casos de uso y simplemente preguntas generales en general sobre cómo se va a utilizar esto. Pero ya sabes, como dije, la API simple está bastante cerca. Hay algunas características del almacenamiento local asíncrono que no estarán en el contexto asíncrono. Específicamente cosas como enter with y disable. Lo que estas APIs te permiten hacer es modificar la información contextual en el lugar sin - con run, run creará ese nuevo marco, enter with modifica ese marco tal como existe. Así que ese marco de contexto se vuelve completamente mutable de forma sincrónica. Eso tiene una serie de desafíos. Azure actualmente permite eso. Es una característica experimental pero eso no va a ser llevado al Contexto Asíncrono por una serie de razones. Así que simplemente no uses esas. No uses esas características. Y en realidad, como parte de WinterCG, creamos lo que llamamos un subconjunto portátil interoperable con la web. Básicamente es solo el subconjunto de la API de almacenamiento local asíncrono que puedes usar hoy y ser compatible con el Contexto Asíncrono cuando salga. Y el objetivo aquí es implementar esto no solo en Node, ya está allí, sino implementarlo en Workers. Nos gustaría verlo implementado en Deno. Nos gustaría verlo implementado en Bun. Nos gustaría verlo implementado en todas las Runtimes de JavaScript que existen. Y estamos trabajando activamente con esas Runtimes, para que empiecen a mirar este subconjunto e implementarlo, antes de que llegue el Contexto Asíncrono.

Así que eso es todo. Espero que haya sido útil.

Si tienen preguntas sobre esto, háganmelo saber. Gracias. Gracias, James. Eso estuvo genial. ¿Tenemos alguna pregunta?

Entonces, tenemos algunas preguntas para ti, la primera es, ¿cómo tienes una barba tan genial? Cuando conocí a mi esposa, solo tenía un poco de barba, y ella simplemente dijo que no me afeitara, así que la tengo. Fue hace bastante tiempo, en 2012. 2012, no te has afeitado ni una sola vez. No me he afeitado en un tiempo, tengo que mantener a mi esposa feliz.

La siguiente pregunta es, ¿no crearía un concurso de sumideros un estado global con su propio conjunto de parámetros a propagar? ¿Vale la pena el compromiso? La respuesta corta es sí. Puede. Si estableces el contexto asíncrono en ese estado global, entonces sí, lleva todos los mismos problemas que para el estado global en general. Puedes establecer ese almacenamiento local asíncrono o el contexto asíncrono en cualquier ámbito que quieras. Solo tiene que ser accesible para las funciones que lo necesitarán. Entonces, no tienes que hacerlo como un global. La mayoría de los ejemplos lo muestran como un global. Genial. Bueno, sigo haciendo tus preguntas, por favor.

La siguiente pregunta es, el contexto asíncrono en la etapa 2, ¿hay algún tipo de resistencia en la security que podría impedir que esto aterrice? Sí. En términos de resistencia, la API es bastante estable. Ha habido algunas preguntas de security en el comité. Pero hasta donde yo entiendo, se han resuelto y es bastante bien aceptado. La pregunta clave que se está haciendo ahora es si realmente pertenece al lenguaje en absoluto versus ser impulsado como una API de plataforma web a través de WG o W3C, uno de esos lugares. Ese es el debate clave que está sucediendo ahora. Y todavía, quiero decir que todavía hay algunos argumentos realmente buenos para que no entre en el lenguaje. Genial. ¿Y por qué el almacenamiento local asíncrono copia pares de valores clave en lugar de hacer las mismas cosas que tú hiciste? El... Es difícil de decir. Como todo se construyó sobre la API de ganchos asíncronos, hay algunas limitaciones en cómo funciona eso. Hay bastante complejidad involucrada en el seguimiento de esos recursos. Y el hecho de que estamos lidiando con tantos tipos diferentes de recursos, promesas y temporizadores y todas estas cosas, era prácticamente lo más fácil de hacer en el modelo actual.

Simplemente no era la forma más eficiente de hacerlo, pero creo que terminó siendo la más fácil. ¿Hay alguna posibilidad de que nterwith pueda ser implementado en la propuesta? Es básicamente necesario para los APMs ya que a veces no podemos decidir si somos SYNC o asíncronos? Sí. Probablemente no. Entonces, en este punto, los autores de la propuesta de contexto asíncrono lo han descartado por completo y dicen que no quieren apoyar esa funcionalidad de nterwith. Si volverá o no más adelante, no lo sé, no lo preveo.

Tenemos más preguntas para ti. Tenemos dominios que están obsoletos y almacenamiento local asíncrono que es experimental. ¿Cuál debería usar ahora si lo necesito? Entonces use el almacenamiento local asíncrono ahora, adhiera a ese subconjunto portátil que WinterCG ha definido. Eso va a ser, si te adhieres a ese subconjunto cuando el contexto asíncrono esté terminado, será, Node lo apoyará, los trabajadores lo apoyarán, esperemos que Dino también lo apoye. Así que tienes una mayor posibilidad de ser compatible si te adhieres a ese subconjunto. La API de ganchos asíncronos, no está obsoleta tanto como es permanentemente experimental y a nadie le gusta. Así que tiene algunos casos realmente buenos para fines de diagnóstico y puedes usarlo para esas cosas pero para la mayoría de los casos de aplicación probablemente sea mejor evitarlo.

Genial. Acabas de mencionar Dino. Tenemos una pregunta de Dino aquí. ¿Ves algunas similitudes con DinoKV? Oh sí, sí. Estoy muy interesado en DinoKV. En los trabajadores, tenemos KV2 y voy a profundizar mucho más en eso. Genial. Pero sí, no hay comentarios al respecto todavía. Sorpresa. ¿Puedes darnos más casos de uso interesantes además del registro? Eso es interesante. Las personas que están trabajando en la propuesta de contexto asíncrono están luchando para obtener más casos de uso además de cosas como el rastreo y el registro y ese tipo de cosas, pero si miras la mayoría de las... Si miras la mayoría de las aplicaciones que utilizan almacenamiento local asíncrono ahora... Son cosas como APMs, trazador, y registro... Esos son los casos de uso clave. Así que es como, sabes, estamos buscando más, pero esos son los que hemos visto más. El rastreo es uno grande. ¿El contexto asíncrono está relacionado o inspirado en el contexto asíncrono de Java? Sabes, esa es una buena pregunta. No lo sé.

¿No? Lo averiguaremos más tarde... Está principalmente inspirado en el almacenamiento local asíncrono.

¿Y qué tipo de aplicaciones se beneficiarán de migrar al contexto asíncrono desde ASL? Creo que todas. Así que ALS es lo que tienes disponible ahora. Es lo que deberías usar ahora. Cuando el contexto asíncrono esté disponible, no habrá ninguna razón para no usarlo y no migrar a él. Como dije, los modelos van a ser muy similares, muy cercanos. Las diferencias en la API van a ser muy mínimas. Así que no habrá ninguna razón para evitarlo.

Los tipos de aplicaciones, servidores, va a ser principalmente más útil para servidores que tengan ese contexto único para cada solicitud. Bueno, no tenemos más preguntas, pero gracias y vamos a darle un bolígrafo.