¿Podemos duplicar el rendimiento del cliente HTTP?

Rate this content
Bookmark

El cliente HTTP de Node.js es una parte fundamental de cualquier aplicación, sin embargo, muchos piensan que no se puede mejorar. Tomé esto como un desafío y ahora estoy listo para presentar un nuevo cliente HTTP para Node.js, undici, que duplica el rendimiento de tu aplicación. La historia detrás de esta mejora comienza con el nacimiento de TCP/IP y está arraigada en una de las limitaciones fundamentales de las redes: el bloqueo de cabeza de línea (HOL blocking). El bloqueo de cabeza de línea es uno de esos temas que los desarrolladores ignoran felizmente y, sin embargo, afecta profundamente la experiencia de tiempo de ejecución de las aplicaciones distribuidas que construyen todos los días. Undici es un cliente HTTP/1.1 que evita el bloqueo de cabeza de línea utilizando keep-alive y pipelining, lo que resulta en una duplicación del rendimiento de tu aplicación.

20 min
24 Jun, 2021

Video Summary and Transcription

La charla de hoy trata sobre los clientes HTTP, servidores, microservicios y la maximización del rendimiento en Node.js. Cubre temas como TCP, latencia, HTTP Keep-Alive, pipelining, el bucle de eventos de Node.js, tiempos de espera e introduce la biblioteca Undici. El orador enfatiza la importancia de reutilizar conexiones, minimizar el bloqueo y utilizar benchmarks para medir el impacto en el rendimiento. Undici se destaca como un nuevo cliente para Node.js que elimina la necesidad de múltiples agentes y ofrece opciones de configuración fáciles.

Available in English

1. Introducción a HTTP y Node.js

Short description:

Hoy voy a hablar sobre clientes HTTP, servidores y cómo mejorar el rendimiento de nuestro cliente HTTP en Node.js. Tengo un buen entendimiento de las necesidades de los usuarios y mantengo Node.js. Como parte de mi trabajo, trabajo con servidores en la nube y tengo experiencia en la construcción de aplicaciones rápidas y escalables en Node.js. También soy coautor de Fastify.

Hola a todos. Soy Matteo Collina y hoy voy a hablarles sobre HTTP. clientes, servidores, tal vez microservicios un poco, y cómo podemos duplicar o incluso triplicar el rendimiento de nuestro cliente HTTP en Node.js.

Primero, un poco sobre mí, soy Matteo Collina. Soy parte del comité técnico de Node.js. Soy el co-creador del framework web FASTI5 y PinnoLogger. Soy arquitecto de software y consultor de profesión, y, ya saben, soy director técnico en NearForm. Síganme en Twitter en Matteo Collina.

Así que un par de notas. También tengo tal vez 6 mil millones de descargas en NPM durante todo el 2020. No sé. Me quedé totalmente asombrado por esto. Tal vez sé de lo que estoy hablando, tal vez no. Tú decides lo que quieras creer.

Entonces, lo que hago normalmente es ayudar a las empresas a construir aplicaciones rápidas y escalables en Node.js. Esto es una de las cosas clave de lo que hago como parte de mi trabajo. También soy parte de los mantenedores de Node.js y una parte clave de su ecosistema con 6 mil millones de descargas al año. Probablemente tengo una buena comprensión de las necesidades de nuestros usuarios y de lo que se quejan, y así sucesivamente. Necesito equilibrar todo el tiempo esas dos cosas. Por un lado, ayudar a nuestros clientes y por otro lado, mantener Node.js. Esto me da mucha perspectiva sobre lo que puedo hacer, lo que necesito hacer para el desarrollo de aplicaciones en Node.js si es un ecosistema. Así que las dos partes de mi trabajo se refuerzan mutuamente hasta cierto punto.

Como parte de mi trabajo, la mayor parte del tiempo trabajo con servidores en la nube. Entonces hay un cliente, típicamente un navegador web o una aplicación móvil que se comunica con la nube y, específicamente, con un servidor, que puede ser múltiples instancias, pero sigue siendo lo mismo que se ejecuta. Es lo que llamamos un monolito en este momento. Saben, también escribí— Como dije, soy coautor de Fastify, así que aquí va un poco de publicidad. Usen esta cosa. En realidad funciona muy bien. Esta tarea no está actualizada. Ah, lo siento.

2. Introducción a Microservicios y Node Core HTTP

Short description:

Esta parte discute el uso de un servidor web rápido y un marco de trabajo para Node.js, que es adecuado para construir aplicaciones pequeñas y grandes, incluyendo monolitos y microservicios. El orador destaca la necesidad de los microservicios para escalar equipos y evitar responsabilidades superpuestas. También abordan el problema de la comunicación excesiva en los sistemas de microservicios y enfatizan la importancia de la comunicación entre los microservicios. El orador luego presenta el Node Core HTTP como el enfoque de la presentación, explicando su papel como respaldo para los clientes HTTP populares. Discuten el proceso de creación de un socket TCP y la latencia potencial involucrada. Además, mencionan el concepto de la ventana de congestión para los nuevos sockets.

Entonces, básicamente, este es un servidor web muy rápido, un marco de trabajo para Node.js. Puedes construir aplicaciones pequeñas y grandes con esto, y funciona muy bien tanto para monolitos como para microservicios.

Ahora, ¿por qué necesitarías microservicios? Porque necesitas escalar equipos. Los microservicios son una forma clara de escalar equipos para que puedas tener diferentes equipos que mantengan diferentes partes de tu sistema y evitar que se superpongan entre sí. Es realmente genial.

Sin embargo, uno de los problemas de los sistemas de microservicios es su comunicación excesiva. De hecho, todos los microservicios se comunican mucho entre sí, y necesitas llamar a datos que son administrados por otros microservicios. Así que hay mucha comunicación entre los diversos microservicios. A veces, alguien lo llama una malla de microservicios. Y en lo que nos vamos a enfocar la mayor parte del tiempo en esta presentación es en este enlace entre microservicios. He estado investigando este problema durante tres, cuatro, cinco años, algo así. Ha estado madurando en mi cabeza durante algún tiempo.

Puedes tener un servidor HTTP con todo, todos pueden trabajar, incluso los más básicos. Así que consideremos un servidor muy simple en el que simplemente hacemos un pequeño tiempo de espera de un milisegundo. Muy simple. Esto simula una base de datos muy rápida que siempre nos responde con `hola mundo` en un milisegundo. Es genial. Y un cliente HTTP, el Node Core HTTP. ¿Por qué nos enfocamos solo en el Node Core HTTP? Bueno, porque Axios, Node fetch, request got, todos lo usan como respaldo. Es genial. Y cada vez que haces esas cosas que estamos haciendo, ya sabes, crean un socket TCP.

Entonces, básicamente, cuando abres un socket TCP, necesitas hacer un pequeño baile. Esto suele ser una ronda completa para establecerlo, lo cual es bastante, ¿vale? Porque, ya sabes, dependiendo de la latencia, la distancia física entre los dos, incluso puede llevar algo de tiempo. Puede ser de 10, 20 milisegundos, algo así. Estamos hablando de números muy pequeños. Pero recuerda, tal vez tienes 200 milisegundos para responder a tu cliente o tal vez 400, lo que quieras. Pero, ya sabes, cuantas más esperanzas hagas, mayor será tu latencia. Así que no quieres perder tiempo porque no has... Una vez que se ha establecido el 3NShake, ni siquiera has transferido ningún dato, ¿verdad? Solo has creado el socket. Ten en cuenta que si estás utilizando TLS o SSL, lleva aún más tiempo. Pero eso no es todo, porque una vez que creas un socket TCP, de hecho, hay un concepto que se llama ventana de congestión, que se considera lento al principio para los sockets nuevos establecidos.

3. Understanding TCP and Latency

Short description:

El servidor envía bytes al cliente, que luego debe confirmar su recepción. A medida que la ventana de congestión crece, se pueden enviar más bytes sin necesidad de confirmación. El éxito de TCP radica en su capacidad para funcionar en redes con ancho de banda variable. La necesidad de confirmaciones surge para evitar la pérdida de datos, pero introduce latencia.

¿Por qué? Esto significa que necesitas hacer más de un viaje de ida y vuelta para mover la misma cantidad de data, porque, ya sabes, la ventana de congestión te indica cuánto debe enviar el servidor antes de que el cliente pueda enviar un hack, o enviarme más, básicamente. Entonces, lo que sucede a la izquierda, como puedes ver a la izquierda, es que el servidor envía algunos bytes, luego el cliente necesita confirmar su recepción y luego envía más bytes, y así sucesivamente. Una vez que la ventana de congestión se ha vuelto más grande, de hecho, puede enviar una gran cantidad de bytes sin necesidad de confirmación. Esta es la razón por la cual TCP es tan exitoso, por cierto, porque le permite funcionar en redes con un ancho de banda muy pequeño o muy alto. ¿Por qué necesitarías todos esos hacks? Porque si pierdes algún mensaje en el medio, esta es la cantidad máxima de data que perderás. Sin embargo, esto tiene un costo.

4. Maximizing Performance with HTTP Keep-Alive

Short description:

Para maximizar el ancho de banda, es crucial reutilizar las conexiones existentes para evitar perder el trabajo realizado por la capa de red. En Node.js, la función HTTP 1.1 llamada KEEPALIVE permite reutilizar los sockets HTTP, lo cual es especialmente importante para TLS. Al utilizar clientes HTTP con Keep-Alive activado, podemos aumentar el rendimiento y el rendimiento de nuestras aplicaciones. Para probar esto, se utilizó un escenario con un cliente que realiza 500 solicitudes paralelas a un servidor, y los resultados mostraron mejoras significativas. Sin embargo, es importante tener en cuenta que estos resultados pueden variar según el sistema, por lo que se recomienda ejecutar pruebas de referencia para medir el impacto real.

que es la latencia. Por lo tanto, uno de los problemas clave con esto es que si deseas tener el máximo ancho de banda, debes reutilizar la conexión existente. Una vez que hayas establecido una conexión, envía algunos data, aumenta la ventana de congestión, esto crece con el tiempo, por cierto, que es genial, una de las mejores características de TCP, debemos reutilizar la conexión existente. Si no reutilizas las conexiones, estás perdiendo todo el trabajo que se hizo por ti en la capa de red. Para hacer esto en Node.js, debes usar una función HTTP 1.1, que se llama KEEPALIVE, que puedes ver aquí. Puedes ver KEEPALIVE true y puedes establecer el número máximo de conexiones para MANTENER ABIERTAS. Esto te permite reutilizar los mantener los sockets, tus sockets HTTP para mantenerlos activos. Más importante aún, es aún más importante con TLS, porque en realidad puedes evitar el establecimiento completo del contexto criptográfico, el contexto seguro entre los dos. Por lo tanto, es realmente muy, muy importante también para TLS.

Entonces, esta es la teoría. Deberíamos poder aumentar nuestro rendimiento, nuestro rendimiento en nuestras aplicaciones simplemente utilizando clientes HTTP con Keep-Alive activado. ¿Es este el caso? ¿Es este el caso? Bueno, veamos. Escenario. Tenemos un cliente que llama a un servidor con 500 solicitudes paralelas en la misma ruta. Y más o menos esto es igual que 500 solicitudes entrantes paralelas. Y el servidor objetivo tarda 10 milisegundos en procesar la solicitud y tiene un límite de 50 sockets. Así que esto es completamente sintético, ¿de acuerdo? No coincide con tu sistema, así que siempre mide estas cosas. No confíes en mí. Ejecuta tus pruebas de referencia.

5. HTTP 1.1 Pipelining and Reliability

Short description:

Siempre utiliza un agente. La canalización de HTTP 1.1 es una función poco conocida que se puede utilizar en el servidor pero no en el cliente HTTP de Node.js. Sufre de bloqueo de cabeza de línea y solo funciona para archivos pequeños. No funciona bien en enlaces poco confiables, pero es menos problemático en centros de datos confiables.

Ahora, esta es la diferencia entre los dos. Así que si olvidas algo de esta charla, siempre utiliza un agente. Eso es todo. Esa es la única cosa que necesitas recordar. Siempre utiliza un agente. La diferencia es tan grande que ni siquiera puedes considerar no usar uno.

Pero ¿podemos seguir mejorando las cosas? Porque he estado investigando este tema durante un tiempo, así que podría tener algo más que decir hasta cierto punto. Bueno, sí, podemos. De hecho, hay algo que se llama canalización de HTTP 1.1. Ahora, esta es una de las características más desconocidas de HTTP 1.1, y decir que no se debe usar esto es incorrecto. El navegador no lo usa, no es compatible con el navegador, pero es parte del estándar, y en realidad se puede usar en el servidor. Entonces, el servidor HTTP de Node.js admite la canalización de forma predeterminada, no necesitas hacer nada para habilitarla. Sin embargo, el cliente HTTP de Node.js no, por lo tanto, necesitas hacer algo más, no utilizarás esta técnica.

En la canalización de HTTP 1.1, todas las respuestas deben recibirse en orden. Esto significa que estás sufriendo de bloqueo de cabeza de línea, y una solicitud lenta puede detener la canalización. Entonces, básicamente, si la primera solicitud que haces es muy lenta, o las otras solicitudes se acumularán, esperando a que la primera termine. Esto es un problema. La canalización de HTTP solo funciona para archivos pequeños. Entonces, el problema siempre son las retransmisiones. Entonces, en el momento, si comienzas a perder un paquete y un paquete, todo se vuelve loco. Entonces, en realidad no puedes hacer nada Lo siento. No funciona realmente bien en enlaces poco confiables. Sin embargo, nuestros propios data centros son enlaces confiables. Entonces, si necesitamos llamarlos de un microservicio a otro, esos enlaces, esas conexiones, esos sockets son realmente confiables. No fallan. No es como si alguien estuviera moviéndose con su iPhone y estuviera conectado con diferentes celdas, por lo que la conexión se activa y desactiva. Esto es en realidad... Sabes, son muy confiables en el centro de data. Entonces, esto es menos problemático en el centro de data.

6. Node.js Event Loop and Performance

Short description:

El bucle de eventos de Node.js funciona programando las E/S para que se realicen de forma asíncrona. El bucle de eventos espera a que ocurra algo y luego realiza una llamada de vuelta a C++. Para mejorar el rendimiento de la aplicación, es importante minimizar el tiempo de bloqueo del bucle de eventos. Se pueden utilizar gráficos de llamas para visualizar y minimizar las llamadas de función.

Ahora, una cosa más de la que preocuparse. Es realmente importante tener en cuenta cómo funciona el bucle de eventos de Node.js. Entonces, cada vez que obtienes un socket TCP, cada vez que hacemos cualquier E/S, básicamente, tu código JavaScript programa alguna E/S para que se realice de forma asíncrona. Y luego realiza una llamada de vuelta y comienza en la cola de eventos. En la práctica, ¿qué significa esto? Esto significa que el bucle de eventos está esperando a que ocurra algo. Luego realiza una llamada de vuelta a C++, y desde C++ realiza una llamada a JavaScript, y desde JavaScript, termina, realiza la siguiente iteración, realiza promesas y así sucesivamente, termina C++, y luego comienza nuevamente el bucle de eventos. Ahora, hay un momento entre estos dos donde el bucle de eventos está bloqueado. Cuando se ejecuta la función C++ y JavaScript. Entonces, ¿qué significa esto? Significa que si queremos mejorar el rendimiento de nuestras aplicaciones, necesitamos minimizar el tiempo en el que estamos bloqueando nuestro bucle de eventos. Y básicamente, es la estrategia clave para aumentar el rendimiento. Y realmente puedes usar gráficos de llamas, usar gráficos de llamas para visualizar las funciones y minimizarlas. Es bastante genial,

7. Timeouts, Echo Resets, and Introducing Undici

Short description:

Ahora, este es uno de los problemas que estamos tratando de resolver: los tiempos de espera y los reinicios de eco. Si usas agentes, es posible que te encuentres con reinicios de eco y tiempos de espera. El problema es que un socket puede morir y quieres minimizar esto. Por defecto, Node.js utiliza una estrategia FIFO, pero recientemente se agregó una nueva estrategia de programación llamada LIFO al agente HTTP en Node.js. Este enfoque LIFO minimiza los tiempos de espera y los reinicios de eco reutilizando los sockets que funcionaron la última vez. Ahora, permíteme presentarte una nueva biblioteca llamada undici, que proviene de http 1.1.11 y se traduce como 'once' en italiano.

funciona muy bien. Ahora, este es uno de los problemas, ¿verdad? El siguiente que estamos tratando de resolver, y este es el punto extra, son los tiempos de espera y los reinicios de eco. Entonces, si usas agentes, está bien, es posible que te encuentres con reinicios de eco. Y ¿qué son esos, y los tiempos de espera? Entonces, el problema es que un socket, si los estás usando, puede morir. Y si mueren, lo que necesitas hacer es reprogramarlos. Entonces, si mueren, es un problema, porque puede suceder y puedo decir, oh, estoy enviando data en este socket. Estoy tratando de reutilizar lo. Cuando lo uso, muere. Ya no está disponible. Estoy obteniendo un registro de eso. Es realmente malo. Entonces, lo que quieres hacer es minimizar esto. Por defecto, la estrategia original para Node.js era FIFO primero en entrar, primero en salir, lo que significa que estaba reutilizando todos los sockets para tratar de crear la menor cantidad. Ahora, el problema con ese enfoque es que todos los sockets son los más propensos a agotarse porque son antiguos. Y así, recientemente, agregamos una nueva programación para el agente HTTP en Node.js. Se llama LIFO. Es una estrategia diferente. Último en entrar, primero en salir significa que el último que usaste, intentamos usarlo. Lo que significa que en realidad vamos a crear más sockets porque, esencialmente, dejamos que más sockets expiren. Sin embargo, con el enfoque LIFO, realmente se minimiza la cantidad de tiempos de espera y reinicios de eco porque en realidad vas a reutilizar los sockets que funcionaron la última vez. Entonces sabes que esto funciona. Está ahí. Entonces es mucho, mucho más probable que tu solicitud se realice. Bien, ya conocemos todas estas cosas. Permíteme presentarte una nueva biblioteca llamada undici. Entonces, ¿qué es undici? Bueno, undici proviene de http 1.1.11. Y sabes que 11 es una palabra secular, ¿verdad? Pero en italiano significa 'once'.

8. Introducción a Undici

Short description:

Undici es un nuevo cliente para node.js que utiliza las funciones internas de Node Core. Admite tanto HTTP como HTTPS, utiliza la programación lithos y permite conexiones ilimitadas. Elimina la necesidad de múltiples agentes y ofrece opciones de configuración sencillas.

Undici significa undici. Así que puedes traducir 11 como undici. Por eso se llama undici. Y también sabes que es una referencia a Stranger Things, por si te lo estabas preguntando. Entonces, ¿qué hace undici? Undici es un nuevo cliente para node.js implementado desde cero utilizando las funciones internas de Node Core. Es genial. Puedes usarlo con un agente global que mantendrá viva tu conexión de forma predeterminada. Utiliza la programación lithos, no utiliza pipelining y permite conexiones ilimitadas. Por lo tanto, funcionará más o menos de la forma en que estás acostumbrado. Admite tanto HTTP como HTTPS al mismo tiempo. No es necesario hacer malabarismos con múltiples agentes y cosas por el estilo. Simplemente lo hace todo. Y eso es bastante genial. Incluso puedes configurar agentes HTTP en el agente. Puedes configurarlo o usarlo directamente. Funciona muy bien, desde mi punto de vista. Puedes crear un conjunto de pipelining, establecer el número de conexiones para cada dominio, y así sucesivamente. Incluso puedes usar el pool. El pool es lo que el agente utiliza para comunicarse con un solo host, por lo que puedes crear un solo cliente HTTP. Puedes crear un solo pool para un solo destino y realizar las solicitudes utilizando ese pool. Y esto es bastante genial. Incluso puedes crear un solo cliente, que es básicamente una sola conexión. Tiene diferentes métodos, por lo que puedes hacer una solicitud, puedes hacer un stream, hay otros que son aún más rápidos. Son bastante geniales. Todos son bastante geniales. Básicamente, están ahí para minimizar la sobrecarga en caso de que lo necesites. ¿Cómo se compara undici con el cliente HTTP de Node Core? Bueno, en realidad es muy rápido. Y cuando activas el pipelining, puedes llegar a obtener hasta 3 veces lo que haría un cliente HTTP de Node Core con Kipallite. Undici también es mucho más estricto en términos de HTTP, así que hay esa diferencia. He hecho algunas pruebas y con undici, un buen pool de conexiones y una buena configuración, realmente puedes obtener muy buenos resultados, y realmente funciona muy, muy bien. Resolvió mi problema con el proxy HTTP de Fastify. Gracias por aguantarme durante esta larga charla, y esto es lo que debes recordar, siempre usa un agente HTTP o HTTPS. Puedes usar undici para reducir drásticamente la sobrecarga de tu sistema distribuido, pero tendrás que hacer algunas pruebas porque esta es una nueva API. Y quiero agradecer a Robert Nagy que básicamente tomó undici y lo hizo listo para producción, porque fue un trabajo fantástico, Robert, gracias. También necesitamos ayuda, más pruebas, hay un undici fetch que está siendo desarrollado por Ethan, así que es bastante genial, para ser honesto, y hay un futuro brillante por delante para undici. Me gustaría recomendarte un libro, este es realmente un libro importante de Ilia Grigorik, deberías leerlo, es una obra maestra, por favor. También hay una guía de eventos, échale un vistazo, y luego está Fastify y Undici. Gracias, soy Matteo Collina, y soy un guía técnico para Uniform. Muchas gracias. ¡Adiós!

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.