Handle Workloads Asynchronously

00:00 Handle workloads asynchronously with Celery. You’ve successfully arranged the puzzle pieces necessary to run asynchronous tasks with Django, Redis, and Celery.

00:10 But at this point, you’ve not yet defined any task to pass on to Celery. The final step to integrate it with Django and offload work to Celery distributed task queue is to refactor the email sending functionality into a Celery task.

00:26 At the moment, your code defines the email sending functionality in send_email of feedback_form. In forms.py,

00:35 you define send_email in line 15. The method simulates an expensive operation that will freeze the app for 20 seconds with a call to sleep().

00:46 Then you compose the email that you’ll send with Django’s convenience send_mail, which was imported earlier in the file. You need to call send_email on a successful form submission, and that is set up in form_valid of views.py.

01:02 Here you can see the definition of form_valid, which FeedbackFormView automatically calls on a successful form submission. You can see where send_email is called.

01:13 Within it, the setup works, but because of the simulated expensive operation, it takes way too long before the app becomes responsive again and allows users to continue browsing.

01:25 It’s time to change that by letting Celery handle email sending on its own schedule.

01:31 For app auto-discover tasks the work has described, you need to define your Celery tasks in a separate tasks.py module inside of each app of the Django project.

01:42 In this example, you only have one app. Larger Django projects will likely have more apps. If you stick with the standard setup, then you’ll create a tasks.py file for each app and store the app Celery tasks.

01:54 In that file, create a new file called tasks.py in the feedback app. In this file, you’ll define a new function that will handle the email sending logic.

02:07 First, the necessary imports are created: sleep from the time module and Django send_mail.

02:17 Most of the code is similar to the previous send_email function, but two parameters are added as you won’t have access to the instance attribute that was used in the original version.

02:27 These two parameters are used in the call to Django send_mail function, which was imported earlier on.

02:38 Apart from these changes, the new function looks very similar to the previous one, and Celery is currently not involved, so it’s time to change that. To transform this function into a Celery task, all you need to do is decorate it with @shared_task, which you import from Celery.

03:02 After importing @shared_task from Celery and decorating send_feedback_email task with it. You are done with the necessary code changes in this file Handing a task to Celery revolves around Celery’s task class, and it’s easy to create tasks by adding decorators to your function definitions.

03:22 As your producer is a Django app, you’ll want to use the @shared_task decorator to set up a task which keeps your apps reusable. With these additions, you are done setting up an asynchronous task with Celery, you’ll only need to refactor where and how you call it in your web app code.

03:39 So that’s what you’ll be doing in the next section of the course.