ESM Loaders: Mejorando la carga de módulos en Node.js

Rate this content
Bookmark

El soporte nativo de ESM para Node.js fue una oportunidad para el proyecto de Node.js de lanzar soporte oficial para mejorar la experiencia de carga de módulos, permitiendo casos de uso como la transpilación sobre la marcha, la sustitución de módulos, el soporte para cargar módulos desde HTTP y la monitorización.


Aunque CommonJS tiene soporte para todo esto, nunca fue oficialmente compatible y se hacía mediante hackeo del código de ejecución de Node.js. ESM ha solucionado todo esto. Analizaremos la arquitectura de la carga de ESM en Node.js y discutiremos la API del cargador que lo admite. También veremos características avanzadas como la concatenación de cargadores y la ejecución fuera de hilo.

22 min
05 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Los ESM Loaders mejoran la carga de módulos en Node.js al resolver URLs y leer archivos del disco. Los cargadores de módulos pueden anular módulos y cambiar cómo se encuentran. Mejorar la fase de carga implica cargar directamente desde HTTP y cargar código TypeScript sin compilarlo. El cargador en la URL del módulo maneja la resolución de URLs y utiliza fetch para obtener el código fuente. Los cargadores se pueden encadenar para cargar desde diferentes fuentes, transformar el código fuente y resolver URLs de manera diferente. El futuro de las mejoras en la carga de módulos es prometedor y fácil de usar.

Available in English

1. Introducción a ESM y Carga de Módulos en Node.js

Short description:

ESM Loaders, Mejorando la Carga de Módulos en Node.js. ESM es el sistema de módulos estándar de JavaScript nativo de Node.js. La carga de módulos en Node.js implica ejecutar el código dentro de un módulo. Los usuarios de TypeScript necesitan transpilar a common.js. La ejecución de módulos en Node.js implica resolver URLs.

ESM Loaders, Mejorando la Carga de Módulos en Node.js. Hola, soy Gil Tayar. Soy bastante viejo. Nos remontamos a los años 80. Siempre fui desarrollador. Hice muchas cosas, pero básicamente eso es lo que amo hacer. Otra cosa que me encanta hacer es usar NPM y ESM y todo eso para mejorar mi código utilizando una modularidad extrema y pruebas de código. Actualmente soy ingeniero de software en Microsoft y trabajo en cosas geniales como el Azure Data Explorer, que es un motor de análisis en tiempo real. Nada que ver con ESM.

Bien, vamos a aclarar algunas cosas antes de hablar sobre cómo mejorar la carga de módulos. Hablemos de qué es ESM. ESM es el sistema de módulos estándar de JavaScript. y ahora es nativo de Node.js. Así que si antes teníamos module.export de common.js para exportar algo y require para importarlo, en ESM, se utiliza la sintaxis estándar export e import para hacer la exportación e importación de módulos. La sintaxis nativa funciona en Node.js, la mayoría de las personas todavía usan common.js pero ESModule se está utilizando cada vez más frecuentemente.

¿Qué es la carga de módulos en Node.js? Hablemos un poco sobre esa carga de módulos. En primer lugar, ¿qué es un módulo? Básicamente, es un archivo glorificado, simplemente se llama módulo. Entonces, cuando ejecuto un módulo o importo un módulo, básicamente estoy ejecutando el código dentro del módulo, es una ejecución glorificada de la carga de módulos. Incluso cuando estoy importando module.js en la parte superior, se está ejecutando module.js en la parte inferior y luego continúa ejecutando main.js. Todo se trata de una ejecución glorificada. En primer lugar, una nota para los usuarios de TypeScript, si estás utilizando TypeScript en Node.js, estás utilizando la sintaxis de import-export pero probablemente estés transpilando eso a common.js porque ESM es bastante nuevo en el juego. Por lo general, TypeScript transpila por defecto a common.js. Así que si estás probando todas las cosas que estoy haciendo aquí con los cargadores de ASM en tu código de TypeScript, no funcionará. Debes no traducir el ESM utilizando module.node.next. Y tienes un ejemplo en el repositorio de GitHub, no te preocupes, al final, tendrás un enlace al repositorio de GitHub con un código QR y un enlace a esta presentación. De acuerdo. ¿Cuáles son las fases de la ejecución de módulos? ¿Cómo ejecuta Node.js un módulo? No es simple. En primer lugar, resolvemos la URL. Así que si estamos haciendo import.slash module.js, tenemos que resolverlo a la ruta absoluta en el disco. Y ESM no habla de rutas.

2. Carga de Módulos ESM en Node.js

Short description:

La carga de módulos ESM en Node.js implica resolver URLs y leer archivos del disco. Carga de forma recursiva todos los módulos en el archivo sin ejecutarlos. Una vez que se cargan todos los archivos, ejecuta el código de los módulos en el orden correcto.

Se habla de URLs. Por lo general, las URLs son URLs de archivos, pero siguen siendo URLs. Una vez que se resuelve la URL, una vez que Node.js resuelve la URL, lee el archivo del disco. Y esto es diferente de CommonJS, pero no hablemos de eso, carga de forma recursiva todos los modules en el archivo sin ejecutarlos.

Observa que no hemos ejecutado el módulo ESM anterior. Una vez que carga de forma recursiva todos los archivos, ejecuta el código de todos los modules de abajo hacia arriba en el orden correcto. Estas son las fases de ejecución de módulos en Node.js. Y básicamente también en los navegadores, en cualquier lugar donde se implemente ESM, estas son las fases. Y esto es diferente de CommonJS, no entremos en detalles.

3. Module Loaders and Overriding Modules

Short description:

Los cargadores de módulos mejoran las fases de resolución y carga en Node.js. Ejemplos incluyen pnpm, que cambia cómo se encuentran los módulos, y los mapas de importación para sobrescribir especificadores sin ruta. Podemos escribir un cargador para sobrescribir módulos especificando un cargador usando la bandera --loader. El archivo loader.js lee el archivo overrides.json y exporta una función de resolución que toma el especificador del módulo como parámetro.

Bien, hablemos de los cargadores de módulos. Los cargadores de módulos mejoran las dos primeras, mejoran y cambian y transforman cómo Node.js realiza una resolución y cómo lee el archivo, el módulo. Hablemos de mejorar la fase de resolución, daremos un ejemplo y luego daremos un ejemplo para la fase de carga.

Hablemos de la fase de resolución. Damos dos ejemplos. Uno es pnpm, es un gestor de paquetes como yarn y npm, pero pnpm cambia la forma en que se encuentran los módulos. Por lo tanto, los busca en el repositorio de caché central en tu disco. Actualmente, debido a que no tienen cargadores, hacen varios tipos de trucos utilizando enlaces duros para que funcione. Pero si tuvieran cargadores, si fuera ESM nativo, podrían haber modificado la fase de resolución para buscar donde quisieran. Otro ejemplo son los mapas de importación, sobrescribiendo especificadores sin ruta y esto es lo que intentaremos hacer. Escribamos un cargador que haga esto y entenderás qué es en un segundo.

Ahora, ten en cuenta que el código de ejemplo es código de demostración. No lo uses en producción, no tiene manejo de errores, no maneja casos extremos, son solo ejemplos de juguete.

Bien, hablemos de sobrescribir módulos. Este es main.js y estamos importando un módulo para sobrescribir. Un módulo para sobrescribir no existe en ningún lugar en los módulos de Node o en cualquier lugar. Entonces, si lo ejecuto, obtengo el error de módulo no encontrado, obviamente. Pero digamos que tengo un archivo overrides.json que dice que un módulo para sobrescribir realmente existe en .moduleoverride.js y este es moduleoverride.js así que imprimimos en la consola módulo sobrescrito y queremos que esto funcione. Entonces, queremos ejecutar main.js con el cargador. ¿Cómo lo hacemos? Agregamos guión guión cargador y apuntamos al cargador y si lo ejecutamos, boom, funciona. Esta es la sintaxis guión guión cargador igual o espacio, no importa y punto barra cargador.js ten en cuenta que el punto barra es importante. Si dices cargador.js buscará el paquete cargador.js no el archivo cargador.js. Bien, el punto barra es esencial.

Bien, veamos loader.js no te preocupes, iremos uno por uno y lo entenderemos. Este es el cargador, es muy muy pequeño como puedes ver escribir un cargador no es tan difícil. En primer lugar, tenemos que leer el overrides.json así que simplemente lo leemos usando el nivel superior 08 y lo analizamos para obtener el overrides.json. Perfecto, fácil, sin problemas. Ahora exportamos una función esa función debe llamarse resolve porque cuando NodeJS está cargando un cargador busca esa función exportada y recibirá tres parámetros lo veremos en un segundo y es asíncrona por lo que puedes hacer lo que quieras allí no estás limitado a la sincronicidad. Entonces hablemos de los tres parámetros. En primer lugar, el especificador el especificador del módulo es lo que está detrás de las comillas y lo siento dentro de las comillas en nuestro ejemplo un módulo para sobrescribir tal como aparece en el código.

4. Enhancing Loading Phase: HTTP and TypeScript

Short description:

Hablaremos de Rex resolve y lo pasaremos a Node.js. Si el especificador es una anulación, tomamos el especificador de anulaciones y lo pasamos a Node.js. Mejorar la fase de carga implica cargar directamente desde HTTP y cargar código TypeScript sin compilarlo. Cargar desde HTTPS usando ESM.SH nos brinda módulos ESM para todos los paquetes de NPM. Ejecutar el código sin un cargador resulta en un error de esquema de URL no compatible, pero con un cargador, funciona.

El contexto que veremos más adelante tiene todo tipo de cosas pero principalmente hablaremos de Rex resolve si no puedes resolver algo o no quieres resolver y quieres pasarlo a Node.js puedes usar next resolve para resolverlo. Así que veamos el código. Si el especificador es una anulación recuerda que las anulaciones son el archivo JSON entonces si no está en las anulaciones llamamos a next resolve con un especificador. Así que si no sabemos qué hacer con él lo pasamos a Node.js. Fácil, pero si queremos saber qué hacer con él tomamos el especificador de anulaciones así que tomamos lo que sea que esté en las anulaciones y lo pasamos a Node.js. Ahora Node.js no obtendrá el especificador sin formato como el módulo para anular pero obtendrá .slash module overrides.js pero aún lo pasamos a Node.js y boom, ahí lo tenemos. Funciona. Mira qué fácil es escribir un cargador de ASM. Realmente es así de simple. Obviamente, casos extremos, manejo de errores, blah blah blah pero en esencia, eso es todo. Entonces hemos visto la fase de resolución. Hablemos de la fase de carga y cómo anularla.

Así que recuerda que resolver es tomar el especificador y resolverlo a una URL completa y luego leer el archivo es donde estamos hablando de carga. ¿De acuerdo? Entonces, ¿por qué mejorar la fase de carga? Bueno, hay muchos ejemplos. Vamos a hacer dos cosas. Cargar directamente desde HTTP en lugar de desde un archivo y cargar código TypeScript sin compilarlo. Por lo tanto, podremos darle un archivo TS y simplemente funcionará. Hablemos de cargar desde HTTP. De acuerdo, este es el código. Así que estamos cargando desde HTTPS, ESM.SH, lo que sea. ESM.SH, y hay otros por ahí, es un servicio que te brinda módulos ESM de todos los paquetes nativos, todos los paquetes de NPM que existen. Es realmente, realmente, realmente genial. De acuerdo, esto es lo que queremos ejecutar. Si lo ejecutamos así sin un cargador, obtendremos un error de esquema de URL no compatible porque Node.js nos está diciendo, no sé qué hacer con HTTPS. Perfecto. Pero si lo ejecutamos con un cargador, boom, funciona. Estamos muy, muy contentos. Veámoslo, el cargador. En primer lugar, al igual que hay una exportación de carga. Tenemos una exportación, al igual que tenemos una exportación de resolución para la resolución de URL. Oh espera, algo le pasó, me detengo.

5. Loader and Fetching Source Code

Short description:

El cargador en la URL del módulo es simple y tiene una función de carga exportada async. Maneja la resolución de URLs y utiliza fetch para obtener el código fuente. Se siguen las redirecciones y el resultado se devuelve a Node.js.

Sí. No, ya veo lo que es. Es mío, ahí vamos. De acuerdo, era, de acuerdo. Así que esto, sí. Ahí vamos. Este es el cargador. Como puedes ver, es simple. Lo repasaremos uno por uno como antes. Al igual que en el resolutor, el cargador tiene una función de carga que se exporta async. Al igual que el ejemplo. Como el anterior.

Hablemos de la URL del módulo. La URL es la URL del módulo. Observa que esta es la URL del módulo después de la resolución. Por lo tanto, los resolutores han terminado con ella. Obtenemos la URL absoluta completa. El contexto lo veremos más adelante. Y luego la carga siguiente, si no puedes cargar algo, puedes usar la carga siguiente para cargarlo. Por lo general, es la de node.js. De acuerdo. Entonces, si la URL no es una URL HTTP o HTTPS, simplemente la pasamos a la carga siguiente. Muy, muy fácil. Si lo es, usamos fetch. Fetch ahora es nativo de node.js, al igual que en el navegador. Puedes usarlo sin importar nada de node V18, creo, o algo así. Entonces usamos fetch para obtener el código fuente. Seguimos las redirecciones porque esm.sh tiene redirecciones y tenemos el código fuente. ¿Qué hacemos con él? Devolvemos el resultado a node.js. El código fuente del módulo está en source.

6. Formato del módulo y Resolutor

Short description:

Formato del módulo: ESM, common.js, JSON, WASM. HTTPS debe ser un módulo y usar cortocircuito. El resolutor de Node.js arroja un error para HTTPS. Se ha abierto un error y una solicitud de extracción. Necesitamos un resolutor en el cargador HTTP para resolver el problema. Manejar especificadores relativos, absolutos y de osos.

El formato es el formato del módulo. ¿Es un módulo, lo que significa ESM, common.js, JSON, WASM? En este caso, siempre decimos que si proviene de HTTPS, debe ser un módulo. Y cortocircuito. Cortocircuito significa decirle a node.js: mira, no llamamos a la siguiente carga. Sabemos cuál es la fuente. Pero solo para que lo sepas, no llamamos a la siguiente carga y está bien. Si no agregamos cortocircuito verdadero, node.js fallará y dirá: ¿Estás seguro de que no querías llamar a la siguiente carga? Si no lo hiciste, por favor envía cortocircuito verdadero, y luego agregas cortocircuito verdadero, y estás bien.

Entonces, ¿esto funcionará? Veamos. No. Porque esto es, quiero decir, porque el resolutor de node.js arroja un error. Entonces no es el cargador el que dice, no sé qué hacer con HTTPS. Es el resolutor el que dice, no sé qué hacer con HTTPS. Esto es exasperante, en realidad, porque ¿por qué debería importarle? ¿Por qué debería el resolutor decir, no sé qué hacer con HTTPS? Tal vez alguien más quiera saber qué hacer con HTTPS. De hecho, me di cuenta de esto cuando estaba trabajando en esta charla, y abrí un error e implementé una solicitud de extracción. Entonces, en la versión 20 de node, si esta solicitud de extracción se aprueba, no necesitaremos la siguiente fase, la siguiente cosa que soluciona esto, porque el resolutor de node.js, dice, oh, no conozco esta URL, pero está bien. Lo pasaré al cargador. Pero todavía tenemos este problema. Entonces necesitamos un resolutor en el cargador HTTP que resuelva este problema. También tenemos que anular la resolución. Y esto es exasperante, pero así es como es. De acuerdo.

Aquí es donde el código se vuelve interesante. Así que por favor, por favor, por favor, presta atención. Especificadores. Recuerda, estos son especificadores. Nuestro resolutor encontrará tres tipos de especificadores. Especificadores de URL relativa, especificadores de URL absoluta, y lo que se llaman especificadores de osos. Y tendremos que lidiar con todos ellos, al igual que node.js lo hace. Entonces, los relativos son estos tipos de especificadores.

7. Manejo de especificadores de osos en Node.js

Short description:

Los osos son los que están en la parte inferior. Si es un especificador de oso, pásalo a Node.js.

Los osos son los que están en la parte inferior. Y absolutos, sí, teóricamente, alguien puede proporcionarnos una URL absoluta. Entonces, especificadores de osos. ¿Qué hacemos? Dejamos que node lo maneje. No sabemos cómo manejar los especificadores de osos. Entonces, si es un especificador de oso, continuamos con la siguiente resolución. No hay problema con las URL de HTTP, así que podemos dejar que node lo maneje. Y esto es un especificador de oso. Es feo. Tal vez alguien más tenga una mejor manera. Entonces diría, si el especificador comienza con un punto, entonces no es un especificador de oso. De lo contrario, analízalo. Si es una URL, si no es una URL, entonces es un especificador de oso. De lo contrario, es una URL, por lo que no es un especificador de oso. Entonces, si es un especificador de oso, pásalo a Node.js.

8. URLs Relativas y Cargador de TypeScript

Short description:

Para lidiar con las URLs relativas, agregamos la URL del módulo al especificador y lo convertimos en absoluto. Si la URL comienza con HTTP, la devolvemos tal cual. De lo contrario, la pasamos al resolutor de Node.js. Otro cargador es para transpilar TypeScript. Llama a nextload para los archivos .ts, lo pasa a Node.js y transforma el código fuente usando ESBuild.

Ahora necesitamos lidiar con las URLs relativas. ¿Cómo convertimos en absoluto una URL relativa? Tomamos la URL del módulo y la agregamos al especificador y la convertimos en absoluta. Entonces, en este caso, module.js, tenemos la URL absoluta del módulo. Y la convertimos en absoluta para obtener module.js. Podemos hacerlo con una nueva URL en Node.js, muy fácil. Y esto es lo que hacemos. Tomamos el especificador, tomamos context.parentURL, que es donde reside la URL principal, y obtenemos una URL en el resultado. Y esto también se encarga de las URLs absolutas.

Ahora, si la URL comienza con HTTP, no queremos enviarla al resolutor de Node.js porque entonces lanzará un error. Así que simplemente devolvemos la URL tal cual y la cortocircuitamos. Y de lo contrario, si no es una URL HTTP, podemos pasarla al resolutor de Node.js. Esto se encarga del problema con HTTP y resolve. Y listo. El cargador funciona.

Hablemos de otro, transpilando TypeScript. El cargador anterior agregó soporte para cargar otras fuentes. Este cargador es más bien un transformador. Veamos el código TypeScript. Este es un main.ts. Importa desde otro código TypeScript pero también importa desde código JavaScript, y como puedes ver, código TypeScript. Y este es el archivo. Nada muy interesante aquí. Ejecutarlo sin un cargador, ¿obtendremos una extensión de archivo desconocida porque no sabe qué hacer con .ts? Perfecto. Ejecutarlo con el cargador funcionará. Veamos cómo funciona un cargador de TypeScript. Si la URL termina con .ts, en primer lugar, llama a nextload. Dice, no sé cómo cargar el archivo. Lo pasaré a Node.js. Node.js cargará el archivo y nos devolverá el código fuente. Una vez que tenemos el código fuente, podemos transformarlo usando ESBuild.

9. Encadenamiento de Cargadores para HTTP y TypeScript

Short description:

Puedes usar cualquier transpilador, pero mi elección preferida es ESBuild debido a su simplicidad. Solo requiere alrededor de 10 líneas de código para la transpilación. Hemos visto tres cargadores: uno para anular módulos, y dos para cargar HTTP y transpilar TypeScript. Estos cargadores se pueden encadenar importando los módulos necesarios y agregándolos en el orden deseado. Al especificar las URLs como HTTP en las anulaciones, podemos usar especificadores simples y lograr una carga y transpilación exitosas.

Puedes usar cualquier transpilador que desees. Yo uso ESBuild porque es fácil. Obtén el nuevo código y devuélvelo como este código transpilado con return source y format. Muy, muy fácil, y listo, obtienes la transpilación con alrededor de 10 líneas de código. Muy fácil.

Mira ts-node.js. Hace lo mismo, pero de manera robusta puedes ver que tiene cientos de líneas de código. Pero en esencia, está haciendo lo que mostré anteriormente.

Ok. Hemos visto tres cargadores. Uno que anula módulos. Realiza la fase de resolución. Y dos, la fase de carga, HTTP y transpilación de TypeScript. ¿Podemos encadenar cargadores? ¿Podemos agregarlos uno tras otro? Y la respuesta es absolutamente.

Entonces, hagamos los cargadores de HTTP y TypeScript juntos. Importo HTTP, pero uno de ellos es un código TypeScript. Y quiero que los dos cargadores lo hagan funcionar. Como puedes ver, estamos usando HTTP y estamos usando TypeScript. Y estos son los módulos, nada interesante aquí. Pero agreguemos la anulación.

Ok, en lugar de proporcionar la URL completa, simplemente daremos especificadores simples, A y B, y especificaremos en las anulaciones que las URLs son URLs HTTP. Agregamos los cargadores con múltiples. Observa las comas entre ellos. También podemos usar --loader, cargador HTTP, --loader, cargador TS, --loader, cargador de anulación. Lo mismo. Los agregamos juntos y, listo, funciona. Veamos cómo porque esto es interesante. Observa el orden, cargador HTTP, cargador TS, cargador de anulación. En primer lugar, realiza la resolución. La resolución recibe un especificador y devuelve una URL, si recuerdas.

10. Funcionalidad del Cargador y Futuro

Short description:

El cargador HTTP llama al cargador de anulación, que llama al último cargador. El resolutor de anulación lee overrides.json y lo pasa al siguiente cargador. El resolutor HTTP maneja los especificadores HTTP, mientras que el resolutor de NodeJS absolutiza todo. Los cargadores mejoran la resolución de URL y la carga de archivos. Pueden cargar desde diferentes fuentes, transformar el código fuente y resolver las URL de manera diferente. Un cargador tiene funciones de resolución y carga. Para usar un cargador, usa --loader. El futuro de las mejoras en la carga de módulos es prometedor y fácil de usar.

Así que nota que el cargador HTTP es el primero, pero llamará al cargador de anulación. Llamará al último cargador. ¿Por qué? Porque el resolutor de anulación, perdón, resolutor de anulación, cuando dice siguiente resolución, llamará a la resolución HTTP. Y cuando la resolución HTTP llama a la siguiente resolución, llamará a la resolución de NodeJS. Entonces, el resolutor de anulación lee el archivo overrides.json y resuelve a través de overrides.json y lo pasa al siguiente cargador. Y este resolutor HTTP, si recuerdas, pasa los especificadores que no son HTTP a NodeJS y maneja los especificadores HTTP por sí mismo. El resolutor de NodeJS absolutiza todo y lo pasa, y boom, obtenemos la URL. Los cargadores, lo mismo. Llamará al último cargador, este es el cargador de TS lo pasará al cargador HTTP, que pasa a NodeJS, etc. etc. El cargador HTTP buscará las URL de HTTP y pasará las URL que no son de HTTP, y boom, funciona. Ahora, mi tiempo es corto, así que omitiré esto, pero puedes ver todo en mi presentación. Pero en realidad puedes usar cargadores con APIs, así que especifica un cargador que también tenga una API. Es un escenario más advanced , no se usa mucho, pero puedes hacerlo. Ok, resumamos. Resumamos. Los cargadores mejoran estas dos fases, no la fase de ejecución, sino la resolución de la URL, que es encontrar dónde está el módulo y leer la URL, o lo que llamamos cargar el archivo. Ok, los cargadores se pueden usar para cargar desde diferentes fuentes, transformar el código fuente, transformar las URL resueltas y resolver las URL de manera diferente. Muchos usos para eso. Un cargador siempre tiene al menos, bueno, no al menos. Como máximo, dos funciones de exportación, resolución y carga. Puede tener solo una de ellas. Una se encarga de la resolución, que toma un especificador y lo resuelve a una URL. Puede usar la siguiente resolución en la cadena si no sabe qué hacer con algo. Y la carga toma la URL, la URL resuelta, y devuelve el código fuente, y si quiere, puede usar la siguiente carga para cargarlo. Para usar un cargador, usa --loader. Puedes encadenarlos, lo cual es genial, y para comunicarte bien, eso es algo que pasamos. Puedes comunicarte con el cargador usando varios métodos. Y el futuro es brillante. Finalmente tenemos una forma formal de hacer mejoras en la carga de módulos. Ha resistido la prueba del tiempo. Aún es experimental, así que pueden ocurrir cambios pequeños. Ten cuidado. Es muy fácil de usar, y se puede utilizar en una gran variedad de casos de uso. Muchas gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Top Content
Almost every developer thinks that adding one more log line would not decrease the performance of their server... until logging becomes the biggest bottleneck for their systems! We created one of the fastest JSON loggers for Node.js: pino. One of our key decisions was to remove all "transport" to another process (or infrastructure): it reduced both CPU and memory consumption, removing any bottleneck from logging. However, this created friction and lowered the developer experience of using Pino and in-process transports is the most asked feature our user.In the upcoming version 7, we will solve this problem and increase throughput at the same time: we are introducing pino.transport() to start a worker thread that you can use to transfer your logs safely to other destinations, without sacrificing neither performance nor the developer experience.
Node Congress 2023Node Congress 2023
30 min
Building a modular monolith with Fastify
In my journey through Nodeland, I saw most teams struggling with the free-form nature of Node.js development: there are no guardrails for maximum flexibility. Yet, not all paths offer a smooth ride.
How to build applications that are well-organized, testable, and extendable? How could we build a codebase that would stand the test of time?
In this talk, we will explore how to avoid the trap of Singletons to create robust Node.js applications through the use of Fastify plugins: we will build a modular monolith!

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.