Apakah validasi berdampak besar pada performa di lingkungan aplikasi backend Node.js?

• Di lingkungan JavaScript dan Node.js, Joi sebagai pustaka validasi lebih lambat performanya dibanding pustaka lain
  • Jika Joi diganti dengan pustaka lain, peningkatan performa di lingkungan backend dapat diharapkan
• Dilakukan pengujian untuk melihat apakah perbedaan performa yang bermakna dapat muncul pada aplikasi backend
  • Pengujian dilakukan menggunakan k6, sekaligus menguji lodash dan class-transformer
• Hasil uji performa:
  • native vs lodash: tidak ada perbedaan performa
  • object literal vs class-transformer: tidak ada perbedaan performa
  • non-validation vs Joi: meskipun performa Joi lebih lambat, tidak muncul perbedaan performa
• Performa memang penting, tetapi pada proyek yang sudah berjalan, perubahan seperti ini mungkin tidak memberikan perbedaan performa yang terasa dibanding waktu yang diinvestasikan

[winterjung]

Saya rasa penulisnya mungkin bukan ingin memperbaiki situasi bottleneck, melainkan berargumen bahwa dalam lingkungan yang mirip dengan kondisi nyata, perbedaan performa antar library validasi tidak terlalu signifikan.

[ddddddd]

Bagaimana jika kita berasumsi ini bukan layanan yang hanya memiliki io bound task seperti yang dijelaskan di artikel, melainkan layanan dengan cpu bound task?
Layanan di lingkungan nyata lebih kompleks dari yang dibayangkan. Server bukan hanya API penyajian data yang dibutuhkan untuk merender UI

[samchon]

Karena operasi validasi dan serialisasi JSON dijalankan di thread utama, ini bukan hal yang bisa dianggap sepele. Di ekosistem backend TS, yang paling umum digunakan adalah class-validator/class-transformer. Dan kapasitas validasi per detiknya sekitar 4MB, yang berarti thread utama tidak bisa memproses lebih dari 4MB per detik.

Karena I/O DB berjalan di thread latar belakang, bukan thread utama, dari sudut pandang server backend (khususnya server TS) hal itu tidak terlalu berdampak besar pada jumlah koneksi simultan. Bergantung pada karakteristik layanan, jika jumlah DTO yang dikirim sekaligus besar, validasi yang lambat justru bisa lebih menakutkan (bahkan ada kasus nyata ketika membangun layanan dengan data besar per request, koneksi simultan NestJS hanya berada di satu digit).

[ddddddd]

Saya setuju, untuk mengajukan premis seperti yang diklaim penulis, yaitu "dalam situasi nyata", contoh situasi nyata yang diberikan terlalu sempit.

[samchon]

Seperti yang dikatakan orang di atas, ini benchmark yang sulit dipahami kenapa I/O DB dimasukkan. Selain itu, validation dan serialization yang lambat lebih besar dampak buruknya terhadap performa server pada response DTO daripada request DTO. Terakhir, saat melakukan eksperimen benchmark seperti ini, seharusnya tidak hanya menggunakan satu DTO, tetapi mengujinya dengan berbagai jenis DTO.

Ketika benar-benar tidak ada DB I/O dan DTO dengan berbagai struktur diuji, hasilnya pun berbeda-beda.

• Benchmark sisi server: https://github.com/samchon/nestia/…%20Core(TM)%20i5-1135G7%20%40%202.40GHz
• Benchmark kecepatan validation murni: https://github.com/samchon/typia/…%20Core(TM)%20i5-1135G7%20%40%202.40GHz

[ddddddd]

Sejak awal sepertinya bottleneck-nya ada di sisi koneksi DB, jadi saya rasa topiknya mungkin kurang tepat.

[ddddddd]

Sepertinya ini dikemas seolah-olah ada peningkatan performa padahal sebenarnya tidak ada, tetapi pada dasarnya bottleneck-nya memang ada di sisi DB, jadi menurut saya penulisan yang berfokus pada perbaikan di titik yang bukan bottleneck bisa menimbulkan kesalahpahaman.

[ddddddd]

Di sebagian besar lingkungan, peningkatan performa berarti mengatasi titik bottleneck. Saat mengoptimalkan validasi, tentu hal itu sebaiknya dilakukan setelah teridentifikasi bahwa sisi validasi memang merupakan bottleneck.