เฟรมเวิร์กงานในตัวของ Django 6: ความประทับใจแรกของฉันหลังจากการทดสอบ

28 กันยายน 2568

เมื่อฉันได้ยินครั้งแรกว่า Django 6 จะได้รับเฟรมเวิร์กงานในตัว ฉันยอมรับว่าฉันสงสัย หลังจากหลายปีที่ต้องต่อสู้กับการกำหนดค่า Celery, การจัดการกับการตั้งค่า Redis/RabbitMQ และการแก้ไขปัญหา worker ลึกลับ คำสัญญาของสิ่งที่เรียบง่ายกว่านั้นรู้สึกดีเกินจริง แต่หลังจากใช้เวลาในสัปดาห์ที่ผ่านมาดำดิ่งลงไปในเฟรมเวิร์กใหม่ ฉันเริ่มเห็นว่ามันเหมาะสมกับระบบนิเวศของ Django ที่ใด และที่ใดที่ไม่เหมาะสม

เฟรมเวิร์กงานใหม่ของ Django คืออะไรกันแน่

เฟรมเวิร์กงานใหม่ ซึ่งเปิดตัวใน Django 6.0's alpha release แสดงถึงการเปลี่ยนแปลงพื้นฐานในวิธีที่ 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="You have a message",
    message="Hello there!",
)

สิ่งที่ทำให้ฉันประทับใจทันทีคือความรู้สึกที่เป็นธรรมชาติเมื่อเทียบกับการตั้งค่า Celery ไม่จำเป็นต้องสร้างแอป Celery แยกต่างหาก กำหนดค่า brokers หรือจัดการการตั้งค่า serialization ที่ซับซ้อน มันใช้งานได้เลย - อืม ก็ประมาณนั้น

ข้อแม้: คุณยังคงต้องการ workers

นี่คือจุดที่สิ่งต่างๆ น่าสนใจ (และอาจทำให้บางคนผิดหวัง) เฟรมเวิร์กงานของ Django จัดการการสร้างและการจัดคิวงาน แต่จงใจไม่จัดหากลไก worker ซึ่งหมายความว่าคุณยังคงต้องการโครงสร้างพื้นฐานภายนอกเพื่อดำเนินการงานของคุณจริง

backends ในตัวสองตัวที่รวมอยู่ในรุ่นนี้มีวัตถุประสงค์หลักเพื่อการพัฒนาและการทดสอบ ในการใช้งานจริง คุณจะต้องใช้โซลูชัน worker ของคุณเองหรือผสานรวมกับระบบประมวลผลงานที่มีอยู่ การตัดสินใจออกแบบนี้สมเหตุสมผลเมื่อคุณคิดถึงมัน - Django ยังคงมุ่งเน้นไปที่การเป็น web framework แทนที่จะพยายามแก้ปัญหาโครงสร้างพื้นฐานทุกอย่าง

การเปรียบเทียบกับ Celery: แอปเปิ้ลกับส้ม?

คำถามที่ทุกคนถามคือสิ่งนี้สามารถแทนที่ Celery ได้หรือไม่ หลังจากทดสอบทั้งสองอย่างละเอียดแล้ว ฉันคิดว่าคำตอบนั้นซับซ้อนกว่าแค่ใช่หรือไม่ใช่

Celery ยังคงเป็นแชมป์รุ่นเฮฟวี่เวท สำหรับการประมวลผลงานแบบกระจายที่ซับซ้อน มีคุณสมบัติเช่น:

Multiple broker backends (Redis, RabbitMQ, etc.)
ระบบ routing และ priority ที่ซับซ้อน
กลไก retry ในตัวพร้อม exponential backoff
Task chaining และ workflows
เครื่องมือ monitoring ที่ครอบคลุม

เฟรมเวิร์กงานของ Django ในทางกลับกัน ให้ความรู้สึกเหมือนเป็นรากฐานมากกว่าโซลูชันที่สมบูรณ์แบบ เหมาะอย่างยิ่งสำหรับ use cases ที่เรียบง่ายกว่าที่คุณต้องการถ่ายโอนงานพื้นฐาน เช่น การส่งอีเมลหรือการประมวลผล uploads โดยไม่มีค่าใช้จ่ายในการตั้งค่า Celery แบบเต็ม

"สำหรับแอปพลิเคชันที่ซับซ้อน เช่น CMS หรือระบบ e-commerce Celery ยังคงเป็นตัวเลือกที่สมบูรณ์แบบสำหรับงานเบื้องหลัง บางทีการกำหนดค่าอาจซับซ้อนกว่าทางเลือกที่เรียบง่ายกว่า แต่โปรเจ็กต์ของคุณจะมีประสิทธิภาพมากขึ้นในอนาคต"

คำพูดนี้จาก การเปรียบเทียบล่าสุด สอดคล้องกับประสบการณ์ของฉัน สำหรับโปรเจ็กต์ส่วนตัวของฉันและงานลูกค้าขนาดเล็ก เฟรมเวิร์กงานของ Django กำลังกลายเป็นตัวเลือกแรกของฉัน แต่สำหรับแอปพลิเคชันระดับองค์กรที่มีความต้องการในการประมวลผลปริมาณมาก Celery จะไม่หายไปไหน

การตั้งค่าการทดสอบและผลการวิจัยเบื้องต้นของฉัน

ฉันได้ทดสอบเฟรมเวิร์กกับสถานการณ์ทั่วไปบางอย่าง:

การแจ้งเตือนทางอีเมล

ตัวอย่างอีเมลข้างต้นทำงานได้อย่างไม่มีที่ติในสภาพแวดล้อมการพัฒนาของฉัน backend ทันทีประมวลผลงานพร้อมกัน ซึ่งเหมาะสำหรับการทดสอบ

การประมวลผลข้อมูล

ฉันสร้างงานสำหรับการประมวลผล CSV และการสร้างรายงาน ไวยากรณ์ decorator ทำให้ง่ายต่อการแปลงฟังก์ชันที่มีอยู่:

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

การบำรุงรักษาตามกำหนดเวลา

ในขณะที่เฟรมเวิร์กของ Django ไม่รวมการจัดตารางเวลาเหมือน Celery Beat ฉันได้ทดลองกับ cron jobs ที่จัดคิวงานในช่วงเวลาที่กำหนด

การกำหนดค่าและตัวเลือก backend

การกำหนดค่าเกิดขึ้นผ่านการตั้งค่า TASKS ในไฟล์การตั้งค่า Django ของคุณ เฟรมเวิร์กได้รับการออกแบบมาให้ขยายได้ ดังนั้นฉันคาดว่าเราจะได้เห็น backends ที่พัฒนาโดยชุมชนสำหรับ Redis, database queues และ cloud services เช่น AWS SQS ในเร็วๆ นี้

สิ่งที่ฉันชื่นชมคือความยืดหยุ่น - คุณไม่ได้ถูกล็อกไว้ในตัวเลือกโครงสร้างพื้นฐานที่เฉพาะเจาะจง สิ่งนี้สอดคล้องกับปรัชญาของ Django ในการให้ค่าเริ่มต้นที่สมเหตุสมผลในขณะที่อนุญาตให้ปรับแต่งได้

บทสรุปเชิงปฏิบัติสำหรับนักพัฒนา Django

หลังจากสัปดาห์แห่งการทดลอง นี่คือคำแนะนำของฉัน:

เมื่อใดควรใช้ Django tasks

การส่งอีเมลและการแจ้งเตือนอย่างง่าย
การประมวลผลไฟล์และการอัปโหลดพื้นฐาน
การแปลงข้อมูลที่มีน้ำหนักเบา
สภาพแวดล้อมการพัฒนาและการทดสอบ
โปรเจ็กต์ที่คุณต้องการหลีกเลี่ยงโครงสร้างพื้นฐานเพิ่มเติม

เมื่อใดควรใช้ Celery ต่อไป

การประมวลผลงานปริมาณมาก
Workflows ที่ซับซ้อนและการพึ่งพากันของงาน
ความต้องการสำหรับการ monitoring งานและ UI การจัดการ
การประมวลผลแบบกระจายในหลายเซิร์ฟเวอร์
งานเบื้องหลังที่สำคัญต่อภารกิจที่ต้องการการจัดส่งที่รับประกัน

กลยุทธ์การย้ายข้อมูล

หากคุณกำลังใช้ Celery อยู่ในปัจจุบันและกำลังพิจารณาที่จะเปลี่ยน ฉันขอแนะนำให้เริ่มต้นเล็กๆ ระบุงานเบื้องหลังที่ง่ายที่สุดของคุณและย้ายข้อมูลเหล่านั้นก่อน ใช้ Celery ต่อไปสำหรับ workflows ที่ซับซ้อนในขณะที่คุณประเมินว่าเฟรมเวิร์กของ Django ตอบสนองความต้องการของคุณหรือไม่

มองไปข้างหน้า

การแนะนำเฟรมเวิร์กงานในตัวใน Django 6 ให้ความรู้สึกเหมือนเป็นการพัฒนาตามธรรมชาติ เติมเต็มช่องว่างสำหรับนักพัฒนาที่ต้องการการประมวลผลเบื้องหลังขั้นพื้นฐานโดยไม่มีความซับซ้อนของระบบ task queue เต็มรูปแบบ ในขณะที่มันจะไม่แทนที่ Celery สำหรับ use cases ที่ซับซ้อน มันเป็นการเพิ่มที่น่ายินดีที่จะทำให้โปรเจ็กต์ Django หลายโครงการง่ายขึ้น

ฉันรู้สึกตื่นเต้นเป็นพิเศษที่จะได้เห็นสิ่งที่ชุมชนสร้างขึ้นบนรากฐานนี้ ระบบ backend ที่ขยายได้หมายความว่าเราน่าจะได้เห็นโซลูชันที่เป็นนวัตกรรมที่เชื่อมช่องว่างระหว่างความเรียบง่ายของ Django และพลังของ Celery

ตอนนี้ ฉันกำลังเพลิดเพลินกับความเรียบง่ายของการเพิ่มงานเบื้องหลังให้กับโปรเจ็กต์ Django ของฉันโดยไม่ต้องปวดหัวกับการกำหนดค่าตามปกติ บางครั้ง น้อยกว่าก็คือมากกว่า...