Video Summary and Transcription
La charla discute el estado actual del cliente HTTP de Node y los problemas que enfrenta, incluyendo la falta de soporte para el canalizado HTTP y el vínculo intrínseco entre los objetos de solicitud y respuesta. El orador introduce la biblioteca Indichy, que tiene como objetivo proporcionar una API más amigable para el usuario para HTTP en Node. La charla destaca las ventajas de rendimiento de usar WebAssembly en el cliente HTTP de Umidigi y los planes para incluirlo en Node Core. El orador también menciona el soporte para señales y la capacidad de publicar 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 a través de los sistemas operativos y las consideraciones para agregar APIs web y estándares a Node Core.
1. Introducción al cliente HTTP de Node e Indichy
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 del 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 el canalizado 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 perturbaciones. Hace unos años, Matteo Macalina creó la biblioteca Indichy, que tiene como objetivo proporcionar una API más amigable para el usuario para HTTP en Node.
Hola a todos. Mi nombre es Robert Nagy. Soy el desarrollador principal en Next Edition y un colaborador frecuente a Node.js y también miembro del TSC. Y voy a hablar un poco sobre algunos trabajos que hemos estado haciendo en el cliente HTTP en Node usando una biblioteca que creamos llamada Bitchy.
Entonces, primero que nada, 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 usando las bibliotecas de NPM como Got y Axios, etc., estas son generalmente 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í? Entonces, en primer lugar, el objeto de respuesta que recibe de la API de solicitud no es realmente un flujo de Node. Solo pretende ser un flujo de Node. Hay varias razones, tanto de compatibilidad como de rendimiento para eso. Pero hay ligeras diferencias que pueden causar problemas extraños si tienes mala suerte. Especialmente si estás usando APIs que esperan flujos, y querías usarlo de manera fluida. No tiene soporte para el canalizado HTTP. El canalizado es una característica del protocolo HTTP que puede proporcionar algunas ventajas significativas 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, incluso si ha completado, también matará la respuesta. Y este enlace es muy difícil de arreglar o eliminar sin romper todo el ecosistema. Está completamente basado en flujos, lo que causa algunas limitaciones de lo que podemos lograr en términos de rendimiento. Y muchos de los internos en la API son de acceso público, y tenemos módulos del ecosistema que dependen de los detalles de implementación internos. En aquel entonces, 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 perturbaciones indebidas en todo el ecosistema. Entonces, 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. 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. Entonces, aquí hay algunas solicitudes de extracción que simplemente revierten el trabajo que se ha hecho hacia esto. Entonces, hace unos años, Matteo Macalina creó esta biblioteca llamada Indichy, que es una nueva visión de lo que HTTP puede y podría, ser en Node. Y me involucré hace un año o así, y he hecho mucho trabajo para hacer esto listo para producción. Entonces, ¿cuáles son nuestros objetivos? ¿Qué es lo que estamos logrando o tratando de lograr dentro de Indichy? Entonces, queremos una API un poco más amigable para el usuario para que las personas no tengan que ir a un tercero
2. Cliente HTTP de Node y Umidigi
Hemos logrado reemplazar todo el cliente HTTP fuera del núcleo de Node utilizando WebAssembly, que ofrece ventajas de rendimiento. Umidigi soporta Keepalive y canalización, abordando problemas en Node Core. Hemos resuelto el problema con Keepalive en Umidigi, y hemos logrado un rendimiento casi 10 veces mejor en comparación con el cliente de Node Core. Estamos desarrollando Umidigi fuera del núcleo para su inclusión posterior y hemos ocultado todos los detalles internos detrás de los símbolos. También estamos considerando implementar fetch en Umidigi. Es importante consumir o destruir el cuerpo para liberar la conexión, y proporcionamos una función de ayuda llamada dump. Tenemos soporte para señales.
biblioteca por defecto. No queremos tener ninguna dependencia nativa. Así que esto es realmente necesario para nosotros, para poder reemplazar todo el cliente HTTP fuera del núcleo de Node, necesitamos dependencias nativas. Y el análisis HTTP en Node es HTTP, que es una biblioteca nativa. Pero hemos logrado sortear esto utilizando WebAssembly, y está funcionando muy bien, y de hecho vemos algunas ventajas de rendimiento al usar WebAssembly. Especialmente ahora, también, que WebAssembly tiene soporte limitado para SIMD. Otra cosa importante es que queremos soportar Keepalive y canalización, así que voy a explicar rápidamente eso. Keepalive es en realidad algo que el cliente de Node Core soporta, pero no está habilitado por defecto. Y hay algunas cosas que tienes que tener en cuenta en Node Core que Umidigi intenta manejar por ti. Así que sin canalización, cada solicitud que haces en realidad crea una nueva conexión y la cierra. Con Keepalive, puedes reutilizar la conexión para solicitudes posteriores. Así que te ahorras el sobrecoste de cerrar y establecer una nueva conexión. Y con la canalización, es posible enviar varias solicitudes antes de que el servidor haya respondido. Y así, puedes reducir algo de la latencia de tus solicitudes. Y hemos dedicado mucho tiempo a asegurarnos de que Umidigi soporta esto de forma nativa.
Y como mencioné, hay un problema con Keepalive que Nord Core no maneja, es que una vez que se establece una conexión, hay un tiempo de espera que el servidor mantendrá esa conexión viva, esperando más solicitudes antes de cerrar la conexión. Ahora, si tienes mala suerte, podrías enviar una solicitud en el momento exacto en que se produce el tiempo de espera del servidor y por lo tanto el servidor cerrará la conexión mientras tu solicitud está llegando. Ahora, algunos servidores proporcionan una pista de Keepalive en sus respuestas para que puedas averiguar durante cuánto tiempo el servidor espera mantener la conexión abierta, y por lo tanto, el cliente puede hacer cosas para evitar este cierre inesperado. Así que eso es algo que hemos solucionado en Umidigi. También hemos mirado el rendimiento así que con Umidigi fuimos capaces de lograr un rendimiento casi 10 veces mejor en comparación con el cliente de Node Core, lo cual tengo que decir que es un resultado bastante bueno. Lo estamos desarrollando fuera del núcleo en este momento para su inclusión posterior. Hay algunas ventajas de esto especialmente en términos de la velocidad de implementación y hemos ocultado todos los detalles internos detrás de los símbolos para que no tengamos una repetición de bibliotecas de terceros, dependiendo de los detalles de implementación. Y también estamos considerando implementar fetch en Umidigi. Así que la API más 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 nodo pero también hemos implementado algunas funciones de ayuda inspiradas en las especificaciones del cuerpo de fetch mixing así que tienes body.text.json.array buffer y puedes simplemente 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, debes 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 terminado no puedes procesar la siguiente así que es importante destruir el cuerpo o volcarlo o consumirlo. Proporcionamos una ayuda llamada dump, que la desventaja de destruir el cuerpo es que eso en realidad causará la destrucción del socket. Tenemos una función de ayuda aquí llamada dump que en realidad intentará leer todo el cuerpo para que la conexión pueda ser reutilizada pero si el cuerpo o la respuesta del servidor excede un cierto umbral entonces elige eventualmente cerrar la conexión. Así que no tienes que descargar un gigabyte de datos antes de poder reutilizar la conexión. Y sí, si no haces esto entonces la conexión no será liberada para la próxima solicitud.
3. Soporte para Señales y Solicitudes POST
Tenemos soporte para señales y la capacidad de realizar solicitudes POST. Sin embargo, se recomienda evitar el uso de solicitudes HEAD debido a problemas de compatibilidad con los servidores. En su lugar, puedes utilizar 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 realizar solicitudes POST. Simplemente pasas 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 Enduci en realidad siempre elige cerrar las conexiones para estar seguro. Una solución para esto con el fin de mantener la funcionalidad similar con el mismo performance es simplemente usar una solicitud de rango si es posible o puedes leer un byte y puedes recibir mucha de la información que
4. Configuración de Keepalive y Stream API en Undici
Keepalive ofrece opciones para personalizar la configuración de las solicitudes. Se puede crear un despachador llamado despachador de agente en Enduci para cambiar estas configuraciones. Puedes configurar el tiempo de espera de Keepalive, la profundidad del canalizado y el número de conexiones a un servidor. Si una solicitud en el canal falla, Undici volverá a intentar las solicitudes idempotentes subsiguientes. La API de transmisión se puede utilizar para evitar la sobrecarga de rendimiento innecesaria de la transmisión legible en la API de solicitud.
de lo contrario tendrías que usar una solicitud HEAD para. Keepalive ofrece algunas opciones. Puedes crear tu propio despachador personalizado en Enduci que te permite cambiar algunas configuraciones sobre cómo se hacen las solicitudes. Así que aquí estamos creando un despachador llamado despachador de agente que tiene algunas opciones. Así que podemos tener un tiempo de espera de Keepalive. Esto es cuánto tiempo 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 estos hints de Keepalive, entonces eso realmente anulará cualquier configuración que uses aquí, por lo que puedes ser bastante agresivo al ponerlo en bajo.
Tenemos un límite, así que si el servidor proporciona una pista, esa pista puede ser de dos días, entonces tal vez no quieras usar eso. Así que tenemos un umbral máximo por lo que no iré más allá. Y también desde el tiempo de espera de la conexión es en realidad desde el momento o desde el momento en que el servidor envió la respuesta, hay un retraso en la respuesta siendo enviada a recibir por Undici. Así que tenemos un umbral de tiempo de espera que básicamente, si toma en cuenta las latencias de transporte. El tiempo de espera es de cinco segundos. Quitaremos un segundo por lo que el cliente asume que quedan cuatro segundos hasta que la conexión sea eliminada por el servidor. Eso es todo con eso. También puedes configurar el canalizado. Undici no hace canalizado por defecto. Así que puedes configurar aquí qué tan profundo quieres que sea el canal, cuántas solicitudes puede enviar Undici antes de recibir una respuesta. Cuál es el mejor valor aquí es un poco difícil de decir. Depende de tu caso de uso, pero dos o tres suele estar bien. Y luego también puedes elegir cuántas conexiones puede hacer Undici a un servidor. Así que si haces una solicitud a un servidor y no hay ninguna 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, si tienes varias solicitudes en cola en el canal, y la que está al frente de la cola de canalización falla, entonces Undici automáticamente matará 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 APIs con las que hemos estado experimentando en Undici. Uno de los inconvenientes de la API de solicitud es que siempre crea esta transmisión de pegamento legible. Así, básicamente, Undici lee desde el socket, lo analiza con el LLHTP, y luego lo escribe en la transmisión legible, y luego lo lees de la transmisión legible para usarlo. Y esto tiene este sobrecarga de rendimiento innecesaria del pegamento. Puedes evitar eso usando la API de transmisión, que básicamente te permite devolver una transmisión escribible donde se debe escribir la respuesta, en lugar de esta transmisión de pegamento intermedia. Como habrás notado antes, hay un cierre
5. API de Undici y Despachadores
Ofrecemos 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, la piscina undici, la piscina equilibrada, el agente undici y el agente proxy. Todos estos métodos utilizan el despachador global por defecto, pero puedes pasar un despachador en las opciones para usar uno diferente.
siempre se crea aquí. Por lo tanto, ofrecemos una opción para enviar una propiedad OPAC, que se proporcionará en el callback. 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 es para, ya sabes, crear fácilmente los pipelines de transformación que son solicitudes HTTP. Entonces, publicas data en una solicitud HTTP y luego obtienes un cuerpo de data de vuelta. Y luego puedes usarlo con pipelines de transmisión, por ejemplo. En realidad no necesitas esto. Puedes lograr lo mismo con, ya sabes, solicitudes undici y un generador. Es un poco más de code, pero esto es igual de bueno. Esta es también una de las razones por las que estamos desarrollando undici fuera del núcleo es 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 cerebro. No entraré en detalles allí. Pero proporcionamos algunos tipos diferentes de despachadores que son utilizables. Entonces, primero, tenemos el cliente undici que es el más básico. Te proporciona una única conexión al servidor y ofrece soporte para keep alive y también te permite seguir las respuestas de redirección. Luego tenemos la piscina undici que crea múltiples 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 una piscina equilibrada mientras que la anterior piscina siempre se conectará al mismo servidor. Así que tendrá múltiples conexiones al mismo servidor. La piscina equilibrada te permite conectarte a diferentes servidores y tener solicitudes equilibradas sobre esos y eso también utiliza una programación de paso primero. El agente undici se construye sobre la piscina y te permite tener múltiples orígenes diferentes y también seguirá las directrices de origen cruzado. También tenemos un agente proxy que te permite hacer proxy a través de servidores. No entraré en detalles allí. Y todos estos métodos han sido mostrándote la solicitud undici. Utilizan algo que llamamos el despachador global que es por defecto y puedes cambiarlo tú mismo. Y entonces todas las llamadas que no establecen explícitamente un despachador lo utilizarán. Pero también puedes pasar un despachador en todas estas APIs en las opciones y entonces
6. Personalización e Indichi en Core
Admitimos seguir redirecciones y permitimos la personalización de las conexiones al 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. Las contribuciones a la implementación de fetch son bienvenidas. Hay algunas diferencias con el Web Bear, particularmente en la recolección de basura en Node.js.
ese despachador será utilizado. Como mencioné antes, admitimos seguir redirecciones y tú simplemente pasas las redirecciones máximas, es decir, cuántas redirecciones permites y Unleash se encargará de eso. También podemos personalizar cómo nos conectamos a los servidores. Así que puedes proporcionar a algunos de los despachadores un método de conexión, que como puedes ver, toma algunos parámetros y luego puedes tener tu propia implementación de socket personalizado o cosas de búsqueda de DNS personalizadas. Así que, por ejemplo, si tienes una implementación rápida, podrías ejecutar HTTP sobre rápido aquí simplemente proporcionando un objeto que parece un socket, pero va sobre rápido. Algunos de los despachadores tienen esto métodos de fábrica. Así que, por ejemplo, pool o agente, puedes, estos usan despachadores internamente, por lo que tienen su propia lógica y luego despachan a un subdespachador y luego tú puedes cambiar cómo sería eso. Así que en el caso del agente, ya sabes, la fábrica por defecto comprueba si, ¿cuántas conexiones has pasado? Si es una, entonces utiliza un cliente porque eso tiene menos sobrecarga porque no tienes que gestionar conexiones. De lo contrario, utiliza una pool, pero aquí podrías usar tu 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 lo que deberíamos incluirlo o no. Tiene, sí, yo diría que simplemente mira el problema y lee a través. 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 más pensadas, podría ser el momento de incluirlo en el núcleo. Ahora también hemos dedicado mucho trabajo a implementar fetch basado en Indichi, y en realidad estamos aterrizando soporte experimental en note 17. Así que está bajo la bandera experimental fetch. Así que ahora estamos llegando cerca de finalmente tener un fetch en el núcleo. Si ustedes quieren ayudar a hacer que no sea experimental, entonces por favor diríjanse al repositorio de Indichi y ayúdennos a mejorar la prueba Y siempre hay casos límite de cumplimiento de especificaciones que pueden ser encontrados y resueltos. Es bastante fácil contribuir a la implementación de fetch en Ditche. Estamos usando una forma muy literal de implementar la especificación en Indichi. Así que básicamente tomamos la especificación e intentamos seguir lo más de cerca posible los pasos de la especificación de manera tan literal como sea posible. Así que si quieres ayudar, simplemente lee la especificación. Hay algunas tareas pendientes aquí que puedes ver si puedes resolver. Pero es razonablemente fácil contribuir. Tenemos algunas diferencias con el Web Bear y principalmente cómo funciona la recolección de basura. En el navegador fetch se recolectará automáticamente la basura 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 Usabilidad y Trabajo Futuro
Actualmente nos estamos enfocando en la usabilidad y el cumplimiento, con mejoras de rendimiento en el pipeline. El trabajo futuro incluye soporte para HTTP 2 y 3, búsqueda de DNS para balance pool y soporte de pool, y mejoras en la programación de fetch y pool. También pretendemos abordar la falta de soporte para las solicitudes HTTP 100 continue en la especificación HTTP 1. Gracias por su atención.
en Node.js funciona un poco diferente. Entonces, no podemos hacer eso. Todavía nos falta archivo. Implementando archivo desde el núcleo para hacer cumplimiento total de la especificación. Y ahora mismo, nos estamos enfocando en la usabilidad, haciéndolo fácil de mantener y contribuir y cumplimiento. Performance no es la prioridad en este momento. Pero, por supuesto, estamos buscando mejorar eso también. Pero personalmente recomendaría usar las otras APIs si performance es la parte importante. Creo que fetch es bueno para la usabilidad y la compatibilidad entre navegadores y Node.
Trabajo futuro. Por supuesto, nos encantaría soportar HTTP 2 y 3. Entonces, eso es algo en lo que estamos trabajando. Sería genial tener búsqueda de DNS para soporte para balance pool y el pool. Estamos buscando mejorar fetch. También, la programación de pool, la forma en que las solicitudes son despachadas y programadas sobre múltiples conexiones. Hay cosas interesantes que puedes hacer allí. ¿Debería ser una programación de profundidad primero, amplitud primero? ¿Deberíamos ponderar diferentes conexiones basadas en su latencia y cuántas veces la solicitud ha fallado en una conexión o upstream? Entonces, hay muchas cosas interesantes que hacer allí. Y todavía nos falta soporte para las solicitudes HTTP 100 continue en la especificación HTTP 1. Y eso es todo lo que tengo. Si tienes 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 lo aterrizamos como experimental en Node.js. Así que supongo que ese movimiento fue bueno dado este resultado. Y personalmente, estoy más orientado a performance. Así que uso una solicitud que es la menos común aquí en la votación, lo cual también es bastante sorprendente. Entonces sí, eso es una buena pista de dónde poner más energía.
Implementación de Node Fetch y Preguntas y Respuestas
El Fetch en Node se construye sobre undici, no sobre el código HTTP de Node normal. Nock no funciona con undici, pero undici tiene su propia implementación de simulación. NodeCore actualmente no soporta Qwik, pero hay planes para añadir soporte en undici. Los benchmarks muestran que reutilizar las 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 incluso más. Una cosa, así que hablaste sobre la implementación de Fetch en Node. Y también estoy bastante emocionado por eso. Espero que todos lo estén. ¿Utiliza undici? ¿Tiene algo en común?
Sí. Así que en realidad, el Fetch en Node se construye sobre undici. No exponemos nada de undici aparte de Fetch en Node, y esa es una decisión consciente para no exponer dos APIs experimentales que pueden cambiar y romperse más tarde. Pero la implementación de Fetch se hace sobre undici, y no sobre el código HTTP de Node normal.
Eso es genial. Supongo que todos los que ejecutan Node estarían esencialmente en undici ahora. Así que esa es la mejor manera de... Oh, tenemos una pregunta de nuestro orador, Joda Developer, quien preguntó, ¿cómo simular una solicitud en undici? Así que por ejemplo, hay una biblioteca Nock que te permite simular solicitudes. Así que si estás usando solicitudes de undici, ¿has intentado simularlo? ¿Y cómo lo harías?
Así que Nock no funciona porque depende de los internos del cliente HTTP. Tenemos implementada la simulación en undici. Así que hay un cliente simulado y un pool simulado y las herramientas que se requieren para hacer básicamente lo mismo que harías con Nock. Así que todo está ahí.
Eso es genial. También agentil1990 pregunta, ¿cómo será el soporte para Qwik en el futuro? Sé que NodeCore soporta Qwik ahora, ¿verdad? ¿Pero qué pasa con undicis?
Así que NodeCore aún no soporta Qwik. Creo que se lanzó como experimental, pero luego fue eliminado. Hay un PR en el que James está trabajando para lanzarlo. A menos que me haya perdido algo, pero una vez que se haya lanzado, debería ser bastante fácil añadir soporte para eso en undici para implementar HTTP1 sobre Qwik. Implementar el soporte para HTTP3 es un poco más de trabajo. Eso suena realmente interesante. Gracias. Otra pregunta es, ¿hay algún benchmark sobre el sobrecosto de crear una nueva conexión cada vez en comparación con el enfoque de undici?
Así que tenemos algunos benchmarks incluidos. Y sí, es difícil decir de dónde vienen todas nuestras mejoras de performance. Y de nuevo, depende de tu caso de uso. Pero diría que es significativamente más rápido mantener y reutilizar las conexiones que abrir y cerrarlas todo el tiempo,
Diferencias en TCP y el Futuro de HTTP en Node
¿Existen diferencias notables entre los sistemas operativos en términos de implementaciones de TCP? El plan actual es incluir Undici en Node Core, pero hay consideraciones respecto a la estabilidad, la superficie de la API y el futuro de HTTP en Node. La adición de APIs y estándares web a Node Core es un tema debatido, con argumentos a favor de soluciones a medida 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 APIs, pero ofrece conveniencia para una implementación rápida.
especialmente en términos de latencia. Entiendo. ¿Existen diferencias notables de un sistema operativo a otro? Como ¿las implementaciones de TCP realmente hacen una diferencia aquí? En términos de sobrecarga de CPU, sí, tal vez. Pero aún necesitas realizar las acciones requeridas por el protocolo de enlace TCP. Así que es más una cuestión de protocolo de red.
Bien. Bueno, la siguiente pregunta es, ¿cuál es el plan o progreso actual para incluir Undici en Node Core? Acabamos de hablar sobre fetch y cómo fetch se ejecuta sobre Undici. Recuerdo que en el pasado ha habido múltiples solicitudes para agregar cosas como los streams de OWG a Node. ¿Crees que este hito de fetch que hemos logrado podría abrir la puerta a un número de otras cosas? El enfoque principal ha sido implementar todos los web standards en Node.js porque están bien especificados y no se esperan tantos cambios disruptivos en el futuro. Una vez que tengamos y una vez que aterricemos Undici en Core, eso pone algunas restricciones en lo que podemos hacer en Undici y cuán rápido podemos hacer las cosas. Así que siempre hay un equilibrio entre tenerlo en Node Core y darle una marca de que no romperemos cosas o tenerlo fuera y mantener la velocidad de desarrollo en él. Creo que estamos llegando, acercándonos al punto donde Undici se siente estable en términos de la superficie de la API. Así que podría valer la pena incluirlo en Core. Pero me gustaría ver un plan más grande en términos de servidor y cliente sobre cómo queremos que se vea el futuro de HTTP en Node antes de empezar a incluir nuevas APIs.
Sí, eso es realmente interesante. Una cosa, entonces, mencionaste acerca de agregar más de estas APIs web y luego Web standards, por así decirlo, en Node Core. Ahora, esto es un tema muy debatido, ¿verdad? No todo el mundo está de acuerdo en que agregar cosas como Fetch a Node sea una buena idea. Una de las razones que solían apoyar eso es diciendo que Fetch y todo están diseñados 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 apila esto? Y por ejemplo, hay tantas cosas en Fetch que son específicas para los navegadores, como los frascos de cookies. ¿Cómo funciona eso en DG? Sí, quiero decir, siempre es un equilibrio entre hacer una solución a medida y una solución uniforme. Creo que muchas de las cosas con Fetch están mejorando la experiencia del desarrollador, facilitando la escritura de un buen código, ¿verdad? Porque la gente trabaja en el navegador, así que ellos necesitan conocer Fetch de todos modos. Y conocen los detalles y los casos límite allí. Y luego tener que aprender una tercera, cuarta, quinta y sexta API, incluso si esas son mejores para casos de uso específicos, tiene algunas desventajas. Por ejemplo, Fetch, undici Fetch, tiene un rendimiento más bajo que las otras APIs que proporcionamos como undici Request. Pero aún así es una buena idea incluirlo porque ayuda con la familiaridad del desarrollador. Y las horas de trabajo del desarrollador son mucho más caras que comprar un hardware más rápido. Así que creo que eso es un poco, esa es mi opinión sobre todo el asunto. Si sólo quieres hacer las cosas rápidamente y que funcione, ve con undici Fetch. Si el rendimiento es tu máxima prioridad, entonces recomendaría algunas de las otras APIs que aún no se han incluido.
Implementación de Undici Fetch y planes futuros
Existen ciertos detalles de implementación en Fetch que solo tienen sentido en un contexto de navegador, como las cookies. En Undici, intentamos seguir literalmente la especificación, 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. Undici ha inspirado correcciones en los streams de Node Core. Los planes futuros para Undici incluyen soporte para Quick, HTTP 2 y HTTP 3. Se espera la clase File de la especificación web para la implementación completa de Fetch.
Sí, eso suena realmente genial. Gracias. Creo que hice la pregunta demasiado larga pero intenté insistir en una segunda parte. La suite de pies, hay 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 Undiji? Buena pregunta, y eso es algo que tenemos que manejar caso por caso. De hecho tenemos algunas, la forma en que implementamos Fetch en Undiji es que intentamos seguir literalmente la especificación. Así que realmente implementamos la 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 hacer que las cosas funcionen.
Por ejemplo, las redirecciones en Undiji Fetch funcionan un poco diferente que en el navegador. Hemos seguido la forma en que CloudFlare y Deno lo hacen. También hay problemas como la recolección de basura que pueden afectar cómo se comporta la implementación y si es importante consumir completamente todas las respuestas o no. En Undiji Fetch tienes que consumir respuestas mientras que en el navegador. Es un poco más agradable. Se limpiará durante la recolección de basura.
Sí, gracias. Eso fue realmente revelador. Tenemos otra pregunta de los espectadores que dice, ¿Es Undiji tu principal motivación para las muchas correcciones que has hecho a los streams de Node.Force? O en otras palabras, ¿fue la complejidad de los streams un obstáculo para el desarrollo de Undiji? Supongo que lo fue pero ni siquiera me di cuenta en ese momento. Así que he estado tratando de, pasé mucho tiempo trabajando en streams HTTP y el cliente y servidor HTTP en Node. Y mucho del trabajo fue para hacer que los streams funcionaran de una buena manera. Di una charla en no TLV sobre este problema con los streams y una vez que llegué tan lejos como pude con los streams y me encontré con el obstáculo con las cosas de HTTP, es cuando me fui a Undiji. Y sí, hay algunas correcciones en los streams inspiradas por problemas que encontré en Undiji. Sí, eso es bastante interesante. Recuerdo que este tema de reformar los streams de notas ha sido un tema tan largo y la gente ha pensado en esto durante tanto tiempo. Me alegra que estés avanzando en esto. Otra pregunta que tenía para ti. Entonces, ya tienes un montón de interesantes características, por así decirlo, en Undici. ¿Hay algún otro estándar web o característica web que esté en tu radar? ¿Hay algo que planeas hacer a continuación? Un poco de lo que hablamos, hay Quick y HTTP 2 y HTTP 3, y eso es lo que estamos buscando 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 asombroso. Muchas gracias Robert, y esta fue una increíble presentación, y fue bastante informativa, al menos para mí, y espero que lo mismo se aplique a todos nuestros espectadores. Si no has terminado de hacer todas estas preguntas a Robert, es posible que quieras unirte a él en la sala de conferencias, así que hay un enlace a la sala de conferencias. Únete a él en Spatial Chat. Muchas gracias Robert. Gracias.
Comments