Undici, el cliente HTTP de próxima generación construido por el equipo principal de Node.js, alimenta el fetch() principal de Node.js. Vamos a adentrarnos en sus entresijos, descubriendo cómo trabajar con Despachadores, Agentes y Pools. Por último, pero no menos importante, incluso haremos algo de magia.
This talk has been presented at Node Congress 2024, check out the latest edition of this JavaScript Conference.
Undici es un cliente HTTP moderno para Node.js que ofrece un rendimiento mejorado y características avanzadas. Admite HTTP 1.1 y recientemente agregó soporte para HTTP 2.0. Undici ofrece un rendimiento impresionante, especialmente con Undici.Stream. También admite el encolamiento de HTTP 1.1, lo que puede reducir significativamente el tiempo de respuesta. Undici ofrece una gestión flexible de conexiones y despachadores, así como interceptores para personalización. Undici v7 viene con APIs mejoradas y un tiempo de ejecución programático para ejecutar múltiples microservicios en el mismo proceso.
Hola a todos, soy Matteo Collina, cofundador y CTO de Platformatic, y hoy voy a profundizar en Undici, la nueva biblioteca HTTP construida por el equipo principal de Node. Unas palabras sobre mí, soy parte del Comité de Dirección Técnica de Node.js, así como miembro de la Junta de la Fundación OpenJS. He creado algunas bibliotecas que es posible que utilices. Hablé de ellas en el Congreso de Node varias veces, por lo que es posible que quieras echarles un vistazo, tanto Fastify como Pino si te gustan. Trabajé ocho años como consultor y luego decidí iniciar una startup. Aquí está Platformatic. Tengo un boletín en node.landofdev, un canal de YouTube, y así sucesivamente. Puedes echarle un vistazo. Pero en todo esto, la parte importante es que es probable que estés utilizando mis cosas, porque mis módulos fueron descargados 22 mil millones de veces el año pasado, lo que probablemente incluye a ti también, que estás viendo este video.
Hola a todos, soy Matteo Collina, cofundador y CTO de Platformatic, y hoy voy a profundizar en Undici, la nueva biblioteca HTTP construida por el equipo principal de Node. Unas palabras sobre mí, soy parte del Comité de Dirección Técnica de Node.js, así como miembro de la Junta de la Fundación OpenJS. He creado algunas bibliotecas que es posible que utilices. Hablé de ellas en el Congreso de Node varias veces, por lo que es posible que quieras echarles un vistazo, tanto Fastify como Pino si te gustan. Trabajé ocho años como consultor y luego decidí iniciar una startup. Aquí está Platformatic. Tengo un boletín en node.landofdev, un canal de YouTube, y así sucesivamente. Puedes echarle un vistazo. Pero en todo esto, la parte importante es que es probable que estés utilizando mis cosas, porque mis módulos fueron descargados 22 mil millones de veces el año pasado, lo que probablemente incluye a ti también, que estás viendo este video.
2. Undici: Cliente HTTP para Node.js
Short description:
Undici es un cliente HTTP moderno escrito desde cero para Node.js. Es fácil de empezar a usar y proporciona todas las características esperadas como código de estado, encabezados, remolques y cuerpo. Undici también es el hogar de fetch para Node.js y tiene como objetivo una alta compatibilidad con las especificaciones. Ofrece un rendimiento mejorado y una separación completa entre la API y la gestión de conexiones. Undici proporciona agrupamiento de conexiones y admite interceptores para la integración.
Hablemos un poco sobre Undici. Undici es un cliente HTTP relativamente nuevo o moderno escrito desde cero para Node.js. ¿Qué significa desde cero? Significa que no se basa en el módulo interno HTTP y HTTPS, sino que lo creamos desde cero. Undici, sin color aquí, significa 11 en italiano y proviene de HTTP 1.1. También es una referencia a Stranger Things porque estaba viendo Stranger Things cuando esto comenzó a venir a mi mente.
¿Cómo funciona? Es muy fácil de empezar a usar, para ser honesto. Solo puedes importar solicitudes de Undici y simplemente colocar tu URL, y obtienes todas las cosas que esperarías. Obtienes el código de estado, encabezados, remolques y cuerpo. Obtienes todas las cosas. Ten en cuenta que ha implementado la misma mezcla de cuerpo de fetch, por lo que puedes esperar body.json, por ejemplo. Algo muy importante para recordar es que cuando obtienes un cuerpo, por favor, consúmelo. Hay cierta lógica interna que se asegurará de que las cosas se manejen correctamente, pero límpialo si es posible. Undici también es el hogar de fetch para Node.js. Cuando usas fetch dentro de Node.js, en realidad estás usando fetch de Undici y Node.js incluye internamente Undici. Es un fetch compatible con las especificaciones que te gusta y amas. Eso es más o menos todo lo que necesita ser dicho. Estamos trabajando muy duro para tener la mayor compatibilidad con las especificaciones posible, por lo que en teoría esto debería funcionar lo más cerca posible del fetch que estás ejecutando en tu navegador y también en otros entornos de ejecución. Si necesitas tener compatibilidad con las especificaciones, si quieres trabajar en la compatibilidad con las especificaciones para fetch, Undici es el lugar adecuado.
¿Cuáles son las cosas buenas de Undici? En primer lugar, Undici tiene un rendimiento mejorado. Hablaremos de eso más adelante. Tengo algunas diapositivas geniales. También crea una separación completa entre la API, la API pública, la experiencia del desarrollador y cómo se maneja la gestión de conexiones. Algo que no estaba presente en la solicitud HTTP y en el módulo HTTP y HTTPS. También tiene múltiples implementaciones. Dije agrupamiento. Sí, dije agrupamiento. HTTP es un protocolo basado en conexiones, por lo que probablemente quieras hacer agrupamiento de conexiones. A pesar de lo que dice la literatura de que HTTP es un protocolo sin estado, en realidad es sin estado porque se trata de una conexión con estado... ¿Cómo es esto posible? Bueno, sí, por supuesto, porque es sin estado en el sentido de la semántica, pero se implementa sobre una conexión con estado, TCP y TLS, por supuesto.
3. Undici: Funciones Avanzadas y Rendimiento
Short description:
Undici es mantenido por el equipo principal de Node y ofrece soporte para HTTP 1.1 y recientemente agregó soporte para HTTP 2.0. Los módulos HTTP son un desastre debido a la misma estructura de API para el cliente y el servidor de HTTP 1.0. Para superar esto, se creó undici.request para ser rápido y altamente configurable, utilizando el flujo de Node.js y admitiendo la agrupación de HTTP 1.1. Undici Fetch está diseñado para cumplir con las especificaciones y utiliza internamente WhatWGstream. También admite HTTP2 y la agrupación de HTTP. Undici ofrece un rendimiento impresionante, especialmente con Undici.Stream.
Hablaré sobre qué son los interceptores y cómo integrarse con ellos. Además, es mantenido por el equipo principal de Node, el equipo de HTTP y, de hecho, la mayoría de nosotros pensamos que HTTP.request es casi irremediable y por eso es en lo que estamos trabajando en su lugar. Al principio, comenzó con soporte solo para HTTP 1.1, luego también agregamos recientemente soporte para HTTP 2.0, y ahora es... Sabes, el nombre Undici puede que ya no sea la mejor referencia. De todos modos, entonces... Además, tenemos HTTP 1.1. También tiene soporte para agrupación de HTTP 1.1. Así que... También... Algo que es un poco... Hay algunas cosas que son diferentes en él, por lo que es posible que experimentes algunos errores con los que debas lidiar, en esencia. Entonces, ¿por qué? Bueno, el problema es que los módulos HTTP son un desastre, ¿vale? Principalmente porque utilizan la misma estructura de API tanto para el cliente como para el servidor de HTTP 1.0, y ambos están vinculados con la gestión de conexiones con la API pública. Entonces, ¿cómo puedes verlo? Bueno, tienes una propiedad request.socket, ¿vale? El hecho de que tengas una propiedad request.socket te dirá que hay este tipo de conexión, porque si tu sistema ya no está en socket, como en HTTP 2.0, ¿cómo lo implementarías? Y esta es la razón por la que no puedes admitir tanto HTTP 1.1 como HTTP 2.0 en la misma API. Por último, pero no menos importante, no podemos cambiar esas clases sin romper express. Entonces, sí, bueno, esa es la situación. Por eso creamos undici.request para que sea lo más rápido posible, porque hacer una solicitud HTTP no debería ser el cuello de botella de tu aplicación. También proporciona una experiencia de desarrollo lo suficientemente buena, una muy buena experiencia de desarrollo, desde mi punto de vista. Es altamente configurable, utiliza el flujo de Node.js, admite la agrupación de HTTP 1.1. Es genial. Solo usa esto. Probablemente este es el code que quieres usar, ¿vale? Undici Fetch está diseñado para cumplir con las especificaciones, ¿vale? Entonces, no coloca elperformance como la máxima prioridad. Es la conformidad con las especificaciones lo que importa. Y en este momento, estamos pasando el 88% de las pruebas WPT que estamos ejecutando para Fetch. Así que creo que la compatibilidad es bastante buena en general. Sin embargo, internamente utiliza WhatWGstream, por lo que puedes usar Pipe2, WhatWGstream, todas las cosas, el flujo legible, como en el navegador. Entonces, todo el code que utiliza Undici Fetch y Fetch Node podría ser isomórfico. Nuevamente, el manejo del protocolo y la API están completamente separados, por lo que todas las cosas de las que vamos a hablar, Undici y la gestión de conexiones y demás, se aplican a ambos. Y esta es la razón por la que Undici Fetch se construyó sobre Undici. Fetching Node se construyó sobre Undici. También admite HTTP2, la agrupación de HTTP, debido a esta separación. Bueno, hablemos deperformance, porque esto es lo crítico, ¿vale? Entonces, lo cual, ya sabes, los números son realmente significativos aquí, ¿vale? Como Undici es prácticamente sin restricciones, ¿vale? Puedes usar, en este sistema detesting, puedes usar Undici, una de las API de nivel más bajo, que es Undici.Dispatch, pero para ser honesto, esto no es lo que deberías estar usando, ¿vale? Es la parte subyacente, o Undici.Stream, que es,
4. Undici: Rendimiento y Velocidad de las Solicitudes
Short description:
Realizar solicitudes HTTP no debería ser el cuello de botella de tu aplicación con Undici.Request. Undici ofrece un rendimiento impresionante, especialmente con Undici.Stream.
ya sabes, aún más rápido, pero nuevamente, probablemente demasiado bajo nivel. Puedes lograr un gran número de solicitudes desde un solo proceso de nodo, ¿vale? Enviar 20,000, 21,000 solicitudes por segundo, es muchas solicitudes que vas a enviar, ¿vale? Entonces, en esencia, nuestro objetivo es que realizar solicitudes HTTP no sea el cuello de botella de tu aplicación con Undici.Request. Y puedes ver cómo se están configurando las otras APIs. Tenemos SuperAgent, tenemos HTTP de Node Core, tenemos Axios, cómo se desempeña Axios, tenemos el módulo de solicitud de la vieja escuela, cómo se desempeña y luego tenemos Undici.Fetch, que en realidad es más lento, ¿vale? Como dije, hay muchas cosas que se pueden optimizar aún, pero es solo un poco más rápido que Node.Fetch, lo cual es genial, y luego tenemos
5. Undici: HTTP 1.1 Pipelining
Short description:
Si estás experimentando problemas de rendimiento al hacer solicitudes HTTP, cambia a Undici. La canalización de HTTP 1.1 permite enviar múltiples solicitudes al mismo tiempo, reduciendo significativamente el tiempo de respuesta. Sin embargo, puede ocurrir bloqueo de cabeza de línea si la primera solicitud se retrasa. A pesar de esto, la canalización puede mejorar el rendimiento, especialmente al llamar a microservicios.
al final. Ok, solo para aclarar, todo esto es realmente muy importante tener en cuenta, que si estás experimentando algún problema de rendimiento al hacer solicitudes HTTP, probablemente deberías cambiar a Undici. Hablo mucho sobre la canalización de HTTP 1.1, y necesito, realmente quiero explicarlo, ¿de acuerdo? Porque de lo contrario probablemente no sabrás de qué estoy hablando. Entonces, en una solicitud HTTP normal, cuando abres un cliente, una solicitud de un cliente a un servidor, ¿de acuerdo? En primer lugar, hay un ping pong, ¿de acuerdo?, de abrir la solicitud HTTP, ¿de acuerdo? Además de eso, debes agregar TLS si hay TLS. Sí, muchos intercambios. Una vez que tienes esta conexión establecida, ¿de acuerdo?, el cliente envía una solicitud a ese socket, ¿de acuerdo? Una vez que el socket vuelve, realiza el procesamiento y lo devuelve al principio, y luego puede enviar una segunda solicitud en ese socket. Hablé mucho sobre la agrupación de conexiones. Entonces, tienes, en esencia, si quieres hablar con otro microservicio en tu red, tienes, no sé, tres, cuatro, cinco, 10, 20, 50, lo que sea conexiones. Entonces, quieres, ya sabes, asignar una conexión a una solicitud hasta que obtengas la siguiente, la siguiente solicitud después. Entonces, si tienes 50 conexiones, en esencia, significa que solo puede haber 10 conexiones, lo siento, 50 solicitudes en proceso en general, porque cada una conexión, una solicitud, ¿de acuerdo? La canalización cambia eso. Entonces, con la canalización, podemos enviar dos solicitudes al mismo tiempo, ¿de acuerdo? Podemos enviar una solicitud, podemos enviar dos solicitudes al mismo tiempo, una tras otra. Ahora, esto es genial porque realmente podemos reducir el tiempo de respuesta significativamente porque enviamos dos mensajes y podemos ahorrar todo el tiempo de ida y vuelta, ¿de acuerdo? Luego, los servidores deberán analizarlos uno tras otro y luego enviarnos los resultados, ¿de acuerdo? Lo cual está bien porque si te deslizas en este ejemplo, se tarda 172 milisegundos en obtener ambas respuestas, mientras que en el otro son 228. Entonces, en realidad estamos respondiendo más rápido y recibiendo los datos de vuelta más rápido, pero hay un problema, ¿de acuerdo? ¿Qué sucede si la primera solicitud se retrasa? Si la primera solicitud se retrasa, ¿de acuerdo?, como puedes ver en este ejemplo, en realidad estamos perdiendo mucho procesamiento, ¿de acuerdo? La segunda, la más corta, necesita esperar para ser enviada, ¿de acuerdo? Porque primero necesito enviar la primera y luego necesito enviar la segunda. Este fenómeno se llama bloqueo de cabeza de línea. Entonces, ¿de acuerdo? Genial, no tan genial, necesitas tener esto en cuenta, ¿de acuerdo? Pero especialmente al llamar a microservicios, esto probablemente está bien o en mi experiencia esto está bien y puede ayudarnos a lograr mucho, mucho, mucho más rendimiento porque
6. Undici: Gestión de conexiones
Short description:
Separaremos la API de la parte interna y gestionaremos manualmente el grupo de conexiones. La parte clave de la gestión de conexiones es el despachador, que se puede cambiar utilizando SetGlobalDispatcher. La jerarquía de despachadores incluye la clase abstracta, el despachador para la gestión de conexiones, el cliente y el grupo. El grupo equilibrado utiliza un algoritmo para elegir el socket con la mejor latencia. El agente permite trabajar en múltiples grupos, uno para cada origen.
podemos utilizar nuestros sockets de una manera mucho mejor, ¿de acuerdo? Entonces, echemos un vistazo a cómo funciona esto. Y en primer lugar, queremos proporcionar la base para HTTP a continuación. Y, como dije, separaremos la API de la API, la API que los usuarios utilizan de la parte interna. Entonces, hay dos capas separadas, completamente independientes entre sí. Y todas las partes internas están basadas en devoluciones de llamada. No se basan en devoluciones de llamada de error y no se basan en eventos, ¿de acuerdo? Entonces, se basan en un mecanismo de nivel inferior que es extremadamente rápido. Entonces, no tenemos ningún sobrecargo en absoluto.
Además, gestionamos manualmente nuestro grupo de conexiones, ¿de acuerdo? Y puedes hacer diferentes cosas. Y somos muy exigentes con el sobrecargo y la asignación de memoria. Por último, pero no menos importante, minimizamos la transición entre C, C++ y JavaScript. Entonces, la parte clave de la gestión de conexiones y cómo interactúas con las partes internas es mediante el concepto de un despachador. Y hay una API en Undici llamada SetGlobalDispatcher. Entonces, si quieres cambiar el despachador global o el mecanismo global para manejar la solicitud HTTP, puedes hacerlo en cualquier momento a través de la biblioteca Undici, llamando a SetGlobalDispatcher y pasando un agente u otra cosa de la que hablaremos pronto. Puedes configurar muchas cosas. Puedes poner muchos parámetros aquí. Así que échale un vistazo. Ahora, lo importante es tener en cuenta que llamar a SetGlobalDispatcher desde Undici también cambiará el de fetch en Node.js, ya que ambas cosas están diseñadas para ser completamente interoperables.
Entonces, ¿cuál es la jerarquía de esos despachadores? Tenemos una clase abstracta de despachador, que incluye muchas cosas. E incluye muchos de los métodos sofisticados. Y luego tenemos una clase abstracta que implementa el despachador para la gestión de conexiones. Y a partir de ahí, tenemos el cliente, que envuelve un socket, una conexión. Luego tenemos el grupo. Y el grupo es un conjunto de clientes, básicamente. Entonces, si el grupo recibe una solicitud, dice: `Oh, dame un cliente libre`. De lo contrario, espera. El grupo equilibrado es un sistema alternativo que utiliza un algoritmo reciente que se publicó en un artículo reciente que nos permite elegir el socket que ofrecerá la mejor latencia para esa solicitud específica. ¿Cómo funciona? Sí, es un algoritmo complejo. Así que échale un vistazo. Utiliza mucho peso y matemáticas para hacer su trabajo. ¿Qué hace el agente? Bueno, el agente te permite trabajar
7. Undici: Dispatchers and Interceptors
Short description:
El agente coordina las solicitudes al grupo correcto y permite la creación de un agente simulado. El método de despacho del despachador separa la interfaz de nivel inferior de la de nivel superior. Se puede utilizar un agente de reintento para volver a intentar las solicitudes HTTP que fallan. Los interceptores de despacho ofrecen una alternativa a la clase de despachador. El módulo UndiciOIDCInterceptor emite automáticamente tokens OIDC de máquina a máquina para las solicitudes a destinos específicos.
a través de un grupo de grupos. Uno para cada origen. Entonces, si tienes una combinación de dominio más puerto, o IP más puerto, entonces el agente es el sistema que lo coordina y envía una solicitud al grupo correcto. Este sistema también nos permite implementar un agente simulado o un sistema simulado para Undici, que está integrado. Entonces, en realidad puedes configurar un agente simulado, y el agente simulado se puede configurar para interceptar solo algunas solicitudes. Entonces, si configuras esto, puedes interceptar una solicitud y puedes envolverla a través del agente simulado. Parece fantástico, ¿verdad? No hay parches de monos ni nada por el estilo. Esto funciona directamente desde el principio. ¿Por qué se llama despachador, sin embargo? Bueno, porque un despachador tiene los métodos más importantes, y el método de despacho es el método de despacho. Y el método de despacho toma un objeto de opciones que describe la solicitud y un controlador para esa solicitud. Un controlador es un objeto complejo que implementa muchas devoluciones de llamada para muchos estados diferentes de la solicitud HTTP. Y si estás llamando a dispatcher.request internamente para usar un controlador de solicitud, y stream, controlador de transmisión, fetch, controlador de fetch, pipeline, controlador de pipeline, sí, parece correcto, ¿de acuerdo? Y así es como separamos la interfaz de nivel inferior que es el despacho, y el nivel superior, como solicitud, fetch, stream, y así sucesivamente. ¿Cuántos métodos hay? Bastantes, en realidad, porque necesitamos rastrear todas las cosas. Entonces tenemos connect, ¿de acuerdo? Tenemos non-connect, onError, onUpgrade, onResponseStarted, onHeaders, onData, onComplete y onBodySent. ¿Sí? Bastante genial, ¿verdad? Bueno, este sistema nos permite crear algo como un agente de reintento. Entonces, imaginemos que quieres volver a intentar tu solicitud HTTP porque están fallando, por cualquier motivo. Bueno, el agente de reintento simplemente hace eso, ¿de acuerdo? Está integrado, ¿de acuerdo? Así que no necesito hacer mucho. Puedo configurarlo como un agente global, o simplemente puedo llamarlo. Funciona muy bien. Internamente, esto, implementa un controlador de reintento. Entonces, el agente de reintento, cuando recibe el método de despacho, crea un controlador de reintento, que básicamente envuelve el controlador anterior y agrega cierta lógica de reintento. ¡Hey! Eso funciona, ¿de acuerdo? Bastante genial, ¿verdad? Y es interminable hasta el final Y una de las opciones en el interior, para el despachador, son los interceptores de despacho, ¿de acuerdo? Lo siento, y los interceptores de despacho son simplemente objetos que tienen una función de despacho. Eso es todo, ¿de acuerdo? Que ofrece la misma API que la clase de despachador, ¿de acuerdo? Pero un interceptor solo, es un objeto que solo tiene despacho. El otro, el despachador también tiene muchos otros métodos en él, ¿de acuerdo? Y por ejemplo, lo que he creado, es un sistema para emitir automáticamente tokens OIDC de máquina a máquina para cada solicitud que sale hacia un destino específico. En este ejemplo, y puedes comprobarlo, es un módulo separado llamado UndiciOIDCInterceptor. Y cuando creas un agente, puedes configurar tus interceptores en el code, ¿de acuerdo? Es bastante, es bastante genial. Es bastante bueno desde mi punto de vista. Y puedes comprobarlo, en esta diapositiva a la derecha, puedes ver un gran ejemplo de cómo se ve el proveedor. Es mucho, ¿de acuerdo? Es mucho code, mucha configuración, pero es
8. Undici: Nuevas APIs y Plataforma de Ejecución
Short description:
Undici v7 viene con APIs mejoradas. Los resultados de referencia muestran que la mayor parte del tiempo se gasta en inicializar los streams WOTUG. El nuevo RFC 9110 de HTTP permite implementar lógica HTTP en cualquier cosa. El despachador Fastify Undici omite la lógica de solicitud HTTP para enrutar las solicitudes al servidor Fastify. La plataforma de ejecución permite ejecutar múltiples microservicios en el mismo proceso.
compatible con Auth0, por ejemplo. Es compatible con cualquier cosa que sea compatible con OIDC y admita tokens de máquina a máquina. Muy bueno desde mi punto de vista. Pero ten cuidado, porque probablemente en la próxima versión de Undici v7, cambiaremos estas APIs. Así que estamos trabajando en algo mejor.
Entonces, a partir del code, el ejemplo que hicimos al principio, te preguntas por qué fetch es bajo, ¿de acuerdo? Así que me tomé la libertad de ejecutar esta referencia. Muy simple, muy, para ser honesto, bastante directo. Emitimos cien mil solicitudes de fetch localmente y obtenemos el texto. Y eso es todo. Y te sorprenderá mucho dónde estamos gastando el tiempo. Todo el tiempo, la mayor parte del tiempo, el 50 por ciento del tiempo se gasta en inicializar los streams WOTUG, ¿de acuerdo? No en el procesamiento HTTP, no en nada más, solo en la inicialización. ¿Por qué los streams WOTUG son tan costosos en la inicialización? Bueno, esta es una respuesta larga y desafortunadamente probablemente valdría la pena una charla por sí sola, pero está relacionada con el hecho de que son transferibles. ¿Qué es eso? Sí, bueno, como dije, probablemente valga la pena una charla por sí sola. Así que algo que hace todo esto significa que también puedes usar la lógica del despachador para hacer algo de magia, ¿de acuerdo? De hecho, debido a cómo funciona esto, el nuevo RFC 9110 de HTTP simplemente separa la semántica de los transportes, de HTTP 1 y HTTP 2.2. Entonces, básicamente, el formato de conexión ahora es solo un detalle de implementación. Básicamente, significa que podemos implementar la lógica de HTTP, ¿de acuerdo? La semántica de HTTP en prácticamente cualquier cosa, lo cual es fantástico. Esto significa que podemos desvincular completamente nuestro sistema del transporte HTTP. De hecho, esta es la lógica que usamos para el multiplexor. Entonces, de hecho, podríamos implementar un sistema que haga HTTP sin red. Para hacer eso, necesitamos una forma de inyectar una solicitud HTTP en otro servidor, lo cual es bastante bueno, ¿de acuerdo? Este módulo se llama LightMyRequest, y de hecho, está integrado en uno de los frameworks que construí llamado Fastify. Y es un framework bastante bueno, pero puedes tomarlo y llamar a inject en él, y esto funciona sin abrir ningún socket HTTP. Entonces, lo que podrías hacer es implementarlo con Fastify, el despachador Fastify Undici, que es otro despachador de Undici que omite completamente la lógica de solicitud HTTP y crea básicamente una red de malla dentro de tu proceso para enrutar tus solicitudes a tu servidor Fastify. Es bastante fantástico. De hecho, es lo que usamos en mi startup. Se llama platformatic, y ayudamos a los desarrolladores a deshacerse y diferenciar el trabajo pesado de construir aplicaciones Node.js. De hecho, te hacemos ir muy rápido de A a B, y luego te ayudamos a ir exactamente donde necesitas ir, dándote todas las herramientas como un SUV muy, muy simple. Entonces, sí, todo esto, que te conté, alimenta la nueva plataforma de ejecución platformatic, que es un sistema para ejecutar múltiples microservicios dentro de la misma caja, dentro del mismo proceso. Y no sé, échale un vistazo. Está ahí. No creo que tenga tiempo para una demostración, pero mantente atento, porque publicaré algo más temprano que tarde en este frente. Y muchas gracias por ver, 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.
Node Congress 2022
JSNation 2023
JSNation Live 2021
React Summit 2022
TestJS Summit 2023
Comments