Evolución del cliente HTTP de Node con undici

Rate this content
Bookmark

Cuáles son algunos de los problemas del cliente HTTP actual de Node Core y cómo podemos superarlos? Una charla sobre cómo undici intenta dar el siguiente paso en el lado del cliente HTTP en Node. Incluye algunos consejos prácticos para usar undici y trampas comunes con algunos comentarios sobre decisiones de diseño de API y planes futuros con una bonificación adicional de Fetch API.

35 min
18 Feb, 2022

Video Summary and Transcription

La charla discute el estado actual del cliente HTTP de Node y los problemas que enfrenta, incluida la falta de soporte para la canalización HTTP y el vínculo intrínseco entre los objetos de solicitud y respuesta. El orador presenta la biblioteca Indichy, que tiene como objetivo proporcionar una API más fácil de usar para HTTP en Node. La charla destaca las ventajas de rendimiento de usar WebAssembly en el cliente HTTP de Umidigi y los planes de incluirlo en Node Core. El orador también menciona el soporte para señales y la capacidad de enviar solicitudes en Umidigi. Además, la charla cubre las opciones de personalización en Undici, los diferentes tipos de despachadores disponibles y la posible inclusión de Indichy en Node Core. Los planes futuros incluyen soporte para HTTP 2 y 3, mejoras en la búsqueda de DNS y mejoras en la programación de fetch y pool. La charla concluye discutiendo las diferencias en las implementaciones de TCP en los sistemas operativos y las consideraciones para agregar API y estándares web a Node Core.

Available in English

1. Introducción al cliente HTTP de Node y a Indichy

Short description:

Hola a todos. Mi nombre es Robert Nagy. Soy el desarrollador principal en Next Edition y un colaborador frecuente de Node.js y también miembro de TSC. Voy a hablar sobre el estado actual del cliente HTTP de Node y los problemas que vemos. El objeto de respuesta no es realmente un flujo de Node, carece de soporte para la canalización HTTP y los objetos de solicitud y respuesta están intrínsecamente vinculados. Hemos intentado solucionar estos problemas varias veces, pero es difícil sin causar disturbios. Hace unos años, Matteo Macalina creó la biblioteca Indichy, que tiene como objetivo proporcionar una API más fácil de usar para HTTP en Node.

Hola a todos. Mi nombre es Robert Nagy. Soy el desarrollador principal en Next Edition y un colaborador frecuente de Node.js y también miembro de TSC. Y voy a hablar un poco sobre el trabajo que hemos estado haciendo en el cliente HTTP de Node utilizando una biblioteca que creamos llamada Bitchy.

Entonces, en primer lugar, hablemos un poco sobre el estado actual del cliente HTTP de Node. Creo que la mayoría de las personas están familiarizadas con la API de solicitud HTTP. Y las personas que están utilizando bibliotecas de NPM como Got y Axios, etc., generalmente son solo envoltorios alrededor de la llamada de solicitud HTTP que proporciona Node Core. Ahora, esto tiene una larga historia y ha funcionado durante mucho tiempo. Pero aquellos de nosotros que hemos estado trabajando en el mantenimiento de esta API sentimos que hemos llegado al final de lo que podemos hacer con un esfuerzo razonable con esta API. Entonces, ¿cuáles son algunos de los problemas que vemos aquí? En primer lugar, el objeto de respuesta que recibes de la API de solicitud no es realmente un flujo de Node. Solo finge ser un flujo de Node. Hay varias razones, tanto de compatibilidad como de rendimiento, para eso. Pero hay pequeñas diferencias que pueden causar problemas extraños si tienes mala suerte. Especialmente si estás utilizando API que esperan flujos y quieres usarlos sin problemas. No tiene soporte para la canalización HTTP. La canalización es una característica del protocolo HTTP que puede proporcionar algunas ventajas significativas en términos de rendimiento. Además, el objeto de solicitud y el objeto de respuesta en esta API están intrínsecamente vinculados. Entonces, si destruyes, por ejemplo, la solicitud, aunque haya terminado, también matará la respuesta. Y esta vinculación es muy difícil de solucionar o eliminar sin romper todo el ecosistema. Está completamente basado en flujos, lo que causa algunas limitaciones en lo que podemos lograr en términos de rendimiento. Y muchos de los detalles internos de la API son accesibles públicamente, y tenemos módulos del ecosistema que dependen de detalles de implementación interna. En ese momento, no teníamos símbolos, por lo que no era posible ocultar cosas a los usuarios. Y todas estas cosas causan problemas que creemos que son muy difíciles de solucionar sin causar disturbios innecesarios en todo el ecosistema. Hace unos años, Matteo o en realidad, otro punto aquí es que hemos intentado solucionar estos problemas varias veces, y eso ha causado problemas y hemos tenido que revertirlos. En realidad, soy una de las personas que ha pasado mucho tiempo tratando de resolver estos problemas. Y es bastante decepcionante cuando te ves obligado a revertirlos debido a regresiones de compatibilidad o rendimiento, etc. Aquí hay algunas solicitudes de extracción que simplemente revierten el trabajo que se ha realizado en este sentido. Hace unos años, Matteo Macalina creó esta biblioteca llamada Indichy, que es una nueva forma de ver lo que HTTP puede y podría ser en Node. Y me involucré hace un año aproximadamente, y he hecho mucho trabajo para que esto esté listo para producción. Entonces, ¿cuáles son nuestros objetivos? ¿Qué estamos logrando o tratando de lograr con Indichy? Queremos una API un poco más fácil de usar para que las personas no tengan que recurrir a un tercero.

2. Node HTTP Client y Umidigi

Short description:

Hemos logrado reemplazar todo el cliente HTTP fuera del núcleo de Node utilizando WebAssembly, lo cual proporciona ventajas de rendimiento. Umidigi admite Keepalive y canalización, abordando problemas en el núcleo de Node. Hemos resuelto el problema con Keepalive en Umidigi y hemos logrado un rendimiento casi 10 veces mejor en comparación con el cliente del núcleo de Node. Estamos desarrollando Umidigi fuera del núcleo para su inclusión posterior y hemos ocultado todos los detalles internos detrás de símbolos. También estamos considerando implementar fetch sobre Umidigi. Es importante consumir o destruir el cuerpo para liberar la conexión y proporcionamos una función auxiliar llamada dump. Tenemos soporte para señales.

La biblioteca Unleashy es la biblioteca predeterminada. No queremos tener dependencias nativas. Por lo tanto, esto es realmente necesario para nosotros, para reemplazar todo el cliente HTTP fuera del núcleo de Node, necesitamos dependencias nativas. Y el análisis HTTP de nodos es HTTP, que es una biblioteca nativa. Pero hemos logrado solucionar esto utilizando WebAssembly, y está funcionando muy bien, y realmente vemos algunas ventajas de rendimiento al usar WebAssembly. Especialmente ahora, también, que WebAssembly tiene soporte SIMD limitado. Otra cosa importante es que queremos admitir Keepalive y canalización, así que voy a explicarlo rápidamente. Keepalive es algo que el cliente del núcleo de Node admite, pero no está habilitado de forma predeterminada. Y hay algunas cosas en las que debes pensar en el núcleo de Node que Unleashy intenta manejar por ti. Sin canalización, cada solicitud que hagas crea una nueva conexión y la cierra. Con Keepalive, puedes reutilizar la conexión para solicitudes posteriores. De esta manera, evitas los gastos generados por cerrar y establecer una nueva conexión. Y con la canalización, es posible enviar varias solicitudes antes de que el servidor haya respondido. De esta manera, puedes reducir parte de la latencia de tus solicitudes. Y hemos dedicado mucho tiempo a asegurarnos de que Unleashy admita esto de forma nativa. Como mencioné, hay un problema con Keepalive que el núcleo de Nord no maneja, y es que una vez que se establece una conexión, hay un tiempo de espera en el que el servidor mantendrá esa conexión activa, esperando más solicitudes antes de cerrarla. Ahora, si tienes mala suerte, podrías enviar una solicitud en el momento exacto en que se agota el tiempo de espera del servidor y, por lo tanto, el servidor cerrará la conexión mientras tu solicitud está llegando. Algunos servidores proporcionan una pista de Keepalive en sus respuestas para que puedas averiguar durante cuánto tiempo espera el servidor mantener abierta la conexión y, por lo tanto, el cliente puede hacer cosas para evitar este cierre inesperado. Eso es algo que hemos resuelto en Umidigi. También hemos considerado el rendimiento, por lo que con Umidigi logramos un rendimiento casi 10 veces mejor en comparación con el cliente del núcleo de Node, lo cual debo decir que es un resultado bastante bueno. Estamos desarrollándolo fuera del núcleo en este momento para su inclusión posterior. Hay algunas ventajas en esto, especialmente en términos de la velocidad de implementación, y hemos ocultado todos los detalles internos detrás de símbolos para que no tengamos dependencias de terceros que dependan de detalles de implementación. También estamos considerando implementar fetch sobre Umidigi. La API básica de Umidigi es la solicitud de Umidigi y básicamente haces un await Umidigi request donde obtienes un cuerpo, un código de estado y encabezados, y el cuerpo es un flujo de nodos, pero también hemos implementado algunas funciones auxiliares inspiradas en las especificaciones de cuerpo de fetch, por lo que tienes body.text.json.array buffer y puedes esperar a esos, pero de lo contrario, el cuerpo es un flujo normal de node.js. Así que esto es bastante simple. Una nota importante que he notado que algunas personas pasan por alto es que es muy importante, incluso si no te importa el cuerpo, consumirlo o destruirlo para liberar la conexión, porque la forma en que funciona con el keep-alive es que a menos que la solicitud anterior haya finalizado, no puedes procesar la siguiente, por lo que es importante destruir el cuerpo o eliminarlo o consumirlo. Proporcionamos una función auxiliar llamada dump, que la desventaja de destruir el cuerpo es que eso en realidad hará que el socket se destruya. Tenemos una función auxiliar aquí llamada dump que intentará leer todo el cuerpo para que se pueda reutilizar la conexión, pero si el cuerpo o la respuesta del servidor supera un cierto umbral, entonces elige cerrar eventualmente la conexión. Por lo tanto, no tienes que descargar un gigabyte de datos antes de poder reutilizar la conexión. Y sí, si no haces esto, la conexión no se liberará para la siguiente solicitud.

3. Soporte para señales y solicitudes POST

Short description:

Tenemos soporte para señales y la capacidad de enviar solicitudes POST. Sin embargo, se recomienda evitar el uso de solicitudes HEAD debido a problemas de compatibilidad con los servidores. En su lugar, puedes usar una solicitud de rango o leer un byte de información para lograr una funcionalidad similar.

Tenemos soporte para señales como cualquier buen ciudadano del mundo de las promesas. También puedes enviar solicitudes POST. Simplemente pasa el cuerpo como una opción al método de solicitud. Por favor, evita usar HEAD. Las solicitudes HEAD tienen algunas limitaciones debido a problemas de compatibilidad con los servidores que pueden o no enviar un cuerpo con la respuesta HEAD y, por lo tanto, Undici siempre elige cerrar las conexiones para estar seguros. Una solución alternativa para mantener una funcionalidad similar con el mismo rendimiento es usar una solicitud de rango si es posible o puedes leer un byte y recibir mucha de la información.

4. Configuración de Keepalive y Stream API en Undici

Short description:

Keepalive proporciona opciones para personalizar la configuración de las solicitudes. Se puede crear un despachador llamado despachador de agente en Undici para cambiar estas configuraciones. Puedes configurar el tiempo de espera de Keepalive, la profundidad de la canalización y el número de conexiones a un servidor. Si una solicitud en la canalización falla, Undici volverá a intentar las solicitudes idempotentes subsiguientes. La API de transmisión se puede utilizar para evitar la sobrecarga de rendimiento innecesaria del flujo de enlace legible en la API de solicitud.

Keepalive proporciona algunas opciones. Puedes crear tu propio despachador personalizado llamado despachador de agente en Undici que te permite cambiar algunas configuraciones sobre cómo se realizan las solicitudes. Aquí estamos creando un despachador llamado despachador de agente que tiene algunas opciones. Podemos tener un tiempo de espera de Keepalive. Este es el tiempo que esperamos que el servidor mantenga la conexión abierta. Esto probablemente debería ser menor de lo que esperas que haga el servidor. Si el servidor proporciona estas indicaciones de Keepalive, eso anulará cualquier configuración que uses aquí, por lo que puedes ser bastante agresivo al ponerlo en un valor bajo.

Tenemos un límite, por lo que si el servidor proporciona una indicación de dos días, es posible que no quieras usar eso. Así que tenemos un umbral máximo para no superarlo. Y también, dado que el tiempo de espera de la conexión en realidad es desde el momento en que el servidor envió la respuesta, hay un retraso en el envío de la respuesta para que Undici la reciba. Por lo tanto, tenemos un umbral de tiempo de espera que básicamente tiene en cuenta las latencias de transporte. El tiempo de espera es de cinco segundos. Quitaremos un segundo para que el cliente asuma que quedan cuatro segundos hasta que la conexión sea cerrada por el servidor. Eso es todo con eso. También puedes configurar la canalización. Undici no realiza canalización de forma predeterminada. Por lo tanto, puedes configurar aquí qué tan profunda debe ser la canalización, cuántas solicitudes puede enviar Undici antes de recibir una respuesta del receptor. Cuál es el mejor valor aquí es un poco difícil de decir. Depende de tu caso de uso, pero generalmente dos o tres está bien. Y luego también puedes elegir cuántas conexiones puede hacer Undici a un servidor. Entonces, si haces una solicitud a un servidor y no hay una conexión disponible, entonces Undici iniciará una nueva conexión. Y de esta manera puedes limitar el número de conexiones, similar a cómo funciona en Node Core. Una cosa importante a tener en cuenta es que si tienes varias solicitudes en cola en la canalización y la que está al principio de la cola de canalización falla, entonces Undici automáticamente cerrará la conexión y volverá a intentar todo después de la que falló, si esas solicitudes son idempotentes, como las solicitudes GET y PUT. De lo contrario, tendrás que volver a intentar las cosas tú mismo. Ahora, hay algunas otras API con las que hemos estado experimentando en Undici. Una de las desventajas de la API de solicitud es que siempre crea este flujo de enlace legible. Entonces, básicamente, Undici lee desde el socket, lo analiza con el LLHTP y luego lo escribe en el flujo legible, y luego lo lees del flujo legible para usarlo. Y esto tiene esta sobrecarga de rendimiento innecesaria del enlace. Puedes evitar eso utilizando la API de transmisión, que básicamente te permite devolver un flujo escribible donde se debe escribir la respuesta, en lugar de este flujo de enlace intermedio. Como notaste antes, hay un cierre

5. API de Undici y Despachadores

Short description:

Proporcionamos una opción para enviar una propiedad OPAC para micro-optimización. Tenemos un pipeline UDG para crear fácilmente pipelines de transformación para solicitudes HTTP. Undici es extensible y utiliza despachadores para manejar diferentes tipos de solicitudes. Hay diferentes tipos de despachadores disponibles, incluyendo el cliente undici, el grupo undici, el grupo equilibrado, el agente undici y el agente proxy. Todos estos métodos utilizan el despachador global de forma predeterminada, pero puedes pasar un despachador en las opciones para utilizar uno diferente.

Siempre se crea aquí. Por lo tanto, proporcionamos una opción para enviar una propiedad OPAC, que se proporcionará en la devolución de llamada. Y de esta manera, el motor V8 no necesita crear el cierre. Esto es un poco de micro-optimización, pero la opción está ahí. También tenemos un pipeline UDG, que se utiliza para crear fácilmente los pipelines de transformación que son solicitudes HTTP. Entonces, envías datos en una solicitud HTTP y luego obtienes un cuerpo de datos de respuesta. Y luego puedes usarlo con pipelines de transmisión, por ejemplo. En realidad, no necesitas esto. Puedes lograr lo mismo con solicitudes undici y un generador. Es un poco más de código adicional, pero esto también es bueno. Esta es también una de las razones por las que estamos desarrollando undici fuera del núcleo, para experimentar con diferentes ideas de API. Ahora undici es muy extensible. Básicamente utiliza el concepto de un despachador para despachar diferentes tipos de solicitudes. La API es bastante simple. Necesitas implementar estos métodos y también el evento llamado brain. No entraré en detalles aquí. Pero proporcionamos algunos tipos diferentes de despachadores que se pueden utilizar. Primero, tenemos el cliente undici, que es el más básico. Te proporciona una conexión única al servidor y admite keep alive y también te permite seguir las respuestas de redireccionamiento. Luego tenemos el grupo undici, que crea varios clientes y luego despacha solicitudes en múltiples conexiones y utiliza una programación de profundidad primero. Si tienes un cliente y cada cliente tiene un valor de canalización de dos, primero llenará la canalización antes de pasar a la siguiente conexión. Tenemos un grupo equilibrado, mientras que el grupo anterior siempre se conectará al mismo servidor. Por lo tanto, tendrá múltiples conexiones al mismo servidor. El grupo equilibrado te permite conectarte a diferentes servidores y tener solicitudes equilibradas entre ellos y también utiliza una programación de profundidad primero. El agente undici se basa en el grupo y te permite tener múltiples orígenes diferentes y también seguirá las redirecciones entre orígenes cruzados. También tenemos un agente proxy que te permite hacer proxy a través de servidores. No entraré en detalles aquí. Y todos estos métodos te han mostrado la solicitud undici. Utilizan algo que llamamos el despachador global, que es el valor predeterminado y puedes cambiarlo tú mismo. Y luego todas las llamadas que no establecen explícitamente un despachador utilizarán ese valor. Pero también puedes pasar un despachador en todas estas API en las opciones y luego

6. Personalización e Indichi en el Núcleo

Short description:

Admitimos redirecciones y permitimos la personalización de las conexiones del servidor. Puedes proporcionar un método de conexión para implementar tu propio socket personalizado o búsqueda de DNS. Hemos estado discutiendo la inclusión de Indichi en el núcleo, considerando los pros y los contras. La implementación de fetch basada en Indichi está en progreso, con soporte experimental en Node 17. Se agradecen las contribuciones a la implementación de fetch. Hay algunas diferencias con el Web Bear, especialmente en la recolección de basura en Node.js.

Siempre se crea aquí. Como mencioné antes, admitimos redirecciones y solo tienes que pasar el número máximo de redirecciones que permites y Unleash se encargará de eso. También podemos personalizar cómo nos conectamos a los servidores. Por lo tanto, puedes proporcionar a algunos de los despachadores una implementación de método de conexión, que como puedes ver, toma algunos parámetros y luego puedes tener tu propia implementación personalizada de socket o búsqueda de DNS. Por ejemplo, si tienes una implementación rápida, podrías ejecutar HTTP sobre quick aquí simplemente proporcionando un objeto que se parezca a un socket, pero que funcione con quick. Algunos de los despachadores tienen estos métodos de fábrica. Por ejemplo, pool o agent, estos utilizan despachadores internamente, por lo que tienen su propia lógica y luego despachan a un subdespachador y puedes cambiar cómo sería eso. Entonces, en el caso del agente, el método de fábrica predeterminado verifica cuántas conexiones has pasado. Si es uno, entonces utiliza un cliente porque tiene menos sobrecarga ya que no tienes que administrar conexiones. De lo contrario, utiliza un pool, pero aquí podrías usar tu propia implementación personalizada y reutilizar la lógica del agente. Hemos estado discutiendo la inclusión de Indichi en el núcleo. Es una discusión en curso con pros y contras, por qué deberíamos incluirlo o por qué no. Tiene, sí, solo diría que eches un vistazo al problema y leas a través de él. Hay muchos pensamientos allí. Una de las ventajas importantes de tenerlo fuera del núcleo ha sido la velocidad de desarrollo. Pero a medida que las cosas se vuelven más estables y se piensan más, podría ser el momento de incluirlo en el núcleo. Ahora también hemos invertido mucho trabajo en la implementación de fetch basada en Indichi, y actualmente estamos implementando el soporte experimental en la versión 17 de Node. Así que está bajo la bandera experimental de fetch. Ahora estamos cerca de tener finalmente un fetch en el núcleo. Si ustedes quieren ayudar a que sea no experimental, por favor diríjanse al repositorio de Indichi y ayúdennos a mejorar las pruebas. Y siempre hay casos especiales de cumplimiento de especificaciones que se pueden encontrar y resolver. Es bastante fácil contribuir a la implementación de fetch en Ditche. Estamos utilizando una forma muy literal de implementar la especificación en Indichi. Básicamente, tomamos la especificación y tratamos de seguir los pasos de la especificación lo más literalmente posible. Así que si quieres ayudar, solo lee la especificación. Aquí hay algunas tareas pendientes que puedes ver si puedes resolver. Pero es razonablemente fácil contribuir. Tenemos algunas diferencias con el Web Bear y principalmente en cómo funciona la recolección de basura. En el navegador, fetch se recolectará automáticamente. Estaba hablando de que siempre tienes que consumir el cuerpo. Eso es lo mismo en fetch. El navegador lo hace automáticamente durante la recolección de basura. Pero la recolección de basura

7. Enfoque en la Usabilidad y Trabajo Futuro

Short description:

Actualmente nos estamos enfocando en la usabilidad y el cumplimiento, con mejoras de rendimiento en proceso. El trabajo futuro incluye soporte para HTTP 2 y 3, búsqueda de DNS para balance de pool y soporte de pool, y mejoras en fetch y programación de pool. También tenemos como objetivo abordar la falta de soporte para solicitudes HTTP 100 continue en la especificación HTTP 1. Gracias por su atención.

. Estamos implementando el archivo desde el núcleo para cumplir completamente con la especificación. Y en este momento, nos estamos enfocando en la usabilidad, haciéndolo fácil de mantener y contribuir, y en el cumplimiento. El rendimiento no es la prioridad en este momento. Pero, por supuesto, también estamos buscando mejorar eso. Pero personalmente recomendaría usar otras APIs si el rendimiento es la parte más importante. Creo que fetch es bueno para la usabilidad, la compatibilidad entre navegadores y Node.

Trabajo futuro. Por supuesto, nos encantaría admitir HTTP 2 y 3. Así que eso es algo en lo que estamos trabajando . Sería genial tener búsqueda de DNS para el balance de pool y el pool. Estamos buscando mejorar fetch. También la programación de pool, la forma en que se envían y programan las solicitudes en múltiples conexiones. Hay cosas interesantes que se pueden hacer allí. ¿Debería ser una programación en profundidad o en anchura? ¿Deberíamos ponderar las diferentes conexiones según su latencia y cuántas veces ha fallado una solicitud en una conexión o en el servidor? Entonces, hay muchas cosas interesantes por hacer allí. Y todavía nos falta soporte para solicitudes HTTP 100 continue en la especificación HTTP 1. Eso es todo lo que tengo. Si tienen alguna pregunta, espero poder responderlas. Y eso es todo. Gracias. Parece que tenemos un claro ganador. Entonces, el 48% de las personas usan fetch. ¿Te sorprende esto en absoluto? Tanto sí como no. Creo que fetch es la API con. Recientemente la hemos lanzado como experimental en Node.js. Así que supongo que fue un buen movimiento dado este resultado. Y personalmente, estoy más enfocado en el rendimiento. Así que uso request, que es el menos común aquí en la votación, lo cual también es bastante sorprendente. Así que sí, es una buena pista de dónde poner más energía.

QnA

Implementación de Node Fetch y Preguntas y Respuestas

Short description:

El Fetch en Node se basa en undici, no en el código normal de Node HTTP. Nock no funciona con undici, pero undici tiene su propia implementación de simulación. NodeCore actualmente no admite Qwik, pero hay planes para agregar soporte en undici. Las pruebas de rendimiento muestran que reutilizar conexiones en undici es significativamente más rápido que abrir y cerrarlas todo el tiempo.

Sí, eso suena genial. Nuestra audiencia tiene muchas preguntas para ti. Pero yo tengo aún más. Una cosa, hablaste de la implementación de Fetch en Node. Y estoy bastante emocionado por eso. Espero que todos lo estén. ¿Usa undici? ¿Tiene algo en común?

Sí. En realidad, el Fetch en Node se basa en undici. No exponemos nada de undici excepto Fetch en Node, y esa es una decisión consciente para no exponer dos APIs experimentales que pueden cambiar y romperse más adelante. Pero la implementación de Fetch se realiza sobre undici, no sobre el código normal de Node HTTP.

Eso es increíble. Supongo que todos los que ejecutan Node estarían básicamente en undici ahora. Esa es la mejor manera de... Oh, tenemos una pregunta de nuestro orador, Joda Developer, quien preguntó, ¿cómo simular una solicitud en undici? Por ejemplo, hay una biblioteca llamada Nock que te permite simular solicitudes. Entonces, si estás usando solicitudes undici, ¿has intentado simularlo? ¿Y cómo lo harías?

Nock no funciona porque depende de los detalles internos del cliente HTTP. Tenemos una simulación implementada en undici. Entonces, hay un cliente simulado y un grupo simulado y las herramientas necesarias para hacer básicamente lo mismo que harías con Nock. Todo está ahí.

Eso es increíble. También agentil1990 pregunta, ¿cómo es el soporte para Qwik en el futuro? Sé que NodeCore admite Qwik ahora, ¿verdad? Pero, ¿qué hay de undici?

NodeCore aún no admite Qwik. Creo que se agregó como experimental, pero luego se eliminó. Hay una solicitud de extracción en la que James está trabajando para agregarlo. A menos que me haya perdido algo, pero una vez que se agregue, debería ser bastante fácil agregar soporte para eso en undici para implementar HTTP1 sobre Qwik. Implementar el soporte HTTP3 es un poco más trabajo. Eso suena realmente interesante. Gracias. Otra pregunta es, ¿hay alguna prueba de rendimiento sobre la sobrecarga de crear una nueva conexión cada vez en comparación con el enfoque undici?

Tenemos algunas pruebas de rendimiento incluidas. Y sí, es difícil decir de dónde vienen todas nuestras mejoras de rendimiento. Y nuevamente, depende de tu caso de uso. Pero diría que es significativamente más rápido reutilizar conexiones que abrir y cerrarlas todo el tiempo.

Differences in TCP and the Future of HTTP in Node

Short description:

¿Existen diferencias notables entre los sistemas operativos en cuanto a las implementaciones de TCP? El plan actual es incluir Undici en Node Core, pero hay consideraciones en cuanto a la estabilidad, la superficie de la API y el futuro de HTTP en Node. La adición de API y estándares web a Node Core es un tema debatido, con argumentos a favor de soluciones personalizadas y uniformes. Fetch, aunque específico para navegadores, mejora la experiencia y familiaridad del desarrollador. Puede tener un rendimiento inferior en comparación con otras API, pero ofrece comodidad para una implementación rápida.

Especialmente en cuanto a la latencia. Ya veo. ¿Existen diferencias notables entre los sistemas operativos? ¿Las implementaciones de TCP realmente marcan la diferencia aquí? En cuanto a la sobrecarga de la CPU, tal vez. Pero aún así, necesitas realizar las acciones requeridas por el handshake de TCP. Así que es más una cuestión de protocolo de red. De acuerdo. Bueno, la siguiente pregunta es, ¿cuál es el plan actual o el progreso para incluir Undici en Node Core? Acabamos de hablar sobre fetch y cómo se ejecuta en Undici. Recuerdo que en el pasado ha habido múltiples solicitudes para agregar cosas como OWG streams a Node. ¿Crees que este hito de fetch abriría la puerta a una serie de otras cosas? El enfoque principal ha sido implementar todos los estándares web en Node.js porque están bien especificados y no se esperan muchos cambios en el futuro. Una vez que lo tengamos y una vez que aterricemos Undici en Core, eso pone algunas restricciones en lo que podemos hacer en Undici y qué tan rápido podemos hacer las cosas. Siempre hay un equilibrio entre tenerlo en Node Core y darle una marca de que no romperemos las cosas o tenerlo fuera y mantener la velocidad de desarrollo en él. Creo que estamos cerca de llegar al punto en el que Undici se siente estable en cuanto a la superficie de la API. Así que podría valer la pena incluirlo en Core. Pero me gustaría ver un plan más amplio en términos tanto del lado del servidor como del cliente sobre cómo queremos que sea el futuro de HTTP en Node antes de comenzar a incluir nuevas API. Sí, eso es realmente interesante. Una cosa, mencionaste agregar más de estas API web y luego estándares web, por así decirlo, en Node Core. Ahora, esto es algo muy debatido, ¿verdad? No todos están de acuerdo en que agregar cosas como Fetch a Node sea una buena idea. Una de las razones por las que solían apoyarlo es diciendo que Fetch en general está diseñado por organismos como WG, que se centran en casos de uso de navegadores, y por lo tanto, una implementación alternativa de HTP que se preocupe más por los casos de uso del lado del servidor sería más apropiada para Node. ¿Cómo crees que se compara esto? Y por ejemplo, hay muchas cosas en Fetch que son específicas de los navegadores, como los cookie jars. ¿Cómo funciona eso en DG? Sí, quiero decir, esto siempre es un equilibrio entre hacer una solución personalizada o una solución uniforme. Creo que muchas de las cosas con Fetch mejoran la experiencia del desarrollador, facilitando la escritura de un buen código, ¿verdad? Porque las personas trabajan en el navegador, por lo que de todos modos necesitan conocer Fetch. Y conocen los detalles y los casos especiales allí. Y luego tener que aprender una tercera, cuarta, quinta y sexta API, incluso si son mejores para casos de uso específicos, tiene algunas desventajas. Por ejemplo, Fetch, Fetch en Undici, tiene un rendimiento inferior a otras API que proporcionamos, como Undici Request. Pero aún así es una buena idea incluirlo porque ayuda a la familiaridad del desarrollador. Y las horas de desarrollo son mucho más caras que comprar hardware más rápido. Así que creo que eso es un poco, esa es mi opinión sobre todo el asunto. Si solo quieres hacer las cosas rápidamente y que funcionen, usa Fetch en Undici. Si el rendimiento es tu máxima prioridad, entonces recomendaría algunas de las otras API que aún no se incluyen.

Undici Fetch Implementation and Future Plans

Short description:

Existen ciertos detalles de implementación en Fetch que solo tienen sentido en un contexto de navegador, como las cookies. En Undici, intentamos seguir la especificación literalmente, incluso si no es posible en un entorno de Node.js. Las redirecciones en Undici Fetch funcionan de manera diferente a las del navegador, siguiendo el enfoque de CloudFlare y Deno. La recolección de basura y el consumo de respuestas también son consideraciones importantes. Undici ha inspirado correcciones en las transmisiones principales de Node. Los planes futuros para Undici incluyen el soporte para Quick, HTTP 2 y HTTP 3. Estamos esperando la clase File de la especificación web para una implementación completa de Fetch.

Sí, eso suena realmente genial. Gracias. Creo que hice la pregunta demasiado larga, pero intenté enfatizar en una segunda parte. La suite de pies, existen ciertos detalles de implementación en Fetch que solo tienen sentido en un contexto de navegador. Cosas como las cookies y demás. Entonces, ¿cómo funciona eso en Undici? Buena pregunta, y eso es algo que tenemos que manejar caso por caso. En realidad, tenemos algunas, la forma en que implementamos Fetch en Undici es que intentamos seguir la especificación literalmente. Así que implementamos una especificación que no es posible alcanzar en un entorno de Node.js, con la esperanza de que en el futuro podamos modificar la especificación o hacer nuestras propias modificaciones para que las cosas funcionen.

Por ejemplo, las redirecciones en Undici Fetch funcionan de manera un poco diferente a las del navegador. Hemos seguido el enfoque de CloudFlare y Deno. También hay problemas como la recolección de basura que pueden afectar el comportamiento de la implementación y si es importante consumir completamente todas las respuestas o no. En Undici Fetch, debes consumir las respuestas mientras que en el navegador es un poco más sencillo. Se limpiará durante la recolección de basura.

Sí, gracias. Eso fue realmente esclarecedor. Tenemos otra pregunta de los espectadores que dice, ¿Undici es tu principal impulsor para las numerosas correcciones que has realizado en las transmisiones principales de Node? ¿O, en otras palabras, la complejidad de las transmisiones fue un obstáculo para el desarrollo de Undici? Supongo que sí, pero ni siquiera me di cuenta en ese momento. Así que he estado tratando de, pasé mucho tiempo trabajando en las transmisiones HTTP y el cliente y servidor HTTP en Node. Y gran parte del trabajo consistió en hacer que las transmisiones funcionaran de manera adecuada. Tuve una charla en no TLV sobre este problema con las transmisiones y una vez que llegué tan lejos como pude con las transmisiones y me encontré con el obstáculo con el tema de HTTP, fue entonces cuando pasé a Undici. Y sí, hay algunas correcciones en las transmisiones inspiradas en los problemas que encontré en Undici. Sí, es bastante interesante. Recuerdo que este tema de reformar las transmisiones de notas ha sido un tema tan largo y la gente ha pensado en esto durante mucho tiempo. Me alegra que estés progresando en esto. Otra pregunta que tengo para ti. Ya tienes muchas características interesantes en Undici. ¿Hay algún otro estándar web o función web que esté en tu radar? ¿Hay algo que planees hacer a continuación? Un poco de lo que hablamos, está Quick y HTTP 2 y HTTP 3, y eso es lo que estamos investigando en Undici, y por supuesto en Node Core estamos esperando la clase File de la especificación web para poder implementar completamente Fetch. Genial. Bueno, eso es increíble. Muchas gracias Robert, y esta fue una presentación increíble, y fue bastante informativa, al menos para mí, y espero que lo mismo se aplique a todos nuestros espectadores. Si aún no has terminado de hacer todas estas preguntas a Robert, es posible que desees unirte a él en la sala de oradores, así que hay un enlace a la sala de oradores. Únete a él en Spatial Chat. Muchas gracias Robert. Gracias.

Check out more articles and videos

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

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 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
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.
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 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.