Kita telah menulis server dengan module http polos, menyusun routing dan middleware di Express, lalu mencicipi pendekatan skema milik Fastify. Sekarang saatnya menjawab pertanyaan yang sejak awal section ini kita tangguhkan: pilihan mana yang tepat untuk proyek kita berikutnya? Chapter ini tidak memberikan satu jawaban baku, melainkan kerangka menimbang — kriteria apa yang relevan, bagaimana peta keputusannya, dan trade-off apa yang kita terima dari setiap pilihan.
Kriteria Penilaian #
Sebelum membandingkan produk, kita perlu setuju pada ukuran. Lima kriteria berikut paling sering menjadi penentu di dunia nyata:
- Keakraban tim: framework terbaik secara teknis tetap mahal bila seluruh tim harus belajar dari nol. Kecepatan pengiriman fitur sering lebih berharga daripada selisih performa.
- Performa: seberapa banyak permintaan per detik yang harus dilayani, dan seberapa ketat batas latensinya. Tolok ukur memberi gambaran, tetapi profil aplikasi kita sendiri yang memutuskan.
- Ekosistem: ketersediaan package pendukung, contoh kode, dan jawaban di forum. Ekosistem besar mempercepat penyelesaian masalah yang sudah pernah dihadapi orang lain.
- Dukungan TypeScript: bila proyek memakai TypeScript, kualitas definisi tipe framework menentukan pengalaman pengembangan sehari-hari.
- Kebutuhan validasi dan kontrak API: API publik dengan kontrak ketat mendapat manfaat besar dari skema JSON; alat internal kecil mungkin tidak memerlukannya.
Peta Keputusan #
Diagram di atas adalah versi ringkas. Tabel berikut menambahkan alasan dan pengecualian untuk tiap jalur:
| Situasi proyek | Pilihan yang wajar | Alasan |
|---|---|---|
| Webhook tunggal, health check, alat internal kecil | Module http polos | Tanpa dependency, kode pendek, mudah diaudit |
| Prototipe API, tim baru mengenal Node.js | Express | Kurva belajar landai, contoh kode sangat melimpah |
| API dengan kontrak ketat, throughput tinggi, validasi menyeluruh | Fastify | Skema JSON bawaan, serialization cepat, error terstruktur |
| Aplikasi besar dengan tim lintas divisi, butuh arsitektur baku | NestJS | Struktur module, controller, dan dependency injection yang terstandar |
| Alat CLI atau skrip otomasi | Tanpa framework web | Framework web tidak relevan untuk program tanpa server |
Satu baris pada tabel di atas mungkin asing: NestJS adalah framework aplikasi sisi server yang dibangun di atas TypeScript dengan arsitektur yang menyerupai Angular — module, controller, provider, dan dependency injection. NestJS menempati lapisan di atas Express (secara bawaan) atau Fastify, sehingga konsep routing dan middleware yang kita pelajari tetap berlaku di dalamnya.
Jujur soal Performa #
Tolok ukur pada situs Fastify secara konsisten menempatkan Fastify di atas Express untuk throughput permintaan per detik, dan keduanya di atas server yang menangani I/O secara sinkron. Angka tersebut nyata, tetapi konteksnya perlu kita pahami sebelum dijadikan dasar keputusan.
Pada aplikasi nyata, waktu pemrosesan umumnya didominasi oleh menunggu basis data, layanan eksternal, atau pengerjaan CPU — bukan oleh lapisan routing framework. Selisih beberapa ribu permintaan per detik di tolok ukur hanya terasa ketika aplikasi benar-benar beroperasi di batas kemampuan tersebut. Untuk sebagian besar proyek, keputusan yang lebih berdampak adalah memastikan seluruh operasi I/O berjalan non-blocking — materi yang sudah kita kuasai di Section Asynchronous Runtime.
TypeScript dan Ekosistem #
Dukungan TypeScript membedakan ketiga pilihan dengan cara yang berbeda. Express ditulis dalam JavaScript murni, sehingga proyek TypeScript memerlukan definisi tipe dari package @types/express yang dikelola komunitas. Fastify ditulis dengan TypeScript dan membawa definisi tipe bawaan yang kaya — handler async yang mengembalikan nilai juga cenderung lebih ramah analisis tipe daripada callback yang menulis respons secara manual. NestJS sejak awal dirancang berbasis TypeScript, menjadikan tipe sebagai bagian dari arsitektur, bukan lapisan tambahan.
Ekosistem package juga layak dihitung: hampir semua middleware populer di npm ditulis untuk Express terlebih dahulu, sementara Fastify memiliki koleksi plugin resmi di bawah naungan organisasinya sendiri. Untuk kebutuhan yang umum — body parsing, CORS, sesi, logging — keduanya sudah terlayani dengan baik; perbedaan baru terasa ketika kita memerlukan package yang lebih niche.
Keterikatan dan Migrasi #
Setiap framework menumbuhkan pola khas: middleware berantai pada Express, plugin berenkapsulasi pada Fastify, decorator dan lifecycle hooks pada Fastify, hingga arsitektur berlapis pada NestJS. Semakin dalam pola tersebut membentuk kode kita, semakin mahal biaya berpindah di kemudian hari. Penyebutan yang menenangkan: keduanya tetap berjalan di atas Node.js — logika domain, akses basis data, dan pengujian yang kita tulis dengan disiplin tetap dapat ikut pindah.
Dengan kerangka ini, keputusan framework berubah dari perdebatan selera menjadi penilaian yang bisa dijelaskan. Setelah framework dipilih dan API berdiri, kebutuhan berikutnya hampir selalu sama: menyimpan data agar tidak hilang saat proses berakhir. Perjalanan kita lanjutkan di Section Database Integration.