Preferensi Menggunakan Django

Django sampai saat ini merupakan framework favorit saya, dari segi fitur sampai developer experience bagi saya django memenuhi ekspektasi.

Django memang bukan framework tercepat tapi untuk banyak hal saya tasa sudah cukup.

Di tulisan kali ini bukan untuk membahas django adalah framework terbaik, kenapa django lambat, atau sebagainya, tulisan ini lebih ke bagaimana saya menyusun dan mengerjakan suatu hal dengan django.

Mengikuti pola

Ketika memasang django kita suda diberikan struktur django yang cukup baik, beberapa ada yg kadang mengubah strukturnya agar sesuai dengan yang diharapkan, bagi saya cukup gunakan struktur yang disediakan jangan ubah terlalu jauh karena jika memang ingin mengikuti struktur yang sangat diinginkan, opsi fast api atau flask harusnya lebih cocok.

Fat model? Fat view?

Diskusi yang cukup sering muncul saat menulis dengan django adalah pilihan pola yang dipake apakah fat model atau fat view, maksudnya apa?

Fat model sesuai namanya menggemukan model, menambah manager, custom method, dan banyak hal di dalam model sehingga modelnya menjadi gemuk dengan banyak tambahan fungsionalitas tadi.

Keuntungannya, karena model adalah pintu awal dan terakhir yg berhubungan dengan data jadinya ketika model dipakai di beragam tempat fungsi yang dibuat bisa hampir dipake di mana saja.

Kekurangannya bagi saya adalah model bukan lagi representasi sebuah tabel, tapi banyak hal jadinya, ingat model adalah abstraksi dari tabel, orm abstraksi dari sql, menambah method di model berarti menambah abstraksi.

Fat view sebaliknya fungsi-fungsi cenderung banyak di views dan model akhirnya hanya berupa petugas menyimpan dan menarik data, beban berat seperti validasi awal, sanitasi, dan logika lainnya berada di level views sehingga models cukup menerima data yang sudah siap disimpan.

Kekurangannya bagi beberapa orang fungsinya menjadi spesifik di satu view itu saja tidak fleksibel, kemungkinan terdapat pengulangan logic (yang sebenarnya menurut saya gapapa daripada over engineering) sangat tingi.

Kalau dua-duanya tidak terus gimana?

Saya memilih menambah satu layer sebelum model dan view yaitu service, kenapa saya memilih pendekatan seperti ini

1. Model cukup bertindak untuk membuat table, saya suka fungsi migration django jadi ya cukup di sana saja.
2. Manfaatkan raw query, cukup sering terjebak dalam pertanyaan "query ini kalau orm nya gimana ya?" kalau sudah tahu querynya kenapa gak langsung saja iya kan?
3. Views cukup sebagai http handler saja, nerima request dan memberikan response
4. Service berfungsi sebagai otak utama dari aplikasi, service tidak peduli dia dipanggil dari views atau tempat lainnya, yang dia tahu jika ada input A maka saya harus memproses menjadi B

Bagi saya benefitnya

1. Model menjadi representasi table, walaupun tidak sepenuhnya mirip tapi memanfaatkan migration menjadi enak, dan nanti jika masih menggunakan model walau tanpa orm kita masih bisa memanfaatkan tools-tools seperti factory boy dalam konteks testing.
2. Pada akhirnya kita menulis sql, mudah dishare ke beragam platform juga jadinya.
3. Satu fungsi di service bertindak satu tanggung jawab, mudah di maintain, dan karena ini di service bisa dipanggil di mana saja kan

Hindari signal jika memungkinkan

Saya punya pengalaman debugging dengan signal yang tidak terlalu menyenangkan, jika tidak butuh-butuh amat mending jangan

Debug tools adalah sahabat

Ipdb, django debug toolbar, django plus adalah beberapa tools tambahan di mode development untuk identifikasi masalah lebih mudah

Granian over gunicorn

Mencoba membandingkan granian dan gunicorn merasakan perbedaan cukup signifikan dengan rps basic, walaupun rps hello world tidak merepresentasikan app sepenuhnya saya kira tetap penting melihat penaikan performa walaupun mungkin tidak banyak setelah dipasang operasional lainnya