Mari kita bantu pengembang mencari tahu apakah kerangka kerja Django cocok untuk proyek mereka berikutnya. Kemungkinan - cocok.
Jangan menggunakan bahasa pemrograman atau kerangka kerja tertentu hanya karena Anda menggunakannya dalam proyek sebelumnya, atau hanya karena Anda sudah terbiasa dengannya. Jadi hal-hal tidak dilakukan.
Sebelum memulai proyek baru, Anda harus mengevaluasi bahasa atau kerangka kerja mana yang terbaik bagi Anda untuk mencapai hasil yang diinginkan. Apa yang paling penting bagi Anda? Keamanan, kecepatan pengembangan, skalabilitas, fleksibilitas, dukungan?
Lebih baik membuat keputusan berdasarkan informasi sebelum mulai bekerja daripada bertobat dengan tergesa-gesa nanti (atau, lebih buruk, menggantungkan kruk pada proyek dalam proses implementasi - karena kenyataan bahwa Anda tidak peduli dengan dukungannya di muka).
Saya bekerja dengan teknologi yang berbeda selama bertahun-tahun, berurusan dengan pengembangan seluler dan web, dan saya pikir Django menawarkan serangkaian fitur lengkap yang tidak ditemukan dalam kerangka web lainnya.
Saya mengerti ini pernyataan yang keras. Biarkan saya membenarkannya.
“Django memiliki banyak situs yang digunakan paling aktif, khususnya Instagram dan Pinterest. Bahkan Facebook menggunakan Django untuk banyak utilitasnya. Django lahir di lingkungan penerbitan, jadi tidak mengherankan bahwa kerangka ini digunakan di situs-situs seperti The Washington Post dan Smithsonian Magazine. " - Amit Ashvini , Wakil Presiden Pemasaran @ Zibtek
Pandangan umum: kapan harus menggunakan Django
Jika setidaknya beberapa poin di bawah ini tentang Anda (dan tidak ada poin dalam daftar yang sangat tidak Anda setujui), maka Django mungkin cocok untuk proyek Anda.
- Anda perlu mengembangkan aplikasi web atau API backend.
- Anda perlu bekerja dengan cepat, menggunakan dengan cepat dan membuat perubahan pada proyek saat Anda bekerja.
- Secara default, aplikasi harus dilindungi dari kerentanan dan serangan yang paling umum, khususnya: CSRF, injeksi SQL, XSS, clickjacking, dll.
- Kapan saja, penskalaan mungkin diperlukan dalam aplikasi: penskalaan dan penyusutan.
- Di masa depan, Anda berencana untuk mengintegrasikan teknologi terbaru, misalnya, pembelajaran mesin.
- Anda perlu menggunakan kerangka kerja yang andal yang sedang dikembangkan secara aktif, digunakan oleh banyak perusahaan terkemuka dan situs web terkemuka di seluruh dunia.
- Baik aplikasi web dan sisi server API diharuskan berada di basis kode yang sama, konsisten dengan "satu sumber kebenaran" (prinsip KERING)
- Anda tidak ingin bekerja secara langsung dengan permintaan basis data, dan Anda memerlukan dukungan ORM.
- Anda akan menggunakan perangkat lunak gratis.
- Jika Anda buntu, Anda harus mencari solusinya sendiri, sehingga Anda akan memerlukan dokumentasi yang baik dan komunitas pengembang yang responsif.
Selain faktor-faktor di atas, Anda perlu mempertimbangkan keterampilan apa yang Anda (atau tim Anda) miliki.
Jika Anda seorang pengembang web dan sudah tahu cara kerja web, maka bekerja dengan Django akan bekerja untuk Anda relatif lancar. Anda perlu memahami bagaimana Django terstruktur, dan beberapa hal lain, tentu saja juga - dan menganggap bahwa Anda siap.
Situs berjalan pada kerangka Django
Sejarah Django sudah ada sekitar 10 tahun yang lalu. Selama periode ini, ini digunakan dalam produksi di banyak situs top. Berikut ini beberapa contoh luar biasa:
Rekayasa PinterestMozillaBitbucketUdemyBawangDisqusWashington PostNASASpotifyRekayasa InstagramGeografis nasionalWaliJsfiddleApakah Anda masih ragu apakah perlu menghabiskan waktu berharga Anda untuk berlatih dengan Django? Untuk memulai, mari kita bahas mengapa Django mungkin TIDAK COCOK untuk proyek Anda:
Saat tidak menggunakan Django
- Anda berurusan dengan aplikasi kolosal, dan itu tidak cocok dalam satu basis kode. Mungkin lebih baik untuk membagi aplikasi Anda ke dalam layanan microser. Setiap levelnya ditangani dengan lebih baik oleh tim yang berdedikasi. Untuk setiap kasus penggunaan spesifik, teknologi lain cocok. Dalam beberapa skenario ini, Django mungkin berguna, tetapi tidak praktis untuk sepenuhnya mengembangkan aplikasi semacam itu pada Django (serta kerangka kerja lain yang terpisah).
- Anda perlu menulis aplikasi sederhana di mana Anda tidak perlu bekerja dengan database, melakukan operasi file atau melakukan sesuatu yang setidaknya sedikit rumit.
Microframes paling cocok untuk situasi seperti itu. Salah satu microframes paling populer - Flask, seperti Django, ditulis dalam Python. Microframe serupa tersedia di teknologi lain, misalnya. Slim di PHP, Apache Spark di Java, Express.js di Node.js, dll. - Anda ingin menulis semuanya sendiri dari awal dan Anda tahu apa yang Anda lakukan.
- Anda atau kolega Anda sama sekali tidak terbiasa dengan Django / Python, dan Anda tidak punya waktu dan sumber daya untuk mengembangkan keterampilan yang diperlukan.
Solusi terbaik dalam kasus terakhir adalah bekerja dengan apa yang paling Anda ketahui. Jika Anda menggunakan teknologi atau kerangka kerja baru, maka kemungkinan mengacaukan meningkat berkali-kali lipat.
Jika semua hal di atas bukan tentang proyek Anda, maka Django mungkin cocok untuk Anda.
Alasan menggunakan Django
Kerangka kerja Django ditulis dalam Python:
Saya tahu Anda tahu itu.
Oleh karena itu, saya akan mengambil kesempatan ini dan menekankan beberapa keunggulan utama Django yang ia warisi dari Python. Saya akan singkat.
Python adalah salah satu bahasa pemrograman yang paling populer dan paling cepat berkembang di dunia.
Sumber:
Indeks TIOBEAnalisis data Jobs.com oleh Coding DojoGithub octoverseMempelajari Python sangat sederhana. Biasanya, pengembang modern adalah yang pertama mempelajari bahasa khusus ini.
Di atas tidak berarti sama sekali bahwa bahasa ini hanya untuk pemula. Python juga digunakan dalam teknologi canggih. Python secara aktif digunakan dalam tumpukan teknologi dari banyak perusahaan raksasa, termasuk Google.
Python sangat bagus untuk mengembangkan alat pengikis web.
Berinteraksi dengan baik dengan bahasa lain.
Pengembangan python tidak berarti bahwa Anda akan dipaksa untuk menulis semuanya hanya dengan Python.
Anda mungkin dapat menggunakan perpustakaan untuk banyak bahasa lain, termasuk C / C ++ / Java.
Python portabel, mudah dibaca.
Python bahkan dapat berjalan di JVM.
Mengenal Jython .
Python banyak digunakan dalam teknologi populer seperti Big Data dan Machine Learning.
Anda mendapatkan akses ke perpustakaan PyPI besar.
Django All Inclusive
“Semua termasuk” berarti bahwa Django berada di luar kotak yang dilengkapi dengan sebagian besar perpustakaan dan alat yang dibutuhkan dalam situasi praktis yang umum. Saya akan daftar: Django ORM, middleware, otentikasi, perpustakaan HTTP, dukungan multisite, i18n, Django Admin, mesin templat, dll. - dan itu belum semuanya. Tidak ada kerangka kerja lain yang diketahui bagi saya untuk memberikan dukungan luas sekaligus.
Beberapa menganggap ini "minus", sementara yang lain menganggapnya "plus". Setiap sisi hukum berbeda dalam caranya sendiri, dan sampai batas tertentu saya setuju dengan keduanya.
Ini adalah minus, karena dalam situasi seperti itu kerangka kerja berubah menjadi monolit.
Saya percaya bahwa jika Anda memerlukan fitur-fitur ini yang mengarah pada pembentukan monolith, maka dengan satu cara Anda harus menggunakan beberapa perpustakaan lain (atau menulis sendiri).
Jadi, mengapa tidak menggunakan alat di mana semua ini sudah ada, diuji dalam pertempuran, beroperasi di situs terbesar, secara aktif dikembangkan dan dilengkapi dengan dukungan masyarakat?
Jika Anda tidak memerlukan sebagian besar fitur yang ditawarkan oleh Django, maka lebih baik tetap menggunakan beberapa mikroframework.
Jangan menemukan kembali roda - Anda ingat? Luangkan waktu Anda pada apa yang benar-benar penting, dan biarkan Django melakukan sisanya.
Admin Django
Meskipun, saya menyebutkan elemen ini di bagian sebelumnya, itu layak mendapat perhatian lebih dekat. Dalam banyak kerangka kerja, khususnya, Laravel, Yii, dll., Upaya telah dilakukan untuk menyederhanakan pekerjaan dengan panel admin. Saya telah berhasil mengembangkan banyak proyek dalam kerangka kerja yang berbeda, tetapi tidak satu pun dari mereka dapat dibandingkan dengan Django dalam kenyamanan bekerja dengan panel admin.
Beberapa percaya bahwa Django Admin tidak cukup fleksibel, dan untuk menyempurnakan bagian mana pun dengan kebutuhan Anda, Anda perlu melakukan banyak usaha. Pada awalnya, bekerja dengan Django, saya cenderung setuju dengan ini, tetapi seiring waktu, setelah menemukan kerangka, saya menjadi yakin akan hal ini. Ya, ada kurva belajarnya sendiri, tetapi tidak sedetik pun yang Anda curahkan tidak akan sia-sia.
Bahkan, Django Admin sangat terstruktur dengan baik. Dalam beberapa proyek saya, saya menggunakan panel admin Django "apa adanya", dan yang lain saya benar-benar menggantinya dengan templat saya sendiri, yang saya kembangkan dari awal. Bagaimanapun, ini tidak lebih dari pengembangan dengan kerangka kerja lain yang saya tahu.
Plus utama? Anda mendapatkan hak akses dan otentikasi dari kotak. Butuh waktu berminggu-minggu (atau setidaknya beberapa hari) untuk mengembangkan semua ini dari awal.
Prinsip KERING (Jangan Diulang)
Saya tahu banyak kerangka kerja yang pendukungnya mengklaim bahwa mereka benar-benar mematuhi prinsip "KERING". Saya telah bekerja dengan banyak kerangka kerja seperti itu, tetapi tidak satupun dari mereka prinsip "KERING" dilaksanakan sebagaimana mestinya.
Sayangnya, dalam kebanyakan kerangka kerja, prinsip "KERING" sama sekali tidak diberi perhatian yang cukup. Menurut pendapat saya, jika Anda menulis aplikasi yang ingin Anda perbarui secara berkala (dan ini dapat dikatakan tentang sebagian besar aplikasi modern), maka Anda harus mengikuti prinsip KERING untuk menghindari masalah.
Jadi, di Laravel, Anda harus menulis validasi untuk setiap prosedur secara terpisah. Situasinya sama dengan kebanyakan kerangka kerja lainnya. Untuk membuat kode Anda mematuhi prinsip KERING, Anda harus bekerja keras. Sulit untuk melacaknya, terutama jika Anda bekerja sebagai tim.
Pada gilirannya, kerangka kerja Django dirancang sedemikian rupa sehingga melanggar prinsip KERING biasanya hanya muncul dengan sengaja.
Seharusnya tidak, kan? Pertimbangkan sebuah contoh.
Begini cara Django bekerja dengan validasi dan migrasi basis data
Buat kelas
Model dengan bidang yang diperlukan. Kami menunjukkan semua validasi dan batasan tambahan yang kami butuhkan.
Migrasi dihasilkan oleh satu perintah CLI: `python manage.py makemigrations`.
Perubahan dibuat ke database dengan satu perintah CLI: `python manage.py migrate`.
Validasi dan pembatasan diperiksa secara otomatis selama setiap operasi CRUD - apakah itu Admin Django atau Kerangka Django REST. Anda tidak perlu menulis validasi lagi.
Kelas model yang sama digunakan untuk menghasilkan tampilan Django Admin CRUD. Tidak diperlukan HTML / CSS khusus.
Bandingkan kondisi ini dengan kerangka kerja lain - dan, saya pikir, Anda tidak akan pernah bisa melakukan hal seperti ini hanya dalam beberapa baris kode berikut:
class Employee(models.Model): name = models.CharField(max_length=127) email = models.EmailField(null=True, blank=True) created_at = models.DateTimeField(blank=True, null=True, auto_now_add=True) updated_at = models.DateTimeField(blank=True, null=True, auto_now=True)
Ini bukan hanya tentang "tidak mengulangi". Pendekatan ini menyelamatkan Anda dari bug di masa depan. Kami semua mendapati diri kami dalam situasi di mana kami mengubah sesuatu di satu tempat dan lupa untuk mengganti di tempat lain - dan ini menjadi jelas hanya setelah banyak pengguna mulai mengalami masalah.
Di Django, kembali ke kode di atas, jika Anda harus mengganti bidang
`max_length` dengan sesuatu yang lain - lakukan saja di sini. Perubahan akan secara otomatis berlaku untuk validasi semua rute dan ke database.
Pemetaan Relasional Objek di Django
Django menyediakan mesin ORM out-of-box berfitur lengkap.
Saya bekerja dengan banyak alat ORM dalam berbagai teknologi, termasuk Eloquent, greenDAO, Yii AR, dll. Dalam semua itu, permintaan paling sederhana ditangani dengan cukup baik, tetapi cepat atau lambat saya harus menulis ini atau permintaan tersebut dari awal, karena mekanisme ORM tidak dapat mengatasi kasus praktis tertentu.
Dengan Django ORM, saya belum dalam situasi seperti itu. Ini bekerja sangat baik sehingga Anda mungkin lupa bahwa Anda bekerja dengan permintaan basis data. Inilah yang seharusnya menjadi pemetaan objek-relasional. Berikut ini adalah beberapa contoh dari Django ORM:
# 5 , rank = 10 age <= 30 top_young_employees = Employee.objects.filter(rank=10, age__lte=30)[:5] # employee = Employee.objects.create(name='John Doe', age=35, country='IN') # print(employee.name)
Perkembangan yang cepat
Pencipta dari hampir semua kerangka kerja web suka menyombongkan hal ini, dan, mungkin, mereka semua benar - tergantung pada makna apa yang kita masukkan ke dalam kata "cepat".
Benar, dengan Django beberapa hal dilakukan dengan cepat. Anda telah melihat betapa mudahnya kami dapat menentukan UI admin, tabel database, dan memvalidasi.
Itu hanya puncak gunung es.
Pada prinsipnya, perkembangan pesat bukanlah fitur seperti itu, tetapi hanya konsekuensi organik dari Django KERING, ORM, mesin templat dan filosofi semua-inklusif.
Django Framework Security
Harus diakui, terkadang pengembang malas. Saya sangat yakin. Dari waktu ke waktu saya menunda-nunda, menunda solusi untuk tugas-tugas penting. Di sinilah berbagai kerentanan dapat muncul.
Saya terutama menyukai kenyataan bahwa Django tidak membuat indulgensi keamanan untuk mempercepat laju pembangunan. Fitur keamanan diaktifkan secara default, jadi tidak masalah apakah Anda malas atau tidak.
Sumber terbuka, dokumentasi luar biasa, komunitas besar, dll.
Karena Django adalah sumber terbuka dan kerangka kerja yang sangat populer, sebuah komunitas responsif telah terbentuk di sekitarnya. Saya pikir Anda sadar akan keunggulan perangkat lunak bebas - dan karenanya, semuanya melekat di Django.
Dokumentasi Django resmi lebih dari cukup untuk pengembang apa pun. Jika Anda mengalami kesulitan, menemukan solusi tidaklah sulit.
Anda mungkin sudah memiliki kesan bahwa Django telah membuat banyak perpustakaan sendiri, jadi Anda mungkin akan terkejut bahwa tidak ada perpustakaan khusus untuk pengujian di sini. Tidak, jangan berpikir bahwa kerangka kerja Django tidak mendukung pengujian - ia mendukung, bahkan seperti itu. Hanya dengan mengikuti prinsip "Jangan Ulangi", tidak ada gunanya untuk mengembangkan perpustakaan untuk pengujian ketika perpustakaan yang sangat baik dari jenis ini sudah ada di Python itu sendiri. Django berinteraksi dengan baik dengannya. Selain itu, ia menggabungkan dengan sangat baik dengan perpustakaan pihak ketiga, seperti pytest.
Keadaan Django saat ini dan kerangka kerja populer lainnya
Jadi, saya mencoba semaksimal mungkin untuk menyoroti masalah yang saya temui ketika bekerja dengan kerangka kerja lain dan membandingkan kerangka kerja ini dengan Django. Setelah bekerja dengan Yii, CodeIgniter, WordPress, CS-Cart, Laravel, dll., Saya sampai pada kesimpulan bahwa Django jauh lebih baik daripada mereka.
Namun, ini hanya pendapat saya.
Jika Anda menyukai statistik, inilah studi tahunan Stack Overflow, di mana Django adalah salah satu kerangka kerja yang paling populer dan dicari:
Kerangka Kerja, Perpustakaan, dan AlatKerangka Kerja, Perpustakaan, dan Alat yang Paling Dicintai, Dicari, dan DicariSelain pengalaman di atas dengan PHP, saya juga mengembangkan aplikasi Android di Java, aplikasi klien di React.js. Dalam semua kasus ini, saya menghabiskan cukup banyak waktu refactoring basis kode, mencari arsitektur terbaik, setelah beberapa bulan menghubungkan masalah dengan skalabilitas dan kembali mengambil refactoring.
Saya baru-baru ini menulis ulang dari Laravel ke Django satu aplikasi yang saya miliki dalam produksi selama lebih dari setahun. Saya berhasil menggunakan basis kode baru dalam waktu kurang dari 10 hari, menulis jumlah minimum kode untuk ini (saya katakan sama: kompleksitas berkurang!) Dalam arah yang berlawanan, operasi seperti itu pasti akan memakan waktu lebih dari sebulan.
Jika Anda mencoba untuk langsung membandingkan kerangka kerja lain dengan Django, ini tidak akan memberi Anda apa pun.
Pemantauan kinerja dapat menunjukkan bahwa kerangka kerja Java lebih cepat daripada Django. Anda bisa menguasai PHP, jadi ada kemungkinan bahwa mengembangkan aplikasi Anda di Django akan lebih cepat daripada dengan kerangka kerja PHP yang sudah dikenal. Dalam hal aplikasi yang sangat sederhana, pengaturan Django mungkin tampak sedikit membosankan bagi Anda - tentu saja, jauh lebih mudah untuk menulis file dengan skrip. Hasil survei dapat bervariasi tergantung pada audiens mana mereka dilakukan.
Namun, di sini kita tidak hanya membahas kerangka kerja yang terkait dengan teknologi lain. Bahkan jika Anda terbiasa dengan Python, Anda mungkin menemukan mikroframework Flask lebih nyaman dan diinginkan. Kita harus memikirkan yang mana yang harus berhenti.
Saran saya adalah jangan membandingkannya.
Kesimpulan
Menurut pendapat saya, Django berhasil menyeimbangkan kinerja, arsitektur, kompleksitas pengembangan, keamanan dan skalabilitas dengan sempurna.
Jika Anda mulai menulis proyek dari awal, saya sangat merekomendasikan mencoba membuatnya dengan Django.