- Em ambientes JavaScript e Node.js, a biblioteca de validação Joi é mais lenta em desempenho do que outras bibliotecas
- Substituir o Joi por outra biblioteca pode trazer ganhos de desempenho esperados em ambientes de backend
- Foi testado se uma diferença de desempenho significativa pode aparecer em aplicações backend
- Os testes foram realizados com k6, e lodash e class-transformer também foram testados juntos
- Resultado dos testes de desempenho:
- native vs lodash: sem diferença de desempenho
- object literal vs class-transformer: sem diferença de desempenho
- non-validation vs Joi: apesar do desempenho mais lento do Joi, não apareceu diferença de desempenho
- Desempenho é importante, mas em projetos já em andamento, ao fazer mudanças, talvez não se perceba diferença de desempenho proporcional ao tempo investido
8 comentários
Acho que a intenção do autor não é melhorar uma situação de gargalo, mas sim defender que, em um ambiente parecido com o de uso real, a diferença de desempenho entre bibliotecas de validação não é tão significativa.
E se presumirmos que, em vez de um serviço com apenas tarefas I/O bound como o autor descreveu no texto, fosse um serviço com tarefas CPU bound?
Os serviços em ambientes reais são mais complexos do que se imagina. Um servidor não é apenas uma API que serve os dados necessários para renderizar a UI.
Como validação e serialização de JSON são operações executadas na thread principal, não é algo para subestimar. No ecossistema de backend em TS, o mais comum de usar é
class-validator/class-transformer. E essas ferramentas conseguem validar algo em torno de 4 MB por segundo, o que significa que não dá para processar mais de 4 MB por segundo na thread principal.Já a entrada e saída com o DB rodam em threads de background, não na principal, então, do ponto de vista de um servidor backend (mais especificamente um servidor TS), isso não afeta tanto a quantidade de conexões simultâneas. Dependendo da natureza do serviço, se o volume de DTO enviado de uma vez for grande, a lentidão da validação pode ser ainda mais assustadora (na prática, já houve caso de um serviço com muito dado por requisição em que o número de conexões simultâneas no NestJS ficou em apenas um dígito).
Concordo. Para partir da premissa de que isso seria uma situação "do mundo real", o exemplo apresentado como situação real é limitado demais.
Como a pessoa acima disse, é um benchmark difícil de entender por que incluiu I/O de banco de dados. Além disso, validação e serialização lentas causam um impacto mais prejudicial no desempenho do servidor no DTO de resposta do que no DTO de requisição. Por fim, ao fazer esse tipo de experimento de benchmark, não se deve testar com apenas um DTO, mas sim com vários tipos diferentes.
Na prática, quando não há I/O de banco de dados e são testados DTOs com estruturas variadas, os resultados são diferentes.
Desde o início, parece que o gargalo está mais no lado da conexão com o banco de dados, então fico pensando se o tema não está equivocado.
Parece que foi apresentado como se houvesse ganho de desempenho, quando na verdade não há, mas na realidade o gargalo desde o início está no banco de dados, então acho que focar em melhorar um ponto que não é o gargalo pode acabar gerando mal-entendidos.
Na maioria dos ambientes, melhorar o desempenho significa eliminar gargalos; ao otimizar a validação, isso só deve acontecer depois que se identificar que a própria validação é o gargalo.