إطار عمل المهام المدمج في Django 6: انطباعاتي الأولى بعد الاختبار

عندما سمعت لأول مرة أن Django 6 سيحصل على إطار عمل مهام أصلي، أعترف أنني كنت متشككًا. بعد سنوات من الصراع مع تكوينات Celery، والتعامل مع إعدادات Redis/RabbitMQ، وتصحيح مشكلات العامل الغامضة، بدا وعد شيء أبسط جيدًا لدرجة يصعب تصديقها. ولكن بعد قضاء الأسبوع الماضي في الغوص في الإطار الجديد، بدأت أرى أين يتناسب في نظام Django البيئي - وأين لا يتناسب.

ما هو بالضبط إطار عمل المهام الجديد في Django؟

يمثل إطار عمل المهام الجديد، الذي وصل في الإصدار الأولي من Django 6.0، تحولًا جذريًا في كيفية تعامل Django مع العمل في الخلفية. لأول مرة، يوفر Django طريقة مدمجة لتحديد ووضع المهام في قائمة الانتظار التي تحتاج إلى التشغيل خارج دورة طلب واستجابة HTTP.

المفهوم بسيط بشكل جميل. إليك النمط الأساسي الذي استخدمته:

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)

بمجرد تحديد مهمة، يصبح وضعها في قائمة الانتظار أمرًا مباشرًا:

email_users.enqueue(
    emails=["[email protected]"],
    subject="لديك رسالة",
    message="مرحبا بك!",
)

ما أثار إعجابي على الفور هو مدى طبيعية هذا الشعور مقارنة بإعداد Celery. ليست هناك حاجة لإنشاء تطبيق Celery منفصل، أو تكوين وسطاء، أو إدارة إعدادات تسلسل معقدة. إنه يعمل ببساطة - حسنًا، نوعًا ما.

المشكلة: ما زلت بحاجة إلى عمال

هنا تصبح الأمور مثيرة للاهتمام (وربما مخيبة للآمال للبعض). يتعامل إطار عمل المهام في Django مع إنشاء المهام ووضعها في قائمة الانتظار، لكنه لا يوفر عمدًا آلية عامل. هذا يعني أنك لا تزال بحاجة إلى بنية تحتية خارجية لتنفيذ مهامك فعليًا.

تم تصميم الواجهتين الخلفيتين المدمجتين المضمنتين في هذا الإصدار بشكل أساسي للتطوير والاختبار. في الإنتاج، ستحتاج إلى تنفيذ حل العامل الخاص بك أو التكامل مع أنظمة معالجة المهام الموجودة. هذا القرار التصميمي منطقي عندما تفكر في الأمر - يظل Django يركز على كونه إطار عمل ويب بدلاً من محاولة حل كل مشكلة في البنية التحتية.

مقارنته بـ Celery: التفاح والبرتقال؟

السؤال الذي يطرحه الجميع هو ما إذا كان هذا يمكن أن يحل محل Celery. بعد اختبار كليهما على نطاق واسع، أعتقد أن الإجابة أكثر دقة من مجرد نعم أو لا.

تظل Celery هي البطل الثقيل لمعالجة المهام الموزعة المعقدة. يوفر ميزات مثل:

• واجهات خلفية متعددة للوسطاء (Redis، RabbitMQ، إلخ)
• أنظمة توجيه وأولوية متطورة
• آليات إعادة محاولة مدمجة مع التراجع الأسي
• تسلسل المهام وسير العمل
• أدوات مراقبة شاملة

من ناحية أخرى، يبدو إطار عمل المهام في Django أشبه بأساس بدلاً من حل كامل. إنه مثالي لحالات الاستخدام الأبسط حيث تريد تفريغ العمل الأساسي مثل إرسال رسائل البريد الإلكتروني أو معالجة عمليات التحميل دون إضافة عبء إعداد Celery كامل.

"بالنسبة للتطبيقات المعقدة مثل أنظمة إدارة المحتوى أو التجارة الإلكترونية، تظل Celery هي الخيار الأمثل للمهام الخلفية. ربما يكون التكوين أكثر تعقيدًا من البدائل الأبسط، لكن مشروعك سيصبح أكثر قوة في المستقبل."

هذا الاقتباس من مقارنة حديثة يتردد صداه مع تجربتي. بالنسبة لمشاريعي الشخصية وعمل العملاء الأصغر حجمًا، أصبح إطار عمل المهام في Django هو خياري المفضل. ولكن بالنسبة لتطبيقات المؤسسات التي لديها احتياجات معالجة عالية الحجم؟ لن تختفي Celery في أي مكان.

إعداد الاختبار الخاص بي والنتائج الأولية

لقد اختبرت الإطار مع بعض السيناريوهات الشائعة:

إشعارات البريد الإلكتروني

يعمل مثال البريد الإلكتروني أعلاه بشكل لا تشوبه شائبة في بيئة التطوير الخاصة بي. تعالج الواجهة الخلفية الفورية المهام بشكل متزامن، وهو أمر مثالي للاختبار.

معالجة البيانات

لقد أنشأت مهامًا لمعالجة CSV وإنشاء التقارير. يجعل بناء جملة المزخرف من السهل تحويل الوظائف الحالية:

@task
def process_user_data(user_id):
    # منطق معالجة ثقيل هنا
    pass

الصيانة المجدولة

في حين أن إطار عمل Django لا يتضمن جدولة مثل Celery Beat، فقد كنت أجرب مهام cron التي تضع المهام في قائمة الانتظار على فترات زمنية محددة.

خيارات التكوين والواجهة الخلفية

يحدث التكوين من خلال إعداد TASKS في ملف إعدادات Django الخاص بك. تم تصميم الإطار ليكون قابلاً للتوسيع، لذلك أتوقع أن نرى واجهات خلفية مطورة من قبل المجتمع لـ Redis وقوائم انتظار قواعد البيانات والخدمات السحابية مثل AWS SQS قريبًا.

ما أقدره هو المرونة - أنت لست مقيدًا بخيار بنية تحتية محدد. يتماشى هذا جيدًا مع فلسفة Django المتمثلة في توفير الإعدادات الافتراضية المعقولة مع السماح بالتخصيص.

الوجبات السريعة العملية لمطوري Django

بعد أسبوع من التجربة، إليك نصيحتي:

متى تستخدم مهام Django

• إرسال إشعارات ورسائل بريد إلكتروني بسيطة
• معالجة الملفات وعمليات التحميل الأساسية
• تحويلات البيانات الخفيفة
• بيئات التطوير والاختبار
• المشاريع التي تريد فيها تجنب بنية تحتية إضافية

متى تلتزم بـ Celery

• معالجة المهام ذات الحجم الكبير
• سير العمل المعقدة وتعتمد على المهام
• الحاجة إلى مراقبة المهام وواجهة إدارة المستخدم
• المعالجة الموزعة عبر خوادم متعددة
• وظائف الخلفية ذات المهام الحرجة التي تتطلب تسليمًا مضمونًا

استراتيجية الترحيل

إذا كنت تستخدم Celery حاليًا وتفكر في التبديل، أوصي بالبدء صغيرًا. حدد أبسط مهام الخلفية الخاصة بك وقم بترحيلها أولاً. احتفظ بـ Celery لسير العمل المعقدة أثناء تقييم ما إذا كان إطار عمل Django يلبي احتياجاتك.

نتطلع إلى المستقبل

يبدو إدخال إطار عمل مهام أصلي في Django 6 بمثابة تطور طبيعي. إنه يملأ فجوة للمطورين الذين يحتاجون إلى معالجة أساسية في الخلفية دون تعقيد نظام قائمة انتظار المهام الكاملة. على الرغم من أنها لن تحل محل Celery لحالات الاستخدام المعقدة، إلا أنها إضافة مرحب بها ستبسط العديد من مشاريع Django.

أنا متحمس بشكل خاص لرؤية ما يبنيه المجتمع فوق هذا الأساس. يعني نظام الواجهة الخلفية القابل للتوسيع أننا سنرى على الأرجح حلولاً مبتكرة تسد الفجوة بين بساطة Django وقوة Celery.

في الوقت الحالي، أنا أستمتع ببساطة إضافة مهام الخلفية إلى مشاريع Django الخاصة بي دون متاعب التكوين المعتادة. في بعض الأحيان، يكون الأقل هو الأكثر حقًا.