Haciendo que mi API de Node.js sea súper rápida

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Los servidores de Node.js necesitan procesar un gran número de solicitudes de manera concurrente a medida que la escala crece. Un microservicio de Node.js que recibe una solicitud de API necesita realizar múltiples acciones, como analizar JWT, usar caché, trabajar con bases de datos y más. En esta charla, Tamar mostrará estrategias para mejorar el rendimiento de su API REST, comenzando desde nuevos frameworks de Node.js que pueden funcionar más rápido, un mejor análisis de las partes de la solicitud, un trabajo eficiente con caché y bases de datos, una mejor paralelización y más estrategias. La charla incluirá demos, benchmarks y perfiles de código para ver las mejoras. Al final de esta charla, los desarrolladores tendrán conocimientos prácticos sobre cómo mejorar el rendimiento de la API en varias plataformas de Node.js.

This talk has been presented at Node Congress 2024, check out the latest edition of this JavaScript Conference.

Tamar Twena-Stern
Tamar Twena-Stern
34 min
04 Apr, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta charla se centra en mejorar el rendimiento en el desarrollo de API de Node.js. Cubre diversas áreas como la optimización del trabajo con bases de datos, el grupo de conexiones, el análisis de JSON, el registro y la selección del framework web. Los aspectos destacados incluyen el uso de Native Mongo Driver para un mejor rendimiento de la base de datos, la optimización del grupo de conexiones para una mayor capacidad de procesamiento, la sustitución del serializador Express para una serialización y deserialización más rápida, y la elección de Festify como un framework web eficiente. Se discute el impacto del almacenamiento en caché y la autenticación en el rendimiento, junto con recomendaciones para los tipos de caché. La charla también enfatiza la consideración de los factores ambientales y el impacto humano en el rendimiento. Fastify se destaca como una herramienta recomendada para la optimización del rendimiento de Node.js.
Available in English: Making My Node.js API Super Fast

1. Introducción a la Optimización del Rendimiento

Short description:

Hola a todos, bienvenidos a mi sesión sobre cómo mejorar el rendimiento en su API de Node.js. Soy un apasionado de JavaScript y Node.js. Hoy discutiremos cómo mejorar el rendimiento en la capa de su API, cubriendo áreas como la base de datos, la serialización, la deserialización, el registro, los marcos web y el almacenamiento en caché. Comencemos con el trabajo de la base de datos. Optimice las consultas a la base de datos, utilice índices eficientes, denormalice los datos y considere soluciones como réplicas de lectura-escritura y fragmentación.

Antes de comenzar a hablar sobre cosas técnicas, permítanme presentarme. Mi nombre es Tamar. Pueden seguirme en estos enlaces y contactarme en estos enlaces. Soy realmente apasionado de JavaScript y Node.js y mi interés en estas tecnologías comenzó cuando fundé mi propia startup y escribí todo el backend en Node.js y desde entonces, el resto es historia.

Y suficiente hablando de mí, comencemos a hablar sobre el rendimiento, que es una de mis cosas favoritas de las que me gusta hablar. Y hoy vamos a hablar sobre cómo mejorar el rendimiento en la capa de su API. Vamos a revisar, vamos a analizar esas áreas, vamos a analizar la base de datos. Vamos a analizar la serialización y deserialización de sus JSON. Vamos a hablar sobre el registro. Puede parecer trivial, pero eso puede afectar su rendimiento. El marco web que elijas y el almacenamiento en caché.

Comencemos con el trabajo de la base de datos. En primer lugar, antes de adentrarnos en cosas relacionadas con JavaScript, hay algunas cosas que debes tener en cuenta para cualquier tecnología con la que trabajes, para cualquier lenguaje de programación. En primer lugar, por supuesto, tus consultas a la base de datos deben estar optimizadas. Todos los índices deben ser muy eficientes y permitir una recuperación y operaciones eficientes muy rápidas. Y luego debes denormalizar tus datos. ¿Qué significa esto? Si tienes una tabla con 50 columnas y solo necesitas tres, no recuperes las 50 completas. Recupera solo lo que necesitas, por ejemplo. Y guarda los datos de manera eficiente. No guardes cosas ineficientes. Y luego debes pensar en soluciones en la capa de la base de datos. Pueden ser réplicas de lectura-escritura que pueden mejorar tu rendimiento. Trabajar con un conjunto de réplicas, emparejar las bases de datos que lo admitan y fragmentación.

2. Mejorando el Trabajo de la Base de Datos en Aplicaciones Node.js

Short description:

Discutamos cómo mejorar el trabajo de la base de datos relacionado con las aplicaciones Node.js, comparando Mongoose y Native Mongo Driver. Las principales medidas para la evaluación del rendimiento incluyen la latencia (analizando el percentil 99) y el rendimiento (promedio de solicitudes por segundo y solicitudes totales). En la evaluación, tanto Mongoose como Native Mongo Driver se utilizaron para enviar un objeto persona a la base de datos. Los resultados mostraron que Native Mongo Driver tuvo un rendimiento significativamente mejor que Mongoose, con un aumento en el promedio de solicitudes por segundo y un percentil 99 mucho más pequeño.

Pero estamos en una conferencia de Node.js, y después de hablar un poco sobre consejos genéricos, vamos a adentrarnos en cosas de Node.js. ¿Cómo puedo mejorar el trabajo de la base de datos en mi aplicación Node.js? Cuando comenzamos a trabajar con Node.js, comenzamos con el primer tutorial que todos hacemos: Node.js, Express y Mongoose. Empecemos con eso y hagamos una evaluación para ver cómo funciona. Al hacer una evaluación, debemos tener en cuenta las siguientes cosas. En primer lugar, las medidas más importantes son la latencia. Debes analizar el percentil 99, no el promedio. Porque cuando tienes un contrato con un tercero y les dices que todas mis solicitudes son más rápidas que esto, debes proporcionarles el percentil 99 de la latencia, no la mediana ni el promedio. Eso es realmente importante. En segundo lugar, medir el rendimiento. Para medir el rendimiento, hay dos cosas importantes que debemos tener en cuenta. Primero, el promedio de solicitudes por segundo, y luego las solicitudes totales. Estas medidas te darán una buena idea de cómo está mejorando tu rendimiento.

Ahora vamos a comparar Mongoose y Native Mongo Driver. Escribí un servidor que funciona con Mongoose, y ese servidor expone una solicitud POST que envía un objeto persona, algo muy simple. El código no es algo realmente interesante. Estamos construyendo un servidor con Express y Mongoose, creando un esquema de Mongoose con varios parámetros, y luego esa es la función que vamos a evaluar. POST, y luego creamos un nuevo objeto persona y lo guardamos, como puedes ver aquí. El código de Native Mongo Driver va a hacer exactamente lo mismo. Una solicitud POST, que también envía un objeto persona, porque queremos comparar manzanas con manzanas. Cuando hacemos una evaluación de rendimiento, queremos comparar cosas que hacen lo mismo. Aquí está el código que se ejecuta con Native Mongo Driver. Como puedes ver, esto también hace una inserción en la base de datos.

Genial. Estos son los resultados que obtuvimos con Mongoose. Puedes ver que si observamos las solicitudes promedio por segundo, estamos alrededor de 5700 solicitudes, y las solicitudes totales son alrededor de 64,000, y el percentil 99 es de 4 milisegundos, pero al usar Mongo Driver, podemos ver que las cosas mejoraron enormemente. Podemos ver que las solicitudes promedio por segundo aumentaron a 9500, lo cual es mucho. Es más del 30%, creo. El percentil 99 es mucho más pequeño, un 50% menos, y pudimos atender, en el tiempo de la evaluación, alrededor de un 30,000% más de solicitudes. Como puedes ver, si lo vemos en un gráfico, Native Mongo Driver tiene un rendimiento mucho mejor que Mongoose.

3. Optimizando la Pool de Conexiones

Short description:

Comparamos las solicitudes totales y las solicitudes promedio por segundo para ver mejoras significativas en el rendimiento. Los ORMs como Mongoose proporcionan una capa de abstracción sobre la base de datos, pero pueden afectar el rendimiento debido a la sobrecarga y consultas ineficientes. Al escalar, es mejor trabajar directamente con la base de datos. Las pool de conexiones son un grupo de conexiones de base de datos disponibles que pueden ejecutar consultas y mejorar el rendimiento. Al optimizar la pool de conexiones, logramos una mejora del 15 al 20 por ciento en las solicitudes promedio y totales, junto con una latencia más corta.

Vamos a comparar las solicitudes totales y las solicitudes promedio por segundo, y verás que es mucho mejor. La pregunta es, ¿por qué es mucho mejor? ¿Por qué tiene un rendimiento mucho, mucho mejor? En resumen, Mongoose es una herramienta de un tipo llamado ORMs, y generalmente cuando usas esas herramientas, están mucho más allá, te brindan una capa de abstracción sobre tu base de datos que te ayuda, pero agrega una sobrecarga de serialización, desreferenciación, a veces consultas ineficientes, por lo que generalmente la mayoría de los ORMs perjudican tu rendimiento. Son buenos para aplicaciones de baja escala, mediana escala, pero cuando vas a alta escala, generalmente comienzas a trabajar nativamente con tu base de datos, ya sea Mongo, SQL u otro. Ahora hablemos un poco sobre las pool de conexiones. ¿Qué son las pool de conexiones?

Cuando trabajamos con una base de datos, queremos tener un grupo de conexiones a la base de datos que estén disponibles, cada una de ellas puede ejecutar una consulta y, cuando termina, vuelve al grupo esperando a otro cliente, otra utilidad para usarla. Si comparamos los resultados cuando trabajamos con una pool de conexiones a nuestra base de datos y trabajamos sin una pool de conexiones, hagamos esa comparación nuevamente, estamos comparando manzanas con manzanas y estamos comparando el mismo servidor, y ese servidor está realizando esa solicitud POST del que hablamos. Entonces, cuando no tenemos una pool de conexiones, veamos el rendimiento. Vemos que las solicitudes promedio por segundo son alrededor de 8100 y las solicitudes totales son aproximadamente 81,000, wow, tenemos un factor de multiplicación de 10 aquí, y luego puedes ver que si optimizamos nuestra pool de conexiones, haciéndola más grande, más eficiente para nuestras necesidades de máquina, para nuestro entorno, entonces logré obtener alrededor de un 15 a un 20 por ciento de mejora. Puedes ver que las solicitudes promedio aumentaron a 9500, la cantidad total de solicitudes está un poco cerca de las 100,000 solicitudes, y si lo vemos con gráficos, entonces podemos ver que cuando optimizamos nuestra pool de conexiones, el rendimiento aumentó un 20 por ciento. Así que estamos viendo las solicitudes totales, las solicitudes promedio y también la latencia se redujo. Otra cosa importante a tener en cuenta es trabajar con una pool de conexiones y asegurarse de optimizarla.

4. Efficiente Análisis JSON y Stringify

Short description:

Cuando trabajamos con solicitudes HTTP, la serialización y deserialización pueden ser operaciones síncronas que bloquean el bucle de eventos. Al reemplazar el serializador predeterminado de Express con FastJSONStringify, logramos una mejora del 15% en el rendimiento del servidor Express. La cantidad promedio de solicitudes aumentó a más de 10,000 por segundo y las solicitudes totales mejoraron en aproximadamente un 50%. FastJSONStringify proporcionó una ventaja en el rendimiento, pero existen otras bibliotecas disponibles para considerar una serialización y deserialización eficientes.

Muy bien, ahora hablemos sobre el análisis eficiente de JSON y el stringify. Entonces, cuando trabajamos con una solicitud HTTP, cuando estamos utilizando una solicitud POST, cuando estamos implementando una solicitud POST, estamos deserializando la solicitud HTTP, el cuerpo de la solicitud, y cuando estamos implementando una solicitud GET, estamos serializando el cuerpo de la respuesta y devolviéndolo al servidor. Pero la serialización y deserialización son operaciones síncronas que siempre bloquean el bucle de eventos. Espero que tengas en mente la arquitectura de Node.js, que estés familiarizado con el bucle de eventos que procesa actividades y trabajo, y cuando tenemos una operación síncrona que es larga, la bloquea. Y la serialización y deserialización son exactamente esas cosas.

Ahora voy a tomar el mismo servidor y reemplazar la serialización de la respuesta con otra biblioteca llamada FastJSONStringify y veamos qué obtenemos aquí. Si vamos a trabajar, estoy implementando una API GET aquí, y estoy trabajando con Express y estoy usando Express.json, como puedes ver, el serializador predeterminado, y esa es una función que estoy probando. Y Express.json se ejecuta cuando hacemos result.json. OK, estamos haciendo find one y devolviendo la respuesta. Ahora agregué un poco de mi propia adición. Creé otro servidor. Usé FastJSONStringify. Esa biblioteca necesita recibir un esquema, así que le di un esquema, como puedes ver aquí, y creé un middleware propio. Reemplacé el serializador predeterminado de Express con mi middleware personalizado, y ese middleware utiliza FastJSONStringify, ese middleware personalizado. Y si comparamos esos resultados, veremos que eso también me dio alrededor de un 15% de mejora en mi servidor Express. Por ejemplo, la cantidad promedio de solicitudes aumentó a más de 10,000 por segundo y también las solicitudes totales, esas aumentaron en aproximadamente un 50%. Pude atender un 50% más de solicitudes, por lo que el rendimiento aumentó y también la latencia es menor. FastJSONStringify me dio la ventaja en el rendimiento aquí. Pero sabes, esa no es la única biblioteca que existe. Hay más bibliotecas que existen y realmente te recomiendo buscar otros serializadores, comprender qué es más eficiente al realizar tus pruebas y tal vez considerar hacer esta capa de serialización y deserialización de tu contenido de solicitud y respuesta más eficiente.

5. Logging and Performance

Short description:

El registro es esencial para la depuración y solución de problemas en aplicaciones. Sin embargo, el registro puede causar degradación del rendimiento. Al comparar servidores con y sin registros, observamos una disminución del 15% en el rendimiento. PinoJS es actualmente la biblioteca de registro más eficiente, proporcionando el menor sobrecosto y un mejor rendimiento general. Al registrar, es importante permitir que la biblioteca de registro maneje la concatenación de cadenas para evitar problemas de rendimiento en aplicaciones grandes y complejas. Considere el uso de PinoJS en lugar de otras bibliotecas de registro para obtener un mejor rendimiento. Además, vale la pena explorar alternativas a Express, ya que es un marco más antiguo (la versión 4 se lanzó en 2014).

Muy bien, hablemos un poco sobre el registro. En un mundo perfecto, nuestro sistema funciona perfectamente, pero en realidad, generalmente hay muchos problemas, las aplicaciones se bloquean, hay errores aleatorios, data falta, por lo que el registro siempre nos ayuda a debug, y el registro es algo que todos necesitamos en nuestras aplicaciones. Pero el registro puede causar una degradación del rendimiento.

Así que estaba, o lo siento, no puede, siempre causará una degradación del rendimiento. Así que estaba comparando un servidor con una solicitud POST que es, ya sabes, sin registros, y otro servidor que solo tiene una línea de registro, y eso es todo. Y mira lo que tenemos aquí. Si sin registro, la cantidad promedio de solicitudes por segundo es de alrededor de 9600, entonces cuando tenemos solo una línea de registro, el rendimiento disminuye alrededor del 15%. Mira aquí. La cantidad promedio de solicitudes por segundo es de alrededor de 8400. En los últimos resultados, pudimos atender alrededor de 100,000 solicitudes en el total de referencia. Ahora podemos atender alrededor de 93,000. Eso es como un 10% de degradación.

Entonces, cuando pienses en el registro, eso también es algo que debes tener en cuenta para elegir una biblioteca que sea eficiente en cuanto al rendimiento. Diferentes bibliotecas de registro que son populares en este momento son, digamos, Winstone, PinoJS y otras bibliotecas que tomé para comparar en mi referencia son Banyan y Log4j. Entonces, cuando miramos el panorama general, veremos que PinoJS es la biblioteca que actualmente te brinda el menor sobrecosto en tu código, lo que significa que eso es, por ahora, para mis comparaciones, la biblioteca de registro más eficiente en cuanto al rendimiento, y te daría los mejores resultados sin perjudicar el rendimiento de tu aplicación. Entonces podemos ver eso en la cantidad promedio de solicitudes por segundo, y también podemos verlo en el total de solicitudes, ya que puedes ver que Pino, el servidor con Pino pudo atender la cantidad de solicitudes que está más cerca de un servidor sin registros. Entonces, si concluimos eso, si estás pensando en el rendimiento y estás pensando en la eficiencia del rendimiento, elige PinoJS en lugar de otras bibliotecas. Eso puede cambiar, pero por ahora, es la biblioteca de registro más eficiente que existe. Otro consejo que me gustaría darte, que es importante, es, ya sabes, cuando hacemos registros, tenemos muchas concatenaciones de cadenas, pero la biblioteca de registro debe manejar esta concatenación de cadenas. No hagas la concatenación de cadenas en tu aplicación tú mismo. Como puedes ver en el ejemplo que está abajo, porque parece insignificante para ti. Lo que realmente está sucediendo detrás de escena es que si mi nivel de registro por ahora es como error, entonces esa concatenación de cadenas no se realizará por la biblioteca de registro. Si lo hago yo mismo, siempre sucederá. Entonces parece insignificante, pero realmente en aplicaciones grandes, aplicaciones complejas, esas cosas se suman. Siempre prefiere que la construcción de cadenas se realice con una interfaz adecuada para eso desde la biblioteca de registro, que recibe parámetros. Bueno, ahora en realidad estaba haciendo toneladas de ejemplos con Express. Entonces la pregunta es si podemos hacer algo más, tal vez no Express. Quiero decir, Express, para ser honesto, es un poco antiguo. No sé si lo sabes, pero la versión de lanzamiento de Express es la versión 4, y eso fue lanzado en 2014. Eso fue hace bastante tiempo.

6. Comparando Frameworks Web

Short description:

Al comparar diferentes frameworks web como Express, NestJS y Festify, Festify superó a los demás con casi el doble de solicitudes por segundo y menor latencia. Elegir un framework web más eficiente puede proporcionar un impulso significativo en el rendimiento y la ventaja, especialmente al comenzar un nuevo microservicio. Festify actualmente tiene el mejor rendimiento entre todos los frameworks analizados.

Sé que el primer tutorial es sobre Express, pero tenemos muchos otros jugadores interesantes en el mercado. Tenemos Nest, tenemos Festify, tenemos Koa. Entonces, tal vez si vamos a elegir algo más, eso puede darnos una ventaja que necesitamos.

Así que estuve comparando Express, Festify y NestJS, y por supuesto, al hacer comparaciones, es muy importante, como dijimos, comparar manzanas con manzanas. Si estoy comparando una solicitud GET que guarda un objeto, un objeto de persona con tres parámetros, tengo que hacer lo mismo con Festify y con Nest, el code tiene que ser el mismo. Y en la base de datos, si estamos haciendo una inserción, necesitamos hacer una inserción en el otro framework. Bien, veamos qué obtenemos. Así que cuando trabajamos con Express, pudimos atender alrededor de 95, 94 cientos de solicitudes por segundo, y el rendimiento es de alrededor de 100,000 solicitudes por segundo. La latencia es de dos milisegundos. Nest nos dio algo más lento. El promedio de solicitudes por segundo es de 5,400. Pudimos atender alrededor de 60,000 solicitudes, pero Festify actualmente nos dio los mejores resultados. Pudimos atender, como puedes ver, cerca de 200,000 solicitudes por segundo. La latencia se redujo a un milisegundo. Así que Festify nos dio la ventaja de performance, y aquí está la comparación. Si lo vemos visualmente, entonces veremos que Nest estaba funcionando alrededor de un 50% más lento que Express, pero Festify actualmente es aproximadamente el doble de rápido que Express, al menos según mis comparaciones. Podemos ver eso con múltiples mediciones que se realizaron. En realidad, en la mayoría de las empresas, es un poco difícil, digamos, refactorizar tu microservicio code. Por lo general, obtienes un code en el que necesitas trabajar, y en ese caso, bueno, tienes qué hacer. Puedes hacer que tu DB funcione de manera más eficiente. Puedes usar caché. Hablaremos sobre la caché de inmediato. Puedes mejorar la serialización, pero si tienes la posibilidad de elegir un framework web más eficiente, o si tienes la posibilidad de comenzar un nuevo microservicio con un framework web diferente en tu organización, realmente deberías considerarlo, porque eso puede darte un impulso y una ventaja reales. Y, como dijimos, Festify actualmente es el framework que tiene el mejor rendimiento entre todos los frameworks que he analizado.

7. Caching and Authentication Performance

Short description:

Agregar autenticación JWT al servidor causó una disminución significativa en el rendimiento. Al implementar el almacenamiento en caché, pudimos recuperar el rendimiento cercano al estado inicial sin autenticación.

Ahora, espero que no te sorprendas, pero vamos a hablar de la última cosa, que es el almacenamiento en caché. Para eso, había implementado un servidor que está autenticado con JWT, y la validación del token se realiza en la autenticación JWT en ambos lados. El cliente debe validar el token y el servidor también debe validar el token. Pero te daré un adelanto. Agregar autenticación JWT al servidor ha causado una disminución del rendimiento de una manera realmente mala. Veamos eso. Entonces, este es el middleware que agregué y para cada solicitud que hago, verifico el JWT del token. Bueno, el código no es realmente complicado aquí.

Este es el middleware que se utiliza. Y mira lo que sucedió. Así que, de una situación en la que estábamos atendiendo alrededor de 100,000 solicitudes en total, pasamos a alrededor de 15,000. Eso es como un 80% de degradación. Eso es enorme. Entonces, sí, las cosas y también la latencia, ya sabes, aumentaron a alrededor de 10 milisegundos. Fue masivo. Para resolver el problema, bueno, lo mejor que se puede hacer aquí para solucionar el problema es utilizar el almacenamiento en caché.

Estos son los resultados cuando no tenemos authentication. Eso es lo que obtuvimos. Sabemos que alrededor de 9,500, 9,600. Esos son los resultados que obtuvimos cuando agregamos la authentication. Verás que el promedio de solicitudes por segundo bajó a 2,500. Y cuando usamos el almacenamiento en caché, puedes ver que estamos muy cerca de lo que teníamos al principio. Sin la authentication, teníamos alrededor de 95 solicitudes, 9,500 solicitudes por segundo. Aquí tenemos 9,100. Eso es bastante cercano. Y también podemos ver que la latencia vuelve a ser de 2 milisegundos, el percentil 99. Eso es lo que estamos observando todo el tiempo. Y aquí puedes verlo visualmente. Cuando agregamos el almacenamiento en caché, está cerca de lo que tenemos cuando no hay authentication en absoluto. Entonces, agregar almacenamiento en caché a la capa de authentication resolvió el problema.

8. Tipos de Caché y Recomendaciones

Short description:

La caché es una solución efectiva para resolver los cuellos de botella de rendimiento. No se recomienda la caché en memoria para ejecutar servicios en múltiples réplicas. Es mejor utilizar tecnologías como Redis o EDCD para la caché distribuida. Los elementos recomendados para cachear incluyen consultas a la base de datos, elementos de criptografía y solicitudes HTTP de terceros. En resumen, optimiza las consultas a la base de datos, utiliza una arquitectura eficiente de base de datos, trabaja con controladores nativos de base de datos y optimiza tu grupo de conexiones. Cachéalo cuando sea necesario.

Podemos verlo con diferentes mediciones. Y podemos ver que la latencia ha vuelto a ser la misma. Ese era el cuello de botella y se resolvió el problema de rendimiento.

Tipos de caché que podemos hacer. Podemos hacer caché en memoria, pero en realidad no se recomienda. Porque la mayoría de las veces, si estás haciendo caché en memoria, no puedes ejecutar tu servicio en múltiples réplicas. No puedes crear múltiples instancias de tu servicio. Así que no se recomienda. Es mejor utilizar tecnologías como Redis. Redis tiene otros competidores como EDCD, por ejemplo. Pero es mejor utilizar tecnologías como estas. Y en ese caso, la caché es distribuida. Todos tus servicios están accediendo a la caché. Y es mucho mejor. Bien, lo que debes cachear. O qué se recomienda cachear. Consultas a la DB, elementos de criptografía. Por ejemplo, vimos JWT. Solicitudes HTTP de terceros. Esos tipos de cosas. Eso mejorará mucho tu rendimiento. Bien. Estamos al final de esto. Lo cual es bueno. Así que hagamos un resumen rápido de todo lo que hemos visto. Optimiza las consultas a la DB. Asegúrate de tener una arquitectura eficiente de la DB como hemos hablado. Es mejor trabajar con controladores nativos de la DB en escalas grandes. Ten la capacidad de optimizar tu grupo de conexiones. Cachéalo cuando lo necesites.

QnA

Optimización de rendimiento y preguntas del público

Short description:

Elige un marco web eficiente, bibliotecas de registro y un serializador. Examina áreas como la latencia, el tiempo de solicitud, el rendimiento y la optimización de consultas para mejorar el rendimiento del servicio. Los factores ambientales también pueden afectar el rendimiento. Optimiza las consultas a la base de datos, el grupo de conexiones y el nivel de registro. Considera otros factores antes de optimizar el código JavaScript. Pasemos a las preguntas del público.

Y también asegúrate de elegir un marco web eficiente para el rendimiento. Debes elegir bibliotecas de registro eficientes. Y elige un serializador eficiente. Eso fui yo. Espero que lo hayas disfrutado. Y puedes seguirme en esos enlaces. Y muchas gracias.

¿En qué áreas deberíamos mejorar el rendimiento en nuestros servicios? Y aunque Columbia es una gran respuesta. Mucha gente lo está. Definitivamente. Pero la gente ha mencionado cosas como la latencia, el tiempo de solicitud, el rendimiento, la optimización de consultas. Entonces, ¿qué piensas? ¿Estos resultados te sorprenden? ¿Qué responderías a una pregunta así? ¿Qué respondería yo? Bueno. Primero que nada, podría ser que el problema no esté en tu aplicación. Tal vez sea un problema ambiental. Tal vez si la máquina se está ejecutando en la nube, haya problemas con otro contenedor. Que esté cortando los recursos de la máquina. Así que asegúrate de no estar en esa situación. Por cierto, creo que optimizar tu código es algo que haces un poco menos. Primero debes revisar tu base de datos. Y ver si necesitas optimizar tus consultas. Y también debes ver si tu grupo de conexiones está optimizado. Y también debes ver el nivel de registro. Por cierto, nunca ejecutes aplicaciones de producción en un nivel de registro en modo malo. Siempre ejecútalas en modo de error o advertencia, porque el registro puede afectar mucho a tu aplicación. Así que antes de comenzar a optimizar tu código JavaScript, hay muchas cosas que puedes hacer.

Fantástico. Esa es una gran respuesta. Pero también quiero pasar a las preguntas de las personas que sintonizaron y tienen preguntas para ti. Así que pasemos a esas preguntas. Y de hecho, creo que es una buena transición hacia lo que preguntó la primera persona.

Cuellos de botella de rendimiento y consejos para Node.js

Short description:

¿Cuál es el mayor cuello de botella de rendimiento: la tecnología o los humanos? Node.js tiene un mejor rendimiento debido a su modelo de E/S no bloqueante y bucle de eventos. Los humanos también afectan el rendimiento a través de problemas de arquitectura de software. Aísle los cuellos de botella de rendimiento en Node.js eligiendo nuevos marcos para un mejor rendimiento general. Trabaje con operaciones asíncronas y ejecute tareas en paralelo para aprovechar la potencia de los hilos de trabajo.

¿Cuál es el mayor cuello de botella de rendimiento? ¿La tecnología? ¿O los humanos en el proceso que implementan la tecnología? ¿Qué crees que es el mayor problema para el rendimiento? Bueno, la tecnología puede tener un impacto. Por ejemplo, creo que Node.js tiene un rendimiento mucho mejor que otros lenguajes como Java. Debido a su único modelo de E/S no bloqueante y bucle de eventos. Pero creo que como humanos, también debemos asegurarnos de dividir nuestro software en una buena arquitectura. Debemos tratar de dividir nuestro software y microservicios de manera que pueda escalar. Entonces, podría ser que los humanos sean capaces de... Los humanos son el mayor problema, en mi opinión. Los humanos son el mayor problema. Eso es. Como ha llegado a... Capa siete. Sí, como el trabajo de base de datos que no es correcto. El trabajo de registro que no es correcto. La arquitectura de microservicios que no está escalando. El caché que no se utiliza. Por eso necesitamos dar la bienvenida a nuestros señores de las máquinas. Ahora es el momento.

Genial, esa es una gran respuesta. Entonces, ¿qué recomiendas para aislar los cuellos de botella de rendimiento en aplicaciones de Node.js? ¿Cuál es tu mejor consejo? ¿Cuál es mi mejor consejo? Por cierto, recomiendo que si comienzas un nuevo proyecto, intentes buscar nuevos marcos. No vayas a usar, no sé, Express que todos están usando. Intenta usar nuevos marcos que te brinden esa ventaja de rendimiento. Y trata de trabajar con operaciones asíncronas, por cierto. Cuando se trata de Node.js, eso es crucial. Intenta trabajar con operaciones asíncronas. En todas partes donde tengas una API asíncrona, trabaja con ella. Trabaja con Promesas siempre que puedas. Siempre intenta ejecutar las cosas en paralelo. Porque, ya sabes, cuando trabajamos con async/await, nos gusta ejecutar las cosas una por una. Pero si puedes, ejecútalas en paralelo para aprovechar toda la potencia de los hilos de trabajo, como la potencia de los hilos de trabajo.

Optimizando el rendimiento en Node.js con Fastify

Short description:

Ejecuta tareas en paralelo para operaciones síncronas intensivas de CPU. Utiliza hilos de trabajo para la optimización específica de rendimiento de Node.js. Se recomienda Fastify por su eficiencia en la serialización, el registro y las operaciones de base de datos.

Así que haz eso. Ejecuta tareas en paralelo. Y si necesitas realizar operaciones síncronas intensivas de CPU, utiliza el modelo principal de hilos de trabajo para ejecutarlas en un grupo de hilos. Eso es como la optimización específica de Node.js para el rendimiento que es importante.

Entonces, eso, está bien. Mencionaste que Express es el predeterminado. Y tienes, esa también es la pregunta aquí, NestJS, Express. ¿Qué hay de Fastify, otras herramientas, qué recomendarías? ¿Cuál es otra opción no típica?

Creo que actualmente Fastify, te brinda todo el paquete. Funciona mucho más rápido que otros. Utiliza un serializador mucho más eficiente. En mi charla, la razón por la que mostré el serializador es para las personas que trabajan con Express y no pueden cambiar de tecnología. Así que eso podría ser una victoria rápida para ellos. Pero Fastify te brinda el serializador eficiente, el registro eficiente. Te brinda todo el paquete. Así que funciona eficientemente con una base de datos, no con Mongo. Así que creo que ahora es recomendado.

Increíble. Muchas gracias por esa increíble sesión de preguntas y respuestas y tu excelente charla y por unirte a nuestra comunidad. Fue maravilloso tenerte aquí. Muchas gracias, Tamar. Muchas gracias por recibirme.

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

Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Node Congress 2022Node Congress 2022
26 min
Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Top Content
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.
Cargadores ESM: Mejorando la carga de módulos en Node.js
JSNation 2023JSNation 2023
22 min
Cargadores ESM: Mejorando la carga de módulos en Node.js
Top Content
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.
Hacia una Biblioteca Estándar para Runtimes de JavaScript
Node Congress 2022Node Congress 2022
34 min
Hacia una Biblioteca Estándar para Runtimes de JavaScript
Top Content
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.
Get rid of your API schemas with tRPC
React Day Berlin 2022React Day Berlin 2022
29 min
Get rid of your API schemas with tRPC
Top Content
Today's Talk introduces TRPC, a library that eliminates the need for code generation and provides type safety and better collaboration between front-end and back-end. TRPC is demonstrated in a Next JS application integrated with Prisma, allowing for easy implementation and interaction with the database. The library allows for seamless usage in the client, with automatic procedure renaming and the ability to call methods without generating types. TRPC's client-server interaction is based on HTTP requests and allows for easy debugging and tracing. The library also provides runtime type check and validation using Zod.
Diagnostics de Node.js listos para usar
Node Congress 2022Node Congress 2022
34 min
Diagnostics de Node.js listos para usar
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.
El Estado de Node.js 2025
JSNation 2025JSNation 2025
30 min
El Estado de Node.js 2025
The speaker covers a wide range of topics related to Node.js, including its resilience, popularity, and significance in the tech ecosystem. They discuss Node.js version support, organization activity, development updates, enhancements, and security updates. Node.js relies heavily on volunteers for governance and contribution. The speaker introduces an application server for Node.js enabling PHP integration. Insights are shared on Node.js downloads, infrastructure challenges, software maintenance, and the importance of update schedules for security.

Workshops on related topic

Masterclass de Node.js
Node Congress 2023Node Congress 2023
109 min
Masterclass de Node.js
Top Content
Workshop
Matteo Collina
Matteo Collina
¿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.

Nivel: intermedio
Práctica con la Rejilla de Datos React de AG Grid
React Summit 2022React Summit 2022
147 min
Práctica con la Rejilla de Datos React de AG Grid
Top Content
Workshop
Sean Landsman
Sean Landsman
Comienza con la Rejilla de Datos React de AG Grid con un tutorial práctico del equipo central que te llevará a través de los pasos para crear tu primera rejilla, incluyendo cómo configurar la rejilla con propiedades simples y componentes personalizados. La edición comunitaria de AG Grid es completamente gratuita para usar en aplicaciones comerciales, por lo que aprenderás una herramienta poderosa que puedes agregar inmediatamente a tus proyectos. También descubrirás cómo cargar datos en la rejilla y diferentes formas de agregar renderizado personalizado a la rejilla. Al final de la masterclass, habrás creado una Rejilla de Datos React de AG Grid y personalizado con componentes React funcionales.- Comenzando e instalando AG Grid- Configurando ordenación, filtrado, paginación- Cargando datos en la rejilla- La API de la rejilla- Usando hooks y componentes funcionales con AG Grid- Capacidades de la edición comunitaria gratuita de AG Grid- Personalizando la rejilla con Componentes React
Construir y Desplegar un Backend Con Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Construir y Desplegar un Backend Con Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic te permite desarrollar rápidamente GraphQL y REST APIs con un esfuerzo mínimo. La mejor parte es que también te permite desatar todo el potencial de Node.js y Fastify siempre que lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y plugins adicionales. En la masterclass, cubriremos tanto nuestros módulos de Open Source 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 esta masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la Platformatic Cloud.
Construyendo APIs GraphQL sobre Ethereum con The Graph
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Construyendo APIs GraphQL sobre Ethereum con The Graph
Workshop
Nader Dabit
Nader Dabit
The Graph es un protocolo de indexación para consultar redes como Ethereum, IPFS y otras blockchains. Cualquiera puede construir y publicar APIs abiertas, llamadas subgrafos, para hacer que los datos sean fácilmente accesibles.

En este masterclass aprenderás cómo construir un subgrafo que indexa datos de blockchain de NFT del contrato inteligente Foundation. Desplegaremos la API y aprenderemos cómo realizar consultas para recuperar datos utilizando diferentes tipos de patrones de acceso a datos, implementando filtros y ordenamiento.

Al final del masterclass, deberías entender cómo construir y desplegar APIs de alto rendimiento en The Graph para indexar datos de cualquier contrato inteligente desplegado en Ethereum.
Construyendo un Servidor Web Hiper Rápido con Deno
JSNation Live 2021JSNation Live 2021
156 min
Construyendo un Servidor Web Hiper Rápido con Deno
Workshop
Matt Landers
Will Johnston
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.
0 a Auth en una Hora Usando NodeJS SDK
Node Congress 2023Node Congress 2023
63 min
0 a Auth en una Hora Usando NodeJS SDK
WorkshopFree
Asaf Shen
Asaf Shen
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