4 poin oleh GN⁺ 2025-12-11 | 1 komentar | Bagikan ke WhatsApp
  • Django 6.0 yang menandai ulang tahun ke-20 merupakan rilis besar yang membawa banyak peningkatan pada area inti seperti template, pekerjaan latar belakang, keamanan, email, dan lainnya
  • Fitur template partials memudahkan penggunaan ulang kode di dalam template serta memperkuat integrasi dengan alat seperti htmx
  • Framework Tasks baru ditambahkan sehingga pekerjaan latar belakang dapat dijalankan di luar siklus request-response HTTP
  • Content Security Policy (CSP) kini tersedia secara bawaan sehingga pertahanan terhadap serangan injeksi konten seperti XSS menjadi lebih mudah
  • Modernisasi API email, peningkatan ORM, perluasan kunci primer, dan lainnya secara signifikan meningkatkan pengalaman developer serta skalabilitas

Ikhtisar Django 6.0

  • Django 6.0 adalah rilis baru dari framework web Python yang melanjutkan evolusinya selama 20 tahun
  • Perubahan utama disusun di sekitar empat area inti: template, pekerjaan latar belakang, keamanan, dan pemrosesan email
  • Banyak kontributor dari komunitas developer ikut berpartisipasi, dan poin-poin peningkatan utama dirangkum berdasarkan catatan rilis resmi

Alat django-upgrade

  • Saat meningkatkan proyek yang sudah ada dari Django 5.2 atau versi lebih lama, alat django-upgrade dapat digunakan untuk melakukan transformasi kode secara otomatis
  • Termasuk 5 fixer otomatis terkait Django 6.0 yang dapat menyelesaikan sebagian peringatan secara otomatis

Template partials

  • Fitur definisi bagian template ({% partialdef %}) ditambahkan agar duplikasi kode di dalam template berkurang dan penggunaan ulang menjadi memungkinkan
    • Partial yang didefinisikan dalam template yang sama dapat dipanggil berkali-kali
    • Dengan opsi inline, partial dapat dirender sekaligus saat didefinisikan
  • Melalui fitur rendering parsial, hanya partial tertentu yang dapat dirender secara terpisah
    • Dalam contoh, view_count diperbarui secara berkala menggunakan htmx
    • Dengan menambahkan #partial_name pada URL, hanya bagian tertentu yang dapat dirender
  • Fitur ini diintegrasikan ke Django melalui proyek Google Summer of Code, dan dikembangkan dari paket django-template-partials yang sudah ada

Framework Tasks

  • Django kini menambahkan framework Tasks untuk menjalankan pekerjaan latar belakang
    • Kode dapat dijalankan di luar siklus request-response HTTP
    • Dapat digunakan untuk pekerjaan asinkron seperti pengiriman email, pemrosesan data, dan pembuatan laporan
  • Pekerjaan didefinisikan dengan dekorator @task, lalu dapat dimasukkan ke antrean dengan Task.enqueue()
  • Backend bawaan yang tersedia untuk pengembangan adalah ImmediateBackend dan DummyBackend,
    sedangkan eksekusi berbasis SQL DB dapat dilakukan dengan DatabaseBackend dari paket django-tasks
  • Worker tugas dijalankan dengan perintah db_worker, dan status dapat diperiksa melalui log
  • Fitur ini berawal dari ide di Wagtail, lalu diintegrasikan ke Django setelah proposal DEP 0014

Dukungan Content Security Policy (CSP)

  • Django 6.0 mendukung standar CSP secara bawaan, memperkuat pertahanan terhadap serangan injeksi konten seperti XSS
    • Aktifkan dengan menambahkan ContentSecurityPolicyMiddleware ke MIDDLEWARE
    • Kebijakan dapat dikonfigurasi melalui pengaturan SECURE_CSP dan SECURE_CSP_REPORT_ONLY
  • Keamanan berbasis nonce tersedia secara bawaan sehingga atribut nonce="{{ csp_nonce }}" dapat ditambahkan pada tag <script> dan <style>
    • Nonce acak dibuat untuk setiap request sehingga hanya resource tepercaya yang dapat dijalankan
  • CSP telah diusulkan sejak 2004 dan sebelumnya diimplementasikan melalui paket django-csp, lalu kini resmi dibangun langsung ke dalam framework

Pembaruan API email

  • Logika pemrosesan email di Django beralih ke API email modern dari Python 3.6
    • Secara internal menggunakan kelas email.message.EmailMessage
    • Antarmuka send_mail() dan EmailMessage yang ada tetap dipertahankan
  • API baru ini memberi keuntungan seperti lebih sedikit bug, keamanan yang lebih baik, dan penanganan lampiran inline yang lebih baik
  • Dengan objek MIMEPart, lampiran inline seperti gambar di dalam body HTML dapat ditambahkan dengan mudah
  • Perubahan ini diusulkan pada 2024 dan digabungkan setelah 8 bulan pengembangan

Pembatasan argumen posisi pada API email

  • Beberapa parameter pada API django.core.mail kini hanya boleh menggunakan argumen keyword
    • Jika argumen opsional seperti fail_silently diberikan sebagai argumen posisi, peringatan akan muncul
    • Ini dilakukan untuk meningkatkan keterbacaan dan kemudahan pemeliharaan
  • Perbaikan otomatis dapat dilakukan dengan fixer mail_api_kwargs dari django-upgrade

Perluasan auto import di Shell

  • Fitur auto import model dari Django 5.2 diperluas sehingga
    settings, connection, models, functions, timezone dan lainnya kini diimpor otomatis
  • Daftar auto import dapat diperiksa dengan ./manage.py shell -v 2
  • Meningkatkan kenyamanan pengembangan dan mengurangi kode berulang

Peningkatan ORM: pembaruan field dinamis saat save()

  • GeneratedField atau field berbasis ekspresi kini diperbarui otomatis setelah save()
    • Pada DB yang mendukung klausa RETURNING (SQLite, PostgreSQL, Oracle), perubahan langsung tercermin
    • Pada MySQL dan MariaDB, pembaruan otomatis dilakukan melalui lazy loading
  • Nilai terbaru bisa langsung digunakan tanpa query tambahan sehingga efisiensi meningkat

Fungsi agregasi Universal StringAgg

  • Fungsi agregasi StringAgg kini dapat digunakan di semua backend database
    • Mengembalikan string yang menggabungkan nilai input dengan pemisah (delimiter)
    • Sebelumnya ini adalah fitur khusus PostgreSQL, tetapi sekarang dapat digunakan langsung dari django.db.models
  • Pemisah dapat ditentukan dengan ekspresi Value()

BigAutoField sebagai default

  • Nilai default DEFAULT_AUTO_FIELD berubah menjadi BigAutoField
    • Menggunakan primary key integer 64-bit untuk mencegah masalah kehabisan Primary Key
    • Pada proyek baru, ini diterapkan otomatis tanpa konfigurasi tambahan
  • Menyederhanakan pengaturan yang diperkenalkan di Django 3.2 sehingga boilerplate berkurang

Peningkatan template

  • Variabel forloop.length ditambahkan sehingga total panjang dapat dirujuk di dalam loop
    • Digunakan dalam bentuk {{ forloop.counter }}/{{ forloop.length }}
  • Peningkatan pada tag template querystring
    • Saat mapping kosong, ? kini ditambahkan otomatis agar perilaku tautan tetap konsisten
    • Mendukung penggabungan beberapa argumen mapping sehingga kombinasi parameter query menjadi lebih mudah

Penutup

  • Django 6.0 melibatkan 174 kontributor dan
    mencakup banyak optimasi serta perbaikan bug
  • Melalui upgrade ini, keamanan, kemudahan pemeliharaan, dan pengalaman developer (DX) meningkat secara menyeluruh
  • Perubahan tambahan dapat dilihat di catatan rilis resmi

1 komentar

 
GN⁺ 2025-12-11
Komentar Hacker News
  • Sudah beberapa tahun memakai Django sesekali di perusahaan. Secara umum suka, tapi ORM-nya masih terasa sulit
    Django adalah framework yang opinionated, jadi saya baru belakangan benar-benar paham bahwa kita harus mengikuti ‘cara Django’.
    Masalahnya, saya harus menangani multi-database dari berbagai unit bisnis, jadi setiap kali selalu repot menyesuaikan kekhasan masing-masing.
    Akhirnya saya mematikan managed, mengimpor skema dengan inspectdb, lalu menghapus manual tabel-tabel yang tidak ingin diekspos ke web.
    Untuk webapp baru yang dibuat dari nol, Django tetap pilihan terbaik

    • Setuju. Tapi workflow migrasi DB masih terasa kurang
      Django tidak menyimpan status skema bersama kode, jadi setiap kali menjalankan perintah DB, ia harus menebak status saat ini.
      Mendefinisikan status DB lewat kode model memang punya batasan yang mendasar.
      Saya lebih suka pendekatan seperti Rails, yang menyusun migrasi dengan perintah DB yang eksplisit lalu menaruh model di atasnya
    • Penasaran apakah Anda memakai dukungan multi-database Django
    • Saya pernah memakai Aldjemy di proyek kecil, dan itu cukup bagus menangani kombinasi query kompleks yang sulit dilakukan dengan Django ORM
    • Saya sudah lebih dari 10 tahun memakai Django, dan ORM-nya menurut saya ‘lumayan’. Dulu sempat ada dorongan untuk pindah ke SQLAlchemy, tapi ternyata tidak sepadan.
      Antarmuka Manager memang membingungkan di awal, tapi alat migrasinya benar-benar luar biasa
    • Menyiapkan view atau materialized view lewat ORM sangat membantu meningkatkan performa.
      Anda bisa mendapat fleksibilitas tuning SQL sekaligus kenyamanan Django.
      Hanya saja, jangan lupa membuatnya di dalam skrip migrasi
  • Saya sangat suka bahwa Django terus membaik secara konsisten di setiap rilis.
    Versi 6.0 khususnya menarik karena punya banyak fitur berguna.
    Anggapan bahwa teknologi yang bisa diandalkan itu membosankan jelas salah. Berkembang seperti ini justru yang tepat

    • Saya juga sudah memakainya sejak era pre-1.0 dan masih menyukainya.
      Sekarang saya tinggal dekat tempat lahirnya Django.
      Tambahan, saya mulai mencari kerja sejak kemarin, jadi kalau ada yang mencari developer Django berpengalaman, silakan hubungi (oldspiceap@gmail.com)
  • Kode dan tulisan blog Adam selalu layak dibaca.
    Saya menantikan bagaimana framework tasks ini akan berkembang ke depan.
    Tapi agak disayangkan Django-Q2 yang hebat disebut hanya bersama Celery

    • Saya penulisnya. Terima kasih atas pujiannya, dan Celery disebut hanya karena popularitasnya ;)
    • Celery memang tidak sempurna, tapi pilihan terbaik yang ada.
      Bug-nya banyak, tapi basis penggunanya sangat besar sehingga jarang sekali Anda menjadi orang pertama yang mengalami masalah tertentu.
      Saya pernah menangani puluhan juta pesan per hari dengan kombinasi Celery + RabbitMQ secara andal.
      Itu masih solusi yang layak jadi pertimbangan pertama
    • Saya sudah bertahun-tahun memakai Celery, jadi penasaran apa yang jadi masalah dan bagaimana Django Q2 memperbaikinya.
      Di stack lain saya juga memakai Kafka, tapi itu untuk use case yang benar-benar berbeda levelnya
    • Saya penasaran kenapa Celery disebut ‘mengerikan’
  • Saya sudah sekitar 5~6 tahun memakai Django, dan walaupun keunggulan ‘batteries included’-nya jelas terasa, secara keseluruhan framework ini terasa berat

  • Fitur template partial tampak bagus.
    Salah satu alasan React jadi populer adalah reusabilitas kode, dan sepertinya Django juga bergerak ke arah sana

    • Inti reusabilitas dan komposabilitas React bukan pada template, melainkan pada gagasan bahwa semuanya adalah fungsi
    • Fitur ini sangat bernilai terutama saat dipakai bersama HTMX. HTMX membutuhkan banyak template partial
    • React tidak sekadar memberi template, tetapi komponen yang mengenkapsulasi state
    • Saya juga mencoba Django 6 dan memakai partial di blog saya
      Contohnya ada di kode ini
    • Mengejutkan bahwa Django baru menambahkan fitur seperti ini pada 2025
  • Saya terutama memakai Odoo, tapi juga sedikit pernah memakai Django dan Celery.
    Sebagai orang yang sering memakai modul OCA queue di Odoo,
    saya selalu penasaran kenapa Django tidak memanfaatkan fitur LISTEN/NOTIFY milik Postgres.
    Mungkin karena saya belum cukup akrab dengan ekosistem Django

  • Template Partials dan HTMX terasa seperti versi Django dari Rails View Components + Stimulus.
    Menyenangkan juga melihat fitur Tasks mendapat dukungan resmi

    • Render partial di Rails bisa dilihat di panduan resmi
    • Kalau ingin memakai Tasks di production, apakah tetap perlu memakai django-tasks juga?
  • Saya sudah memakai Django sejak era 1.x, dari masa ketika belum ada ORM.
    Cukup mengejutkan bahwa baru sekarang fitur eksekusi task ditambahkan.
    Bukan bermaksud mengkritik, hanya evolusi yang menarik

    • Justru terasa menyegarkan. Django tidak terburu-buru menambahkan fitur, tapi mengerjakannya dengan benar.
      Setiap fitur baru dimasukkan hanya setelah cukup teruji, dengan fokus pada LTS dan stabilitas API.
      Karena itu, saat versi baru keluar, hampir tidak pernah perlu menulis ulang seluruh aplikasi
    • Sebenarnya Django sudah menyertakan ORM sejak versi 0.95.
      Waktu itu memang masih sederhana, tapi sudah cukup lama tidak perlu memakai raw SQL
  • Diskusi tambahan berlanjut di thread ini

  • Saat memakai Django bersama HTMX, saya merasa template berbasis komponen terlalu tidak nyaman,
    jadi saya membuat sendiri library komponen berbasis Python bernama Compone.
    Ini bisa dipakai bukan hanya di Django tapi di semua framework web Python, dan memberi pengalaman pengembangan yang jauh lebih nyaman