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.
This talk has been presented at Node Congress 2021, check out the latest edition of this JavaScript Conference.
FAQ
Matteo Collina es un arquitecto de software, consultor, director técnico en NearForm y parte del comité técnico de Node.js. Es co-creador del framework web Fastify y de PinnoLogger, y también se destaca por tener aproximadamente 6 mil millones de descargas en NPM durante el año 2020.
Fastify es un servidor web y marco de trabajo muy rápido para Node.js, diseñado para construir aplicaciones pequeñas y grandes. Es efectivo tanto para monolitos como para microservicios, ofreciendo un rendimiento optimizado y eficiente.
Los microservicios son una forma de estructurar sistemas donde diferentes equipos mantienen diferentes partes del sistema de forma independiente. Esto ayuda a escalar los equipos y a evitar superposiciones en el trabajo, mejorando la gestión y la eficiencia del desarrollo.
Keep-Alive es una función en HTTP 1.1 que permite reutilizar una conexión TCP existente para múltiples solicitudes HTTP, en lugar de abrir una nueva conexión para cada solicitud. Esto mejora significativamente la eficiencia y el rendimiento de las aplicaciones al reducir la latencia y el uso de recursos.
En Node.js, el rendimiento HTTP puede mejorarse utilizando técnicas como Keep-Alive para reutilizar conexiones y la canalización HTTP 1.1, que permite enviar múltiples solicitudes antes de recibir las respuestas anteriores. Estas técnicas optimizan la utilización de la red y reducen la latencia.
Undici es un cliente HTTP para Node.js diseñado desde cero utilizando funciones internas de Node Core. Ofrece un rendimiento superior al cliente HTTP de Node Core, especialmente cuando se activa la canalización, proporcionando hasta 3 veces más rendimiento.
Los agentes HTTP y HTTPS son cruciales para gestionar conexiones de red en un sistema distribuido. Permiten mantener múltiples solicitudes y conexiones de manera eficiente, lo que es esencial para minimizar la sobrecarga y mejorar la respuesta de las aplicaciones.
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.
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!
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
This talk covers various techniques for getting diagnostics information out of Node.js, including debugging with environment variables, handling warnings and deprecations, tracing uncaught exceptions and process exit, using the v8 inspector and dev tools, and generating diagnostic reports. The speaker also mentions areas for improvement in Node.js diagnostics and provides resources for learning and contributing. Additionally, the responsibilities of the Technical Steering Committee in the TS community are discussed.
Deno aims to provide Node.js compatibility to make migration smoother and easier. While Deno can run apps and libraries offered for Node.js, not all are supported yet. There are trade-offs to consider, such as incompatible APIs and a less ideal developer experience. Deno is working on improving compatibility and the transition process. Efforts include porting Node.js modules, exploring a superset approach, and transparent package installation from npm.
Today's Talk is about logging with Pino, one of the fastest loggers for Node.js. Pino's speed and performance are achieved by avoiding expensive logging and optimizing event loop processing. It offers advanced features like async mode and distributed logging. The use of Worker Threads and Threadstream allows for efficient data processing. Pino.Transport enables log processing in a worker thread with various options for log destinations. The Talk concludes with a demonstration of logging output and an invitation to reach out for job opportunities.
¿Alguna vez has tenido dificultades para diseñar y estructurar tus aplicaciones Node.js? Construir aplicaciones que estén bien organizadas, sean probables y extensibles no siempre es fácil. A menudo puede resultar ser mucho más complicado de lo que esperas. En este evento en vivo, Matteo te mostrará cómo construye aplicaciones Node.js desde cero. Aprenderás cómo aborda el diseño de aplicaciones y las filosofías que aplica para crear aplicaciones modulares, mantenibles y efectivas.
Platformatic te permite desarrollar rápidamente APIs GraphQL y REST con un esfuerzo mínimo. La mejor parte es que también te permite aprovechar todo el potencial de Node.js y Fastify cuando lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y complementos adicionales. En el masterclass, cubriremos tanto nuestros módulos de código abierto como nuestra oferta en la nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). En este masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la nube de Platformatic.
Construyendo un Servidor Web Hiper Rápido con Deno
WorkshopFree
2 authors
Deno 1.9 introdujo una nueva API de servidor web que aprovecha Hyper, una implementación rápida y correcta de HTTP para Rust. El uso de esta API en lugar de la implementación std/http aumenta el rendimiento y proporciona soporte para HTTP2. En este masterclass, aprende cómo crear un servidor web utilizando Hyper en el fondo y mejorar el rendimiento de tus aplicaciones web.
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada. Mejoraremos una aplicación JS de pila completa (backend de Node.JS + frontend de React) para autenticar usuarios con OAuth (inicio de sesión social) y contraseñas de un solo uso (correo electrónico), incluyendo:- Autenticación de usuario - Administrar interacciones de usuario, devolver JWT de sesión / actualización- Gestión y validación de sesiones - Almacenar la sesión para solicitudes de cliente posteriores, validar / actualizar sesiones Al final del masterclass, también tocaremos otro enfoque para la autenticación de código utilizando Flujos Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña. Tabla de contenidos- Una breve introducción a los conceptos básicos de autenticación- Codificación- Por qué importa la autenticación sin contraseña Requisitos previos- IDE de tu elección- Node 18 o superior
Cómo construir una aplicación GraphQL fullstack (Postgres + NestJs + React) en el menor tiempo posible. Todos los comienzos son difíciles. Incluso más difícil que elegir la tecnología es desarrollar una arquitectura adecuada. Especialmente cuando se trata de GraphQL. En este masterclass, obtendrás una variedad de mejores prácticas que normalmente tendrías que trabajar en varios proyectos, todo en solo tres horas. Siempre has querido participar en un hackathon para poner algo en funcionamiento en el menor tiempo posible, entonces participa activamente en este masterclass y únete a los procesos de pensamiento del instructor.
Node.js test runner es moderno, rápido y no requiere bibliotecas adicionales, pero entenderlo y usarlo bien puede ser complicado. Aprenderás a utilizar Node.js test runner a su máximo potencial. Te mostraremos cómo se compara con otras herramientas, cómo configurarlo y cómo ejecutar tus pruebas de manera efectiva. Durante la masterclass, haremos ejercicios para ayudarte a sentirte cómodo con el filtrado, el uso de afirmaciones nativas, la ejecución de pruebas en paralelo, el uso de CLI y más. También hablaremos sobre trabajar con TypeScript, hacer informes personalizados y la cobertura de código.
Comments