# django-tasks - bringing background workers in to Django core **URL:** \ **Category:** Show & Tell\ **Created:** [July 14, 2024, 5:37pm UTC](https://forum.djangoproject.com/t/django-tasks-bringing-background-workers-in-to-django-core/32967 "2024-07-14T17:37:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![theorangeone](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/theorangeone/32/21264_2.png) [@theorangeone](https://forum.djangoproject.com/u/theorangeone)\ **Post date:** [July 14, 2024, 5:37pm UTC](https://forum.djangoproject.com/t/django-tasks-bringing-background-workers-in-to-django-core/32967/1 "2024-07-14T17:37:45Z")
[`django-tasks`](https://github.com/realOrangeOne/django-tasks) is an [accepted Enhancement Proposal](https://github.com/django/deps/blob/main/accepted/0014-background-workers.rst) to bring background workers into Django itself (as `django.tasks`). Introducing both a common API contract for developers and library authors (eg `django.core.cache`), but also a production-grade ORM-based worker and queue. I gave a talk at Djangocon Europe last month introducing it: [![](https://us1.discourse-cdn.com/flex026/uploads/djangoproject/original/3X/7/1/71fa18533d31703db0d2221f3df5a21c88439370.jpeg "DjangoCon Europe 2024 | Empowering Django with Background Workers") ](https://www.youtube.com/watch?v=RxcRBNqxjeY) Now, I need your help testing it, finding the issues, and adding features. The aim is to get it merged into Django 5.2 (April 2025, but the merge deadline is December 2024), and there’s a lot still to do between now and then. Give it a try, see how it works, and let me know what you think! ---
**Author:** ![oldtechaa](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/oldtechaa/32/23072_2.png) [@oldtechaa](https://forum.djangoproject.com/u/oldtechaa)\ **Post date:** [August 6, 2024, 4:30am UTC](https://forum.djangoproject.com/t/django-tasks-bringing-background-workers-in-to-django-core/32967/2 "2024-08-06T04:30:36Z")
Hello! I saw your video and decided to come here to ask about it. Are you looking to eventually be able to interface with Celery or similar worker providers like RQ using the consistent django-tasks (or similarly named) API? I wasn’t exactly sure from the video whether that’s the ultimate goal is to interface with the existing systems or to simply replace most use-cases with a DB-backed system. ---
**Author:** ![theorangeone](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/theorangeone/32/21264_2.png) [@theorangeone](https://forum.djangoproject.com/u/theorangeone)\ **Post date:** [August 6, 2024, 8:58am UTC](https://forum.djangoproject.com/t/django-tasks-bringing-background-workers-in-to-django-core/32967/3 "2024-08-06T08:58:55Z")
I’d like interops between existing implementations, yes. When and who writes them is still TBC. There’s a Celery backend [in progress](https://github.com/RealOrangeOne/django-tasks/pull/64). These will absolutely be in Django core, as it’s too much maintenance burden. The DB backend will definitely be in Django core. Redis might come later to core, but that’s not my decision to make. `django-tasks` will likely live on to contain the components which don’t make sense in Django core, and as a testing ground before integrating. ---
**Author:** ![theorangeone](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/theorangeone/32/21264_2.png) [@theorangeone](https://forum.djangoproject.com/u/theorangeone)\ **Post date:** [October 11, 2024, 7:59am UTC](https://forum.djangoproject.com/t/django-tasks-bringing-background-workers-in-to-django-core/32967/4 "2024-10-11T07:59:28Z")
The first PR, implementing the core API for background workers is up for review 🎉 ! > > > \#### Trac ticket number > > N/A - https://github.com/django/deps/blob/main/accept…ed/0014-background-workers.rst > > \#### Branch description > > This PR implements the first parts of \`django.tasks\`, as implemented in \[\`django-tasks\`\](https://github.com/realOrangeOne/django-tasks): > > \- Common API interface > \- Base backend > \- Task / result classes > \- Immediate / Dummy backends > > The database backend is intentionally absent, and will be added in future (\*\*after\*\* this PR is merged). This makes the PR significantly smaller, and easier to review. > > The commits are also not squashed, to assist with iterative reviewing. I'll squash them all towards the end once the change is approved. > > \##### To do > > \- Documentation > > \##### Notable deviations from the DEP > > \- The email backend has been removed, as it isn't possible to be API-compatible, due to the need to return the number of successfully-sent emails. > \- Enqueue and finished task signals were added, to allow easier introspection from day 1. > > \#### Checklist > \- \[x\] This PR targets the \`main\` branch. > \- \[x\] The commit message is written in past tense, mentions the ticket number, and ends with a period. > \- \[\] I have checked the "Has patch" ticket flag in the Trac system. > \- \[x\] I have added or updated relevant tests. > \- \[\] I have added or updated relevant docs, including release notes if applicable (TBC). > \- \[\] I have attached screenshots in both light and dark modes for any UI changes. The notable omission is the database worker. This exists in `django-tasks`, but in the interest of easier review, isn’t in the first PR. It’ll come later, once the core is merged. Any and all review appreciated! ---
**Author:** ![AlexTo](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/alexto/32/27808_2.png) [@AlexTo](https://forum.djangoproject.com/u/AlexTo)\ **Post date:** [March 29, 2025, 5:03am UTC](https://forum.djangoproject.com/t/django-tasks-bringing-background-workers-in-to-django-core/32967/5 "2025-03-29T05:03:19Z")
thank you very much for the great work. Meanwhile, when the ticket is not yet merged, my question is, can I start using django-tasks as a separate module and later remove django-tasks when it is available as part of the Django’s core without any code changes? Cheers, Alex ---
**Author:** ![theorangeone](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/theorangeone/32/21264_2.png) [@theorangeone](https://forum.djangoproject.com/u/theorangeone)\ **Post date:** [March 31, 2025, 8:00am UTC](https://forum.djangoproject.com/t/django-tasks-bringing-background-workers-in-to-django-core/32967/6 "2025-03-31T08:00:55Z")
“without any code changes” is a very strong phrase. No, you can’t do it without _any_, but it should be minimal at best. As an application developer, it should be a case of swapping out the task backend in `TASKS`, and changing where you import the `task` decorator from. Everything else should “just work” ™ Exactly how a project will behave with both installed, I don’t know. In theory the APIs are the same, so assuming they have the same backend, each package’s `task` decorator shouldn’t conflict.