Belajar Flask - Bagian 14
Kapan Sebaiknya Memakai Flask?
oleh: Suryo Adhy Chandra, ST
Setelah tiga belas bagian sebelumnya membahas cara memakai Flask, bagian ini membahas pertanyaan yang justru sering datang belakangan: kapan sebenarnya Flask menjadi pilihan yang tepat, dan kapan sebaiknya memilih yang lain. Pertanyaan ini penting karena memilih perkakas yang keliru di awal proyek biasanya baru terasa akibatnya berbulan-bulan kemudian.
1. Apa yang sebenarnya diberikan Flask
Flask disebut microframework. Kata micro di sini bukan berarti hanya untuk proyek kecil, melainkan berarti Flask hanya menyediakan inti yang paling dasar: menerima permintaan dari browser, mencocokkannya dengan alamat tertentu, lalu mengembalikan jawaban. Selebihnya diserahkan kepada kita.
Delapan baris di atas sudah menjadi aplikasi web yang bisa dijalankan. Tidak ada berkas konfigurasi yang harus diisi lebih dulu, tidak ada struktur folder yang wajib diikuti, dan tidak ada perintah pembuatan project. Inilah daya tarik utama Flask.
2. Keadaan yang membuat Flask menjadi pilihan tepat
a. Membuat API yang tugasnya spesifik. Kalau yang dibutuhkan hanya beberapa alamat yang mengembalikan data JSON, misalnya layanan yang menghitung ongkos kirim atau memeriksa status suatu nomor, Flask memberi hasil paling cepat dengan kode paling sedikit.
b. Membuat prototipe atau membuktikan ide. Saat sebuah gagasan masih perlu ditunjukkan cepat kepada calon pengguna, kecepatan membuat lebih penting daripada kerapian struktur. Flask memungkinkan satu berkas Python menjadi aplikasi yang bisa didemokan hari itu juga.
c. Belajar cara kerja aplikasi web. Karena Flask tidak menyembunyikan banyak hal, alur permintaan dan jawaban terlihat jelas. Bagi yang sedang belajar, ini justru menguntungkan: kita tahu persis apa yang terjadi, bukan sekadar mengikuti perintah yang sudah disiapkan framework.
d. Menempelkan antarmuka web pada program yang sudah ada. Misalnya sudah ada skrip Python untuk mengolah berkas Excel, lalu ingin dijalankan lewat browser oleh staf lain. Membungkusnya dengan Flask jauh lebih ringan daripada memindahkannya ke framework besar.
3. Keadaan yang membuat Flask kurang cocok
Kebebasan Flask menjadi beban ketika aplikasinya tumbuh. Beberapa tanda yang biasanya muncul:
- Banyak tabel yang saling berhubungan. Flask tidak membawa ORM maupun sistem migrasi. Keduanya perlu dipasang dan diatur sendiri, dan pengaturan itu berbeda-beda di tiap proyek.
- Perlu halaman pengelolaan data untuk staf. Halaman tambah, ubah, hapus, cari, dan saring harus dibuat sendiri satu per satu. Pekerjaan ini memakan waktu dan hasilnya mudah tidak konsisten.
- Ada beberapa jenis pengguna dengan hak akses berbeda. Sistem login dan pengaturan hak akses harus dirakit dari beberapa paket, dan di sinilah celah keamanan paling sering muncul.
- Dikerjakan oleh tim dan dirawat bertahun-tahun. Karena struktur project ditentukan sendiri, dua proyek Flask bisa sangat berbeda susunannya. Pengembang baru butuh waktu lebih lama untuk memahami kode yang bukan buatannya.
4. Perbandingan singkat dengan pilihan lain
| Kebutuhan | Pilihan yang biasanya paling pas | Alasannya |
|---|---|---|
| Satu atau beberapa API sederhana | Flask | Ringan, cepat dibuat, tanpa struktur wajib |
| API dengan validasi data ketat dan dokumentasi otomatis | FastAPI | Validasi tipe data dan dokumentasi dibuatkan otomatis |
| Aplikasi berisi banyak data, pengguna, dan hak akses | Django | ORM, migrasi, login, dan halaman admin sudah tersedia |
| Prototipe cepat untuk menunjukkan ide | Flask | Satu berkas sudah cukup untuk didemokan |
| Situs yang isinya jarang berubah | HTML statis | Tidak memerlukan server aplikasi maupun database |
5. Kalau proyek Flask terlanjur membesar
Tidak perlu langsung menulis ulang semuanya. Ada beberapa langkah yang biasanya sudah cukup menahan kerumitan:
- Pecah berkas utama memakai Blueprint, agar tiap bagian aplikasi punya berkasnya sendiri.
- Pisahkan pengaturan aplikasi ke berkas konfigurasi tersendiri, jangan dicampur dengan kode.
- Pakai SQLAlchemy untuk basis data dan Alembic untuk mencatat perubahan strukturnya.
- Simpan kunci dan kata sandi di variabel lingkungan, bukan ditulis langsung di dalam kode.
Kalau setelah semua itu aplikasinya masih terus tumbuh dan mulai memerlukan halaman pengelolaan data serta pengaturan hak akses yang rumit, barulah pindah ke Django menjadi pertimbangan yang masuk akal.
6. Ringkasnya
Pakailah Flask kalau ruang lingkupnya jelas dan tidak akan tumbuh liar, kalau yang dibutuhkan adalah layanan kecil atau prototipe, atau kalau kamu memang ingin memahami cara kerja aplikasi web dari dekat. Pilihlah framework yang lebih lengkap kalau aplikasimu berisi banyak data, banyak jenis pengguna, dan direncanakan dipakai jangka panjang.
Yang perlu diingat, memilih framework bukan soal mana yang lebih hebat. Flask dan Django sama-sama dipakai di aplikasi besar yang berjalan bertahun-tahun. Yang membedakan hanyalah seberapa banyak keputusan yang ingin kamu ambil sendiri, dan seberapa banyak yang ingin sudah diambilkan.