El camino hacia el contexto asíncrono

Buenos días, ¿cómo están todos? Cuando me invitaron a subir y hablar, estaba pensando en qué quería hablar Sabes, podríamos hablar de Node en general, de lo que está sucediendo en el proyecto. Y solo quería hablar de código.

Así que, sabes, quiero hablar sobre parte del código que hemos estado escribiendo recientemente, hemos estado trabajando no solo en Node, sino también en Cloudflare Workers y la API de almacenamiento local async. Si no estás familiarizado con ella, ha estado en Node durante un par de años, pero no es muy conocida en cuanto a lo que hace y cómo funciona. Y una de las cosas que, sabes, mientras comenzamos a trabajar en esto en Workers recientemente como parte de nuestra historia de compatibilidad con Node, tratamos de averiguar cómo está implementado, cómo, sabes, es el rendimiento y cómo está escrito. ¿Es lo que debería ser? Bien.

En Workers, decidimos tomar un enfoque de diseño diferente en cómo funciona bajo los covers y quiero hablar sobre las diferencias entre cómo funciona en Node, cómo funciona en Workers y hacia dónde se dirigen las cosas. Ahora, sabes, ese título original de la charla, el Camino hacia Async Context. Async context es en realidad una nueva API estándar propuesta que cubre el mismo caso de uso que almacenamiento local async, pero en realidad se agregará al propio lenguaje. Y hablaré un poco sobre eso al final. Un poco más sobre mí, 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. En realidad, soy parte del 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í. Mostrará algunos detalles y aspectos más específicos de Workers. Si estás interesado en eso, te recomiendo que vayas a su charla más tarde. Bien, empecemos. ¿Qué es el almacenamiento local async? La documentación de Node nos da esta definición muy útil. Crea una tienda que se mantiene coherente a través de operaciones async. Eso es básicamente todo. Y luego te da un ejemplo. Es una explicación extremadamente inútil de lo que es. Así que lo vamos a desglosar un poco más. Bien, 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. Una continuación es cualquier código que se programa para ejecutarse más tarde. Piensa en un temporizador o una promesa. Cada vez que adjuntas un then, un catch, un finally a ella. Callbacks.

Entonces, cuando llamas a la API de FS y se ejecuta el callback async más tarde. Sabes, la continuación es más o menos el término genérico para esas cosas que están programadas para ejecutarse más tarde. ¿De acuerdo? De acuerdo. Entonces, a medida que el contexto de ejecución se está ejecutando, puede programar cualquier número de estas cosas, ¿verdad? Sabes, si estás usando QMicroTask, promesas, callbacks o process next take. Todas estas cosas son cosas que el código actual, el código en ejecución actual, puede programar para ejecutarse, ya sabes, en unos momentos, más tarde, ya sabes, en algún momento posterior en la aplicación. Lo que sea. Pero estas cosas pueden acumularse.

El almacenamiento local asíncrono se trata de poder asociar data contextual con la programación de esa continuación, ¿verdad? Entonces, cuando el contexto de ejecución actual se está ejecutando, 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 entender. Muy bien. 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 consola que tenga un identificador de solicitud único. ¿De acuerdo? Así que 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 del registro de la consola, queremos incluir ese ID único en esa salida. ¿De acuerdo?

La forma en que tenías que hacerlo hasta que existía el almacenamiento local esencialmente era pasar ese ID explícitamente a través de todas tus funciones. ¿De acuerdo? O tenías que adjuntarlo a algo más. Probablemente todos hemos visto el caso en el que tomas el objeto de solicitud y agregas propiedades y lo pasas así. Eso es muy desagradable. Agregar propiedades arbitrarias a un objeto de otra persona que no posees siempre es un poco problemático. ¿De acuerdo? Y además, tener que pasar esta propiedad por 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. ¿De acuerdo? Todas esas funciones por las que tienes que pasar, si no controlas eso, hace que sea mucho más difícil de hacer. ¿De acuerdo? Entonces, ya 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, en realidad no estamos usando el ID allí. La única razón por la que tenemos que pasarlo es para poder llegar a ese registro. ¿De acuerdo? Con el almacenamiento local asíncrono tenemos un modelo mucho mejor. ¿De acuerdo? Podemos crear esta instancia de almacenamiento local asíncrono en un ámbito que sea visible tanto para, ya sabes, el servidor como para nuestra función de registro. ¿De acuerdo? Los métodos de hacer algo y hacer algo más no necesitan saber nada sobre este ID. ¿De acuerdo? A medida que establecemos, a medida que, ya sabes, vamos y comenzamos a lidiar con nuestra solicitud, ¿verdad? Le decimos al ID de solicitud cuál será ese valor. Esto está configurando un contador que se incrementa en cada solicitud. Y luego llamamos a set timeout. Solo estamos 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, extraeremos ese valor almacenado del ID de solicitud y seguiremos adelante. Entonces, simplifica en gran medida cómo pasamos realmente esta información. Como dije, especialmente cuando no controlamos esa API por la que estamos pasando.

¿Verdad? Entonces, si este hacer algo es de algún módulo arbitrario de terceros en NPM que no controlas la API, pero aún necesitas que se pase ese ID y aparezca en tus registros, el almacenamiento local asíncrono es lo que hará eso posible para ti. ¿Verdad? Te permitirá obtener esa información. Esto es a lo que nos referimos con mantener la coherencia. Está ahí cuando lo necesitas en ese flujo asíncrono. ¿De acuerdo?

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

Pero, ¿cómo lo hacemos? Desafortunadamente, es un poco complicado en Node en este momento. El almacenamiento local asíncrono se basa en una API llamada ganchos asíncronos y ganchos de promesas. Hablaremos un poco más sobre eso en un momento. Pero agrega un cierto grado de complejidad y pérdida de rendimiento cuando realmente lo usamos. 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 dado dentro de Node, tenemos esta cosa llamada 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 actual dentro de Node, ¿verdad? Cada vez que estableces ese valor, entonces als.run, ¿verdad?, y establecemos ese valor, lo que hacemos es establecer esa clave de esa instancia en el 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 habrá 10 claves, 10 valores diferentes, ¿verdad? Cada vez que programamos algo nuevo, un nuevo temporizador, una nueva continuación de promesa, cada vez que agregas un nuevo then, cada vez que creas una nueva promesa, lo que hacemos ahora es tomar el conjunto completo de esas propiedades y copiarlas al nuevo recurso. Pero piensa en el costo de rendimiento de eso. He trabajado con aplicaciones en 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, este contexto asíncrono aquí, esas claves valores se copian de un objeto al siguiente. ¿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 ser bastante conservador. ¿Verdad? Podemos hacerlo mejor. Como dije, la implementación de Node se basa en ganchos asíncronos y ganchos de promesas. Los ganchos asíncronos fueron originalmente destinados 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 básico e interno. Se descubrió cuando comenzamos a analizar el almacenamiento local asíncrono, como, hey, podríamos usar esto para implementar este modelo. pero su rendimiento es realmente pobre.

Promise hooks es una API integrada en v8, realmente destinada a ayudar con este tipo de casos de uso. Lo que hace es configurar una serie de devoluciones de llamada que se pueden activar cuando se crea una promesa, cuando se resuelve, cuando ocurren todos los diferentes eventos del ciclo de vida de esa promesa. Pero eso se vuelve extremadamente costoso cuando invocas 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 unos momentos de tiempo. Por lo tanto, ese código termina siendo extremadamente costoso de ejecutar cada vez.

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

Recientemente implementamos el almacenamiento local asíncrono en Cloudflare Workers. Esto es algo divertido. En realidad, no vamos a tener compatibilidad total con Node en Workers, pero 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 nodo allí. Es obligatorio, al igual que en Dino. Está ahí. Y el almacenamiento local asíncrono es uno de los primeros que agregamos. Acaba de habilitarse, creo que el mes pasado, y está disponible para que todos lo usen. Pero lo hicimos 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 esta cosa llamada un 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 el dato realmente cambia. Entonces, inicialmente, cuando la aplicación se está ejecutando, 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 realmente mantiene ese mapa. El recurso de ejecución solo mantiene una referencia al marco actual. Entonces, cuando se crea ese recurso, simplemente lo vincularemos al marco actual. Solo creamos nuevos marcos cuando se especifica un nuevo valor.

Entonces 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 rendimiento. Esto es cómo lo hacemos actualmente en Workers. Esto es cómo quiero hacerlo en Node.

Me salté algunas diapositivas aquí, pero hay un desafío 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 y que estamos utilizando. Es poco documentada, muy pocas personas realmente conocen esta API. Elimina por completo cualquier dependencia de los ganchos asíncronos y los ganchos de promesa para implementar todo este modelo.

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

Entonces, ¿qué hay de la estandarización? Esta es una muy buena pregunta. Hace un tiempo, Luca, que trabaja en Dino, publicó este comentario en Twitter, lo encontré bastante divertido. Vercel ha adoptado el almacenamiento local asíncrono, otras personas están comenzando a adoptarlo. Entonces, ¿qué deben hacer estos entornos de ejecución? ¿Dino y Workers y Bun, simplemente implementan, siguen el ejemplo de Node e implementan todas las API específicas de Node? Bueno, resulta que sí, estamos haciendo eso. Estamos implementando esa capa de compatibilidad con Node, pero lo que realmente queremos son estándares, 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 tener una idea de cómo se verá esto, este es el ejemplo con almacenamiento local asíncrono ahora, y así es como cambia con el contexto asíncrono. ¿Correcto? Entonces simplemente cambiamos new async local storage a new async context y get store simplemente se convierte en get. ¿Correcto? Será tan simple como eso.

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. ¿De acuerdo? Muy, muy sencillo. El código QR te lleva al repositorio de GitHub donde se está trabajando en esta propuesta. Actualmente está en desarrollo activo. Está en la etapa dos. Se espera que pase a la etapa tres un poco más adelante este año, con muchas preguntas sin respuesta, cosas en las que todavía están trabajando. La mayor parte de la API, sin embargo, es estable, pero está en camino de ser agregada pronto.

Si tienes interés en esto, están buscando más aportes sobre casos de uso y preguntas generales sobre cómo se va a utilizar. Pero, 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 permiten estas API es modificar la información contextual en su lugar sin - con run, run creará ese nuevo marco, enter with modifica ese marco tal como existe. Por lo tanto, ese marco de contexto se vuelve completamente mutable de forma síncrona. Eso tiene varios desafíos. Azure actualmente lo permite. Es una función experimental, pero eso no se llevará a Async Context por varias razones. Así que simplemente no uses esas. No uses esas características. Y de hecho, como parte de WinterCG, creamos lo que llamamos un subconjunto portátil interoperable web. Básicamente, es solo el subconjunto de la API de almacenamiento local asíncrono que puedes usar hoy y ser compatible con Async Context cuando salga. Y el objetivo aquí es implementar esto no solo en Node, que 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 todos los JavaScript Runtimes que existen. Y estamos trabajando activamente con esos Runtimes para que analicen este subconjunto e implementen esto, antes de que llegue Async Context.

Eso es todo. Espero que haya sido útil.

La gente tiene preguntas sobre esto, solo avísenme. Gracias. Gracias James. Eso fue genial. ¿Tenemos alguna pregunta?

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

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

La siguiente pregunta es, el contexto asíncrono está en la etapa 2, ¿hay algún tipo de resistencia en cuanto a seguridad que pueda evitar que esto se implemente? Sí. En cuanto a la resistencia, la API es bastante estable. Ha habido algunas preguntas de seguridad en el comité. Pero según lo que he entendido, esas preguntas se han resuelto y ha sido bien aceptado. La pregunta clave que se está haciendo en este momento es si realmente pertenece al lenguaje o si debería ser implementado como una API de la plataforma web a través de WG o W3C, uno de esos lugares. Ese es el debate clave que está ocurriendo en este momento. Y todavía hay algunos argumentos muy buenos en contra de que se incluya en el lenguaje. Genial. Y ¿por qué el almacenamiento local asíncrono copia pares clave-valor en lugar de hacer lo mismo que hiciste? Es difícil de decir. Dado que 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 estemos lidiando con muchos tipos diferentes de recursos, promesas y temporizadores y todas esas cosas, fue lo más fácil de hacer en el modelo actual.

No fue la forma más eficiente de hacerlo, pero creo que terminó siendo la más fácil. ¿Hay alguna posibilidad de que nterwith se pueda implementar en la propuesta? ¿Es básicamente necesario para APM ya que a veces no podemos decidir si estamos en modo SYNC o asíncrono? Sí, probablemente no. En este momento, los autores de la propuesta de contexto asíncrono lo han descartado por completo y dicen que no quieren admitir esa funcionalidad de nterwith. No sé si volverá más adelante, no lo veo.

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? Así que use el almacenamiento local asíncrono ahora, adhiérase a ese subconjunto portátil que ha definido WinterCG. Eso será, si se adhiere a ese subconjunto cuando se termine el contexto asíncrono, Node admitirá ambos, los workers admitirán ambos, con suerte Dino admitirá ambos. Así que tiene una mayor probabilidad de ser compatible si se adhiere a ese subconjunto. La API de ganchos asíncronos, no está obsoleta tanto como que es permanentemente experimental y a nadie le gusta. Tiene algunos casos realmente buenos para fines de diagnóstico y puede usarlo para esas cosas, pero en la mayoría de los casos de aplicación es mejor evitarlo.

Genial. Acabas de mencionar a Dino. Tenemos una pregunta sobre Dino. ¿Ves algunas similitudes con DinoKV? Oh sí, sí. Estoy muy interesado en DinoKV. En los workers, tenemos KV2 y voy a investigar eso mucho más en detalle. Bueno, 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 trabajan en la propuesta de contexto asíncrono están luchando por encontrar más casos de uso además de cosas como trazado y registro, pero si observas la mayoría de las... Si observas la mayoría de las aplicaciones que usan el almacenamiento local asíncrono ahora... Son cosas como APM, trazador y registro... Esos son los casos de uso clave. Así que, ya sabes, estamos buscando más, pero esos son los que hemos visto más. El trazado es uno importante. ¿El contexto asíncrono está relacionado o inspirado en el contexto asíncrono de Java? Esa es una buena pregunta. No lo sé.

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

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

Los tipos de aplicaciones, servidores, principalmente serán más útiles para servidores que tienen ese contexto único para cada solicitud. Bueno, no tenemos más preguntas, pero gracias y démosle una pluma.