Kerangka kerja tugas bawaan Django 6: kesan pertama saya setelah pengujian

Ketika saya pertama kali mendengar bahwa Django 6 mendapatkan kerangka kerja tugas asli, saya akui saya skeptis. Setelah bertahun-tahun bergulat dengan konfigurasi Celery, berurusan dengan pengaturan Redis/RabbitMQ, dan men-debug masalah pekerja misterius, janji sesuatu yang lebih sederhana terasa hampir terlalu bagus untuk menjadi kenyataan. Tetapi setelah menghabiskan seminggu terakhir menyelami kerangka kerja baru, saya mulai melihat di mana letaknya dalam ekosistem Django - dan di mana tidak.

Apa sebenarnya kerangka kerja tugas baru Django?

Kerangka kerja tugas baru, yang mendarat di rilis alfa Django 6.0, mewakili perubahan mendasar dalam cara Django menangani pekerjaan latar belakang. Untuk pertama kalinya, Django menyediakan cara bawaan untuk menentukan dan mengantrekan tugas yang perlu dijalankan di luar siklus permintaan-respons HTTP.

Konsepnya sangat sederhana. Berikut adalah pola dasar yang telah saya gunakan:

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

Setelah Anda menentukan tugas, mengantrekannya sangat mudah:

email_users.enqueue(
    emails=["[email protected]"],
    subject="You have a message",
    message="Hello there!",
)

Apa yang langsung membuat saya terkesan adalah betapa alaminya perasaan ini dibandingkan dengan menyiapkan Celery. Tidak perlu membuat aplikasi Celery terpisah, mengonfigurasi broker, atau mengelola pengaturan serialisasi yang kompleks. Ini berfungsi begitu saja - yah, begitulah.

Tangkapan: Anda masih membutuhkan pekerja

Di sinilah segalanya menjadi menarik (dan berpotensi mengecewakan bagi sebagian orang). Kerangka kerja tugas Django menangani pembuatan dan antrean tugas, tetapi dengan sengaja tidak menyediakan mekanisme pekerja. Ini berarti Anda masih membutuhkan infrastruktur eksternal untuk benar-benar menjalankan tugas Anda.

Kedua backend bawaan yang disertakan dalam rilis ini terutama ditujukan untuk pengembangan dan pengujian. Dalam produksi, Anda perlu menerapkan solusi pekerja Anda sendiri atau berintegrasi dengan sistem pemrosesan tugas yang ada. Keputusan desain ini masuk akal ketika Anda memikirkannya - Django tetap fokus untuk menjadi kerangka kerja web daripada mencoba menyelesaikan setiap masalah infrastruktur.

Membandingkannya dengan Celery: apel dan jeruk?

Pertanyaan yang diajukan semua orang adalah apakah ini dapat menggantikan Celery. Setelah menguji keduanya secara ekstensif, saya pikir jawabannya lebih bernuansa daripada sekadar ya atau tidak.

Celery tetap menjadi juara kelas berat untuk pemrosesan tugas terdistribusi yang kompleks. Ia menawarkan fitur-fitur seperti:

• Beberapa backend broker (Redis, RabbitMQ, dll.)
• Sistem perutean dan prioritas yang canggih
• Mekanisme coba lagi bawaan dengan backoff eksponensial
• Rantai tugas dan alur kerja
• Alat pemantauan komprehensif

Kerangka kerja tugas Django, di sisi lain, terasa lebih seperti fondasi daripada solusi lengkap. Ini sangat cocok untuk kasus penggunaan yang lebih sederhana di mana Anda ingin menurunkan pekerjaan dasar seperti mengirim email atau memproses unggahan tanpa overhead pengaturan Celery penuh.

"Untuk aplikasi kompleks seperti CMS atau sistem e-commerce, Celery tetap menjadi pilihan yang sempurna untuk tugas latar belakang. Mungkin konfigurasinya lebih kompleks daripada alternatif yang lebih sederhana, tetapi proyek Anda akan menjadi lebih kuat di masa mendatang."

Kutipan ini dari perbandingan baru-baru ini selaras dengan pengalaman saya. Untuk proyek pribadi saya dan pekerjaan klien yang lebih kecil, kerangka kerja tugas Django menjadi pilihan utama saya. Tetapi untuk aplikasi perusahaan dengan kebutuhan pemrosesan volume tinggi? Celery tidak akan pergi ke mana pun.

Pengaturan pengujian saya dan temuan awal

Saya telah menguji kerangka kerja dengan beberapa skenario umum:

Pemberitahuan email

Contoh email di atas telah bekerja dengan sempurna di lingkungan pengembangan saya. Backend langsung memproses tugas secara sinkron, yang sempurna untuk pengujian.

Pemrosesan data

Saya membuat tugas untuk pemrosesan CSV dan pembuatan laporan. Sintaks dekorator memudahkan untuk mengonversi fungsi yang ada:

@task
def process_user_data(user_id):
    # Heavy processing logic here
    pass

Pemeliharaan terjadwal

Sementara kerangka kerja Django tidak menyertakan penjadwalan seperti Celery Beat, saya telah bereksperimen dengan pekerjaan cron yang mengantrekan tugas pada interval tertentu.

Konfigurasi dan opsi backend

Konfigurasi terjadi melalui pengaturan TASKS di file pengaturan Django Anda. Kerangka kerja ini dirancang agar dapat diperluas, jadi saya berharap kita akan melihat backend yang dikembangkan komunitas untuk Redis, antrean database, dan layanan cloud seperti AWS SQS segera.

Apa yang saya hargai adalah fleksibilitas - Anda tidak terkunci dalam pilihan infrastruktur tertentu. Ini selaras dengan filosofi Django dalam menyediakan default yang masuk akal sambil memungkinkan penyesuaian.

Pengambilan praktis untuk pengembang Django

Setelah seminggu bereksperimen, berikut saran saya:

Kapan menggunakan tugas Django

• Pengiriman dan pemberitahuan email sederhana
• Pemrosesan dan unggahan file dasar
• Transformasi data ringan
• Lingkungan pengembangan dan pengujian
• Proyek di mana Anda ingin menghindari infrastruktur tambahan

Kapan tetap menggunakan Celery

• Pemrosesan tugas volume tinggi
• Alur kerja dan ketergantungan tugas yang kompleks
• Kebutuhan akan pemantauan tugas dan UI manajemen
• Pemrosesan terdistribusi di beberapa server
• Pekerjaan latar belakang penting yang membutuhkan pengiriman terjamin

Strategi migrasi

Jika Anda saat ini menggunakan Celery dan mempertimbangkan untuk beralih, saya sarankan untuk memulai dari yang kecil. Identifikasi tugas latar belakang Anda yang paling sederhana dan migrasikan yang pertama. Simpan Celery untuk alur kerja yang kompleks saat Anda mengevaluasi apakah kerangka kerja Django memenuhi kebutuhan Anda.

Melihat ke depan

Pengenalan kerangka kerja tugas asli di Django 6 terasa seperti evolusi alami. Ini mengisi celah bagi pengembang yang membutuhkan pemrosesan latar belakang dasar tanpa kompleksitas sistem antrean tugas penuh. Meskipun tidak akan menggantikan Celery untuk kasus penggunaan yang kompleks, ini adalah tambahan yang disambut baik yang akan menyederhanakan banyak proyek Django.

Saya sangat senang melihat apa yang dibangun komunitas di atas fondasi ini. Sistem backend yang dapat diperluas berarti kita kemungkinan akan melihat solusi inovatif yang menjembatani kesenjangan antara kesederhanaan Django dan kekuatan Celery.

Untuk saat ini, saya menikmati kesederhanaan menambahkan tugas latar belakang ke proyek Django saya tanpa sakit kepala konfigurasi yang biasa. Kadang-kadang, lebih sedikit benar-benar lebih banyak.