- En entornos de JavaScript y Node.js, Joi, una librería de validación, es más lenta en rendimiento que otras librerías
- Reemplazar Joi por otra librería permite esperar una mejora de rendimiento en entornos backend
- Se probó si en aplicaciones backend puede aparecer una diferencia de rendimiento significativa
- Las pruebas se realizaron con k6, y también se evaluaron lodash y class-transformer
- Resultados de las pruebas de rendimiento:
- native vs lodash: no hay diferencia de rendimiento
- object literal vs class-transformer: no hay diferencia de rendimiento
- non-validation vs Joi: aun con el bajo rendimiento de Joi, no aparece una diferencia de rendimiento
- El rendimiento es importante, pero en proyectos ya en marcha puede que no se perciba una diferencia de rendimiento proporcional al tiempo invertido al hacer cambios
8 comentarios
Creo que la intención del autor no es mejorar una situación de cuello de botella, sino sostener que, en un entorno similar a uno real, la diferencia de rendimiento entre las bibliotecas de validación no es tan significativa.
¿Qué pasaría si suponemos que no es un servicio que solo tiene tareas I/O-bound, como se explicó en el artículo, sino un servicio con tareas CPU-bound?
Los servicios en entornos reales son más complejos de lo que uno piensa. Un servidor no es solo una API que sirve los datos necesarios para renderizar la UI.
Como las tareas de validación y serialización de JSON son operaciones que se realizan en el hilo principal, no es algo que se pueda tomar a la ligera. En el ecosistema de backend con TS, lo más común es usar
class-validator/class-transformer. Y estos pueden validar alrededor de 4 MB por segundo; es decir, el hilo principal no puede procesar más de 4 MB por segundo.Las operaciones de entrada/salida con la DB funcionan en hilos en segundo plano, no en el principal, así que desde la perspectiva de un servidor backend (un servidor TS) no suelen afectar mucho la cantidad de conexiones concurrentes. Dependiendo de la naturaleza del servicio, si la cantidad de DTO que se transmite de una sola vez es grande, una validación lenta puede dar todavía más miedo (de hecho, hubo casos en los que, al crear un servicio con mucho volumen de datos por solicitud, la concurrencia de NestJS quedó en un solo dígito).
Estoy de acuerdo. Para dar por sentado lo que afirma el autor como una situación "real", el ejemplo de situación real que presentó es demasiado sesgado.
Como dijo la persona de arriba, es un benchmark en el que cuesta entender por qué se incluyó la entrada/salida de la base de datos. Y la validación y serialización lentas afectan más negativamente al rendimiento del servidor en los DTO de respuesta que en los DTO de solicitud. Por último, al hacer este tipo de experimentos de benchmark, no se debería probar con un solo DTO, sino con varios tipos distintos.
De hecho, cuando no hay I/O de base de datos y se prueban DTO con estructuras variadas, los resultados difieren.
Desde el principio, parece que el cuello de botella está del lado de la conexión a la base de datos, así que me pregunto si el tema no estará mal planteado.
Parece como si lo hubieran presentado como una mejora de rendimiento aunque en realidad no la hay, pero de hecho desde el principio el cuello de botella está del lado de la base de datos, así que creo que centrarse en mejorar un punto que no es el cuello de botella puede generar malentendidos.
En la mayoría de los entornos, mejorar el rendimiento significa eliminar cuellos de botella; al optimizar la validación, eso debería hacerse solo después de identificar que la validación es el cuello de botella.