El Estado del Núcleo de Node.js

Rate this content
Bookmark

Node.js, como plataforma, está en constante cambio y evolución. El núcleo de Node es una mezcla de características de nuestra propia comunidad, así como de dependencias como V8 y libuv. Esta charla cubrirá los últimos desarrollos en el núcleo de Node.

24 min
18 Apr, 2023

Video Summary and Transcription

La charla de hoy discutió el estado del núcleo de Node.js, con descargas crecientes y más de 2 millones de paquetes en npm. Node.js tiene un programa LTS, con Node 14 actualmente en modo de mantenimiento. Se recomendó apuntar a Node 18, ya que Node 16 y su versión de OpenSSL pronto llegarán al final de su vida útil. Node 18, conocido como Hydrogen, es estable y tiene nuevas características. La charla también cubrió pruebas de CLI, módulos principales, nuevas características y mejoras próximas.

Available in English

1. Node.js Core State and LTS

Short description:

Hoy voy a hablar sobre el estado del núcleo de Node.js. El número de descargas desde nodejs.org sigue aumentando. npm es el único gestor de paquetes con más de 2 millones de paquetes. Node tiene un programa de soporte a largo plazo conocido como LTS. Lanzamos nuevas versiones en abril y octubre. Node 14 está actualmente en modo de mantenimiento.

Hola a todos, gracias por venir a mi charla. Hoy voy a hablar sobre el estado del núcleo de Node.js. Para empezar, quiero mostrar algunas métricas de descarga. Estas métricas son de los últimos dos años aproximadamente y se puede ver que el número de descargas desde nodejs.org sigue aumentando, con la excepción de dos grandes caídas de tráfico relacionadas con las vacaciones de Navidad y cosas así, pero sí, Node sigue en aumento. A continuación, quiero hablar sobre el ecosistema, así que esta es una gráfica de modulecounts.com que compara el tamaño del ecosistema de npm con otros registros de paquetes populares para cosas como Rust, Java y Ruby, entre otros. Esto no representa necesariamente el núcleo de Node, sino el ecosistema más grande. npm es el único gestor de paquetes en esta gráfica que tiene más de 2 millones de paquetes. JavaScript es, con mucho, el ecosistema más grande del mundo, y esto viene con algunas advertencias, ya que npm también aloja cosas que no son solo módulos de Node.js, así que hay otras cosas allí. No todos los módulos son de gran calidad, pero hay algunos paquetes realmente buenos. También hay otros que probablemente no se usan mucho o no deberían usarse mucho, pero en general, creo que esto representa bastante bien la salud del ecosistema.

A continuación, quiero hablar sobre el programa de soporte a largo plazo de Node, también conocido como LTS. En 2015, Node creó un plan de LTS para equilibrar a los individuos y desarrolladores que desean incluir la mayor cantidad de características posible con los usuarios empresariales, que valoran la estabilidad a lo largo de los años, no solo días o semanas. Creamos este plan donde dos veces al año, en abril y octubre, lanzamos una nueva versión principal del proyecto. Puedes ver aquí en la gráfica en la parte superior, la barra inestable etiquetada como Main. Ahí es donde se realiza todo el desarrollo activo del proyecto. Parches, nuevas características, cambios rompedores, todo se incluye en la rama principal. Luego mantenemos varias ramas de lanzamiento a las que seleccionamos confirmaciones cada vez que hacemos un lanzamiento. Ahora mismo tenemos las versiones 14, 16, 18, 19 y 20 de Node como ramas de lanzamiento activas o próximas. Este año en abril, lanzaremos la versión 20, y luego en octubre lanzaremos la versión 21. Así que hacemos lanzamientos con números impares en octubre y lanzamientos con números pares en abril. La última versión principal se convierte en lo que llamamos la línea de lanzamiento actual durante seis meses. Ahora mismo, la versión 19 de Node es la versión actual, y después de ese período de seis meses, si es una versión con número impar, pasará a un período de mantenimiento abreviado donde recibirá cosas como correcciones de seguridad, pero es más bien un período de gracia para que las personas migren, mientras que las versiones con números pares pasan a lo que llamamos LTS activo durante un año, y en LTS activo, aún obtienes todo, excepto los cambios rompedores que se incluyen en la línea de lanzamiento actual, pero los mantenemos en la línea de lanzamiento actual durante unas semanas para asegurarnos de que sean estables y no haya grandes regresiones, y luego los retrocedemos. Obtienes los mismos cambios, pero a un ritmo más lento y con una mayor garantía de estabilidad. Después de esos 12 meses, las versiones con números pares pasan al modo de mantenimiento durante 18 meses, esto es para dar tiempo suficiente a las grandes empresas y demás para migrar a la próxima línea de lanzamiento que van a utilizar. Así que esta es una descripción general de todas las líneas de lanzamiento en este momento.

A continuación, quiero profundizar en cada línea de lanzamiento individualmente y ver qué está sucediendo allí. Node 14 está actualmente en modo de mantenimiento. Se le asigna el nombre en código Firmium, así que todas las versiones LTS se les asigna un elemento de la tabla periódica, en este caso Firmium. Creo que comenzamos con Argon y Node 4, Boron y Node 6, y así sucesivamente. Algunas letras no tienen elementos de la tabla periódica, en ese caso simplemente inventamos algunos.

2. Node.js Core Versions and Recommendations

Short description:

Volviendo a Node 14, llegará al final de su vida útil a finales de abril. Recomiendo apuntar a Node 18 si es posible. Node 16 es conocido con el nombre en código gallium. La versión de OpenSSL que se incluye con Node 16 también llegará al final de su vida útil. Si estás migrando desde Node 14, no vayas a la versión 16. Si estás utilizando la versión 16, comienza a apuntar a Node 18. Node 18 se conoce con el nombre en código Hydrogen. Actualmente es una LTS activa y pasará a mantenimiento en octubre de este año. Node 18 es muy estable y tiene muchas características que no están en Node 14 y 16. Node 19 no tiene un nombre en código de elemento de la tabla periódica porque nunca será LTS. Fue lanzado originalmente en octubre de 2022. No entrará en LTS activa y no recomiendo usarlo en producción.

Eso es solo un dato curioso. Volviendo a Node 14, llegará al final de su vida útil a finales de abril, por lo que probablemente puedes esperar 1 o tal vez 2 lanzamientos más entre ahora y entonces, pero si estás utilizando Node 14, realmente necesitas comenzar a migrar ahora.

Recomiendo apuntar a Node 18 si es posible, y la razón de eso es que Node 16 también llegará al final de su vida útil este año. Node 16 es conocido con el nombre en código gallium. Debería haber llegado al final de su vida útil en abril de 2024, pero solo será compatible hasta septiembre de 2023. Hay una diferencia de 7 meses, pero hay una buena razón para ello. La versión de OpenSSL que se incluye con Node 16 también llegará al final de su vida útil, por lo que como proyecto, tuvimos que equilibrar si queríamos seguir admitiendo Node 16 solo porque sí, o dejarlo desaparecer en lugar de pedir a las personas que ejecuten lo que podría ser una versión posiblemente insegura de OpenSSL cuando llegue al final de su vida útil.

He vinculado la publicación oficial del blog en la parte inferior de la diapositiva aquí, si deseas más detalles. Pero en general, solo recomendaría que si estás migrando desde Node 14, no vayas a la versión 16. Si actualmente estás en la versión 16, comienza a apuntar a Node 18.

A continuación, quiero hablar brevemente sobre Node 18. Node 18 se conoce con el nombre en código Hydrogen. Actualmente es una LTS activa y pasará a mantenimiento en octubre de este año. Una vez que esté en mantenimiento, se admitirá con parches de seguridad y cosas así hasta abril de 2025. Node 18 es muy estable en este momento y en realidad tiene muchas características que no están en Node 14 y 16. Personalmente, esto es lo que recomendaría utilizar en producción. Esto es lo que estoy usando en producción en el trabajo. Como dije, es muy estable y definitivamente es lo que debes apuntar ahora.

Siempre habrá personas que quieran utilizar las últimas y mejores cosas en producción. En este momento, eso sería Node 19. Node 19 no tiene un nombre en código de elemento de la tabla periódica porque nunca será LTS. Fue lanzado originalmente en octubre de 2022. Seguirá siendo la línea de lanzamiento actual hasta abril de 2023. En ese momento, tendrá algunos meses de soporte de mantenimiento y llegará al final de su vida útil en junio de 2023. Como mencioné, no entrará en LTS activa. No recomiendo usarlo en producción. En el pasado, tuvimos muchos casos en los que la línea de lanzamiento actual tenía regresiones que no se incluían en LTS. Eso ya no es tanto el caso. Las versiones con números impares parecen ser cada vez más estables, lo cual es bueno. Pero aún así no lo recomendaría para producción.

3. Node.js Versiones de Lanzamiento y Recomendaciones LTS

Short description:

Hay un cambio notable en esta línea de lanzamiento. Se eliminaron las sondas de diagnóstico dTRACE, SystemTap y ETW. Node 14 está pasando a modo de mantenimiento, mientras que Node 16 sigue en aumento. Node 18 está ganando terreno lentamente, mientras que Node 19 no ha tenido mucho éxito. Se recomienda ejecutar una versión LTS en producción y considerar la facilidad de actualizaciones y la necesidad de nuevas características. A continuación, hablaré sobre las nuevas características en Node a través del proyecto V8.

Hay un cambio notable en esta línea de lanzamiento. Se eliminaron las sondas de diagnóstico dTRACE, SystemTap y ETW. La razón de esto es simplemente que Node es un proyecto de código abierto dirigido principalmente por voluntarios. Nadie se ofreció como voluntario o se hizo cargo de mantener esos fragmentos de código. Se estaban convirtiendo en una carga de mantenimiento y se eliminaron. Hay un problema abierto invitando a cualquier persona que se sienta fuertemente acerca de estas cosas a que venga y las apoye nuevamente, pero por ahora, no están en la base de código.

Similar al gráfico que mostré al principio, este es un desglose de las descargas por diferentes líneas de lanzamiento de Node en los últimos dos años. La barra azul, que comienza en el extremo izquierdo y luego disminuye a medida que pasa el tiempo, es Node 14. Ese es el comportamiento esperado y lo que queremos ver. Las descargas aumentaron y luego pasó a modo de mantenimiento y comenzaron a disminuir. De manera similar, Node 16, que es la barra naranja, todavía está en proceso de aumentar y avanzar hacia la derecha. Espero que las personas, y parece que la tendencia ya está comenzando en este gráfico, comiencen a migrar de la versión 16 a Node 18. Node 15 y 17 no se muestran en este gráfico porque ya habían alcanzado el final de su vida útil cuando se compiló este gráfico. Luego, puedes ver la línea amarilla de Node 18 comenzando a ganar impulso un poco más de la mitad del gráfico y está aumentando lentamente. Como dije, si volvemos a hacer este gráfico en unos meses, imagino que Node 18 será considerablemente más alto, con suerte más que Node 16. Y luego, la pequeña parte verde en el extremo derecho es Node 19. Puedes ver que llegó al mundo más tarde que todas las demás líneas de lanzamiento. No ha tenido tanto éxito y espero que también veamos que comienza a desaparecer.

Entonces, si quieres elegir qué versión ejecutar en producción, ya he insinuado esto, pero definitivamente deberías ejecutar una versión LTS en producción, especialmente si Node es crítico para la misión, si estás ganando dinero con Node.js en producción, entonces quieres ser lo más estable posible. También debes preguntarte si puedes actualizar fácil y frecuentemente. Estar en la vanguardia implica que puede haber problemas. Si insistes en ejecutar Node 19 en producción, asegúrate de poder actualizar fácilmente porque las cosas se mueven mucho más rápido allí. Y luego, realmente debes preguntarte si realmente necesitas todas las características más nuevas. Algunas personas realmente las necesitan, pero muchas veces la respuesta es no. No necesitas estrictamente las cosas más nuevas y puedes esperar unos meses. Estas son solo recomendaciones. Puedes hacer lo que quieras, pero así es como recomendaría proceder.

A continuación, quiero hablar sobre algunas de las nuevas características que han llegado a Node a través del proyecto V8. La forma en que funcionan las cosas es que cuando hay una nueva característica de JavaScript, TC39 crea una especificación para ella. Los implementadores de navegadores o motores de JavaScript como V8 realmente desarrollarán las nuevas características y una vez que Node.js se actualice a una versión de V8 que incluya esas características, las recibiremos automáticamente.

4. Nuevas características y mejoras de Node.js

Short description:

Una de las cosas que agregamos en Node es habilitar los reinos sombreados, que permiten ejecutar código en su propio reino. También tenemos nuevos métodos de matriz, adiciones y mejoras en la API, mejoras de rendimiento relacionadas con los campos y métodos de clase, integración de promesas de JavaScript para WebAssembly y compatibilidad con las API de la plataforma web. Node 18 también incluye un ejecutor de pruebas incorporado.

Una de las cosas que tuvimos que agregar en Node es habilitar los reinos sombreados. Los reinos sombreados son la solución oficial del lenguaje para cosas como el módulo VM de Node, para poder ejecutar código en su propio reino, enviar entradas y obtener salidas. Es similar a VM, pero un poco más seguro que Eval, pero como aún está detrás de una bandera experimental en V8, tuvimos que agregar una bandera experimental en Node para desbloquear esas características.

También tenemos un par de nuevos métodos en las matrices. find last y find last index son similares a find y find index, pero comienzan desde el final de la matriz en lugar del principio. Se han realizado varias adiciones y mejoras en la API. Si estás utilizando las API de internacionalización, se ha mejorado la localización y se han agregado el formato de número y los valores admitidos en el método. También ha habido algunas mejoras de rendimiento relacionadas con los campos y métodos de clase. Por lo general, cuando se agregan nuevas características a V8, no están completamente optimizadas. Entonces, los campos y métodos de clase llegaron a V8, tuvimos acceso a ellos en Node, pero evitamos usarlos porque eran más lentos que las alternativas que utilizaban símbolos y otras cosas. Pero el rendimiento ha mejorado y ahora podemos recomendar completamente su uso en tu código.

Y luego, algo importante que ha llegado recientemente es la integración de promesas de JavaScript. Esto se dirige específicamente a las personas que utilizan WebAssembly. La forma en que generalmente funcionaba era que llamabas desde tu código JavaScript a WebAssembly y WebAssembly realizaba alguna operación sincrónica. Si necesitaba alguna funcionalidad personalizada, podías llamar de vuelta a JavaScript. Pero no había una forma real de tener una integración asíncrona entre JavaScript y WebAssembly. Con tantas de las nuevas API de JavaScript basadas en promesas o simplemente asíncronas en general, había una especie de desconexión. Esto es realmente una gran mejora en la calidad de vida para las personas que utilizan WebAssembly y Node.

A continuación, quiero destacar algunas de las API que hemos obtenido basadas en la compatibilidad con la plataforma web. Node intenta admitir, cuando tiene sentido, muchas de las mismas API que se pueden obtener en un navegador. Una de las más importantes que las personas han estado esperando durante años es Fetch. El proyecto finalmente logró hacer que Fetch sucediera. Junto con Fetch, también se agregaron muchas otras API como Request, Response y FormData. Tenemos Web Streams, que son la respuesta del navegador a las transmisiones de Node.js. Actualmente, no están altamente optimizados en Node, pero están mejorando poco a poco. Tenemos Web Crypto, Structured Clone, que es muy útil para poder copiar objetos. No voy a enumerar todas las cosas diferentes aquí, pero constantemente estamos tratando de mejorar nuestra compatibilidad con la plataforma web.

Otra característica importante que se implementó en Node 18 es un ejecutor de pruebas incorporado. Hay algunas formas de usar el ejecutor de pruebas. Existe el módulo de pruebas node:test dentro de Core que puedes requerir.

5. Node.js CLI Runner y Módulos Core

Short description:

Hay un ejecutor de línea de comandos (CLI) para pruebas en Node.js. Admite subpruebas, saltar pruebas, especificar solo pruebas, ganchos del ciclo de vida y simulación. Tiene cobertura de código incorporada y permite reportes personalizados. El reporte predeterminado es TAP, pero puedes usar SPEC para un formato más legible para humanos. Los módulos principales solo con prefijo 'node-' permiten identificar fácilmente los módulos principales.

También hay un ejecutor de línea de comandos (CLI), que se habilita con guión, guión, prueba. Y si estás utilizando una versión anterior de Node que, ya sabes, no se ha adaptado a esto, como por ejemplo, actualmente Node 14 no tiene soporte para ello.

Algunas personas amables tomaron el código de Core, lo pusieron en un paquete en npm, y puedes instalarlo desde allí y obtener casi todas las mismas funcionalidades. Por lo tanto, admite muchas de las cosas que esperarías que un ejecutor de pruebas, soporte de pruebas, admita de forma predeterminada.

Por lo tanto, tiene subpruebas. Puede saltar pruebas. Puedes especificar solo pruebas, por lo que solo quieres ejecutar un subconjunto de tu conjunto de pruebas. Ganchos del ciclo de vida, como antes, antes de cada uno, después y después de cada uno, y cosas así. Y también admite simulación de forma predeterminada.

Actualmente no admite la simulación de módulos completos. Debido a algunas limitaciones en los módulos ES. Pero puedes simular funciones, métodos y cosas así. Tiene cobertura de código incorporada de forma predeterminada, que puedes habilitar con la bandera --experimental-test-coverage del CLI. Y ahora también puedes generar tus propios reportes personalizados.

Por lo tanto, hay algunos que están integrados en Node. De forma predeterminada, será TAP, que significa Protocolo de Prueba de Cualquier Cosa, que es un formato para expresar resultados de pruebas, que se utiliza, entre otros ecosistemas, no solo en Node.js. Y eso se enviará a través de la salida estándar, pero puedes personalizarlo. Puedes usar SPEC, que es un formato más legible para humanos. TAP, el formato pequeño donde solo se muestran puntos con X. No sé cómo se llama eso. Y luego puedes usar la bandera de destino del reporte de prueba, donde puedes decir dónde quieres que se envíen tus resultados. Por defecto, es la salida estándar, pero puedes usar la salida de error estándar y otras cosas.

Esto es solo una imagen rápida de cómo se ve una prueba. Admitimos pruebas sincrónicas, pruebas asincrónicas, devoluciones de llamada, etc. A la izquierda, aquí está lo que obtendrías si ejecutases la prueba anterior y generases la salida TAP. A la derecha está lo que obtienes con el reporte SPEC. Si quieres colores y cosas que sean un poco más amigables para los humanos, puedes usar eso.

Del TestRunner también surgió otra nueva característica llamada módulos principales solo con prefijo 'node-'. La diferencia aquí, si miras en la parte superior, estamos importando node:test y node:assert. Cada módulo principal se puede importar usando el prefijo 'node:', y eso es bueno porque permite que las herramientas y las personas que leen el código lo sepan.

6. Módulos Core de Node.js y Nuevas Características

Short description:

Puedes importar módulos core sin el prefijo 'node'. Hay un modo de observación similar a nodemon. util.parse.args es una API simple para analizar indicadores de línea de comandos. El soporte para aplicaciones ejecutables individuales permite distribuir binarios de Node.js. Se ha implementado un sistema de permisos para restringir el acceso al sistema de archivos y a los procesos secundarios. Otros cambios destacados incluyen el soporte de 'happy eyeball' y ayudantes de streams.

justo al principio cuando algo es un módulo core. En la parte inferior, también puedes importar el módulo assert y todos los demás módulos coremodules sin el prefijo 'node', pero con TestRunner, y probablemente con todos los futuros módulos coremodules, eso no es el caso. Node-test te dará el módulo core, just-test intentará cargar desde el código de usuario, así que módulos node y cosas así. Es una distinción importante a tener en cuenta, especialmente a medida que potencialmente habrá más módulos coremodules que sigan este patrón. Ahora también tenemos un modo de observación, por lo que es muy similar a nodemon. Si has usado ese indicador de línea de comandos --watch, observará todos tus archivos importados, y cuando alguno de ellos cambie, reiniciará Node. Está integrado con TestRunner, por lo que puedes ejecutar tus pruebas, hacer algunos cambios y luego volverá a ejecutar tus pruebas por ti. Y puedes personalizarlo con el indicador --watch-path para especificar qué archivos realmente quieres observar, aunque esto está limitado a macOS y Windows. También está util.parse.args. Esta es una API simple para analizar indicadores de línea de comandos y devolverlos en una estructura de datos. Esto se estabilizará en node 20, por lo que es algo con lo que debes estar familiarizado. Una cosa menos en la que tienes que depender de NPM. Recientemente, hemos agregado soporte para aplicaciones ejecutables individuales. Esto te permite inyectar tu código de aplicación en un binario de Node.js, y luego puedes distribuir ese binario en sistemas que no tienen Node o NPM instalado. Actualmente, solo se admite un archivo común JS, pero puedes, ya sabes, usar un bundler o algo así para crear ese archivo común JS y luego empaquetar toda tu aplicación de esa manera. El proyecto Node tiene un módulo auxiliar para esto llamado postject, que está disponible en NPM. Fue amablemente donado por la gente de Postman Labs. Hay herramientas similares disponibles, pero el proyecto no prueba oficialmente ninguna de ellas. También hemos agregado recientemente un sistema de permisos. Para habilitarlo, se usa el indicador --experimental-permission. Una vez habilitado, restringe el acceso al sistema de archivos, a los procesos secundarios y a los marcadores, y luego hay varios indicadores a continuación que puedes usar para desbloquear todo o partes de esas cosas. Se admiten comodines, por lo que puedes decir allow FS read star, y eso te permitirá leer cualquier cosa del sistema de archivos. También puedes usar la API programática dentro de tu código. Por ejemplo, process.permission.has, puedes verificar si tienes un permiso específico, y luego puedes, ya sabes, denegar cosas adicionales en tiempo de ejecución. No hay forma de volver a permitirlas. Tiene sentido porque no querrías permitir que las personas se otorguen más permisos, pero siempre puedes verificar qué permisos tienes actualmente, y puede ser un poco más granular. Aquí puedes ver que hemos deshabilitado los derechos del sistema de archivos para un directorio específico. Aún tenemos acceso general al sistema de archivos, pero no a ese directorio específico es lo que este ejemplo está transmitiendo. También ha habido otros cambios destacados recientemente. Soporte de 'happy eyeball', que te permitirá hacer resolución DNS con IPv4 y v6 al mismo tiempo. Ayudantes de streams para convertir entre streams de Node y streams web y cosas así.

7. Pruebas de Snapshot y Enlaces Importantes

Short description:

Teníamos pruebas de snapshot, pero se eliminaron debido a la insatisfacción con la implementación. Las próximas características incluyen la interfaz de función extranjera, una mejor integración con TypeScript, soporte de proxy para fetch y mejoras en los módulos core. Se proporcionan enlaces importantes para informes de errores, preguntas de soporte, calendario de lanzamientos y vulnerabilidades de seguridad. Únete a la comunidad de OpenJS Foundation en Slack para discusiones sobre el proyecto. Se hace una mención a Platformatic, una empresa que simplifica la creación de API con Node.js.

No voy a mencionar todos ellos, nuevamente por falta de tiempo, pero vale la pena señalar que teníamos pruebas de snapshot, el assert.snapshot, pero la gente no estaba realmente satisfecha con la implementación, así que lo hemos eliminado y esperamos revisarlo para refinarlo un poco más.

Algunas características potenciales próximas, recientemente se abrió una solicitud de extranjero interfaz de función o FFI para el core. Actualmente, las personas están trabajando en soluciones para una mejor integración con TypeScript, agregando soporte de proxy a fetch y con suerte prometiendo más mejoras en los módulos core, solo quedan unos pocos en este momento. Nuevamente, todas estas son cosas futuras que pueden o no suceder, así que creo que probablemente sucederán, pero no quiero hacer promesas que no pueda cumplir. Y por último, quería mencionar algunos de los enlaces importantes relacionados con el proyecto, por lo que si tienes un informe de error o una solicitud de función, ve a nodejs slash node en GitHub. Si tienes una pregunta de soporte, puedes crear una discusión o ir a nodejs slash help. Si estás interesado en el calendario de lanzamientos, algunas de las cosas que mencioné anteriormente en esta charla, nodejs slash release tiene todos los detalles. Si tienes una vulnerabilidad de seguridad que encontraste, por favor repórtala en HackerOne con el enlace aquí, no la informes en el rastreador de problemas público. Y finalmente, nodejs está activo en la comunidad de OpenJS Foundation en Slack, por lo que hay un enlace aquí donde puedes unirte a Slack. Nodejs y nodejs slash core son los canales principales donde se discute el proyecto. Y eso es todo de mi parte. Solo quería hacer una mención a la empresa para la que estoy trabajando actualmente, Platformatic, que ayuda a simplificar la creación de API con Node.js mucho más fácil para las API REST, GraphQL, Metrix, todas las cosas que son un poco indiferenciadas, estamos tratando de hacerlas más simples para todos. Y eso es todo lo que tengo. Gracias nuevamente por venir a mi charla.

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 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
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.

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.