"That approach worked but it was never ideal. Background tasks are not an edge case. They are a fundamental part of almost every non-trivial web application. Leaving this unavoidable slice entirely to third-party tooling meant that every serious Django project had to make its own choices, each with its own trade-offs, infrastructure requirements, and failure modes. It's one more thing that makes Django complex to deploy."
"Django's task system only supports one-off execution. There is no notion of scheduling, recurrence, retries, persistence, or guarantees. There is no worker process and no production-ready backend. That limitation would be easier to accept if one-off tasks were the primary use case for background work, but they are not. In real applications, background work is usually time-based, repeatable, and failure-prone. Tasks need to run later, run again, or keep retrying until they succeed."
Background tasks have long been part of Django projects but were handled outside the framework. Django historically focused on the request/response cycle while sending emails, cleanups, and file processing used third-party tools like Celery, RQ, or cron. Outsourcing background work forced projects to choose different tooling, adding trade-offs, infrastructure requirements, and failure modes that increase deployment complexity. Django 6.0 introduces a first-party tasks framework that standardizes how background work is defined and provides execution hooks. The new framework supports only one-off execution and lacks scheduling, recurrence, retries, persistence, worker processes, and a production-ready backend, limiting usefulness for repeatable, time-based, failure-prone workloads.
Read at Loopwerk
Unable to calculate read time
Collection
[
|
...
]