Recently we have upgraded one of our own projects to Rails 4.2. New minor version contains many improvements of old features and adds some new ones. One of most interesting (and helpful) new features is adding a new framework for declaring jobs and making them run on a variety of queuing backends — Active Job.
It is hard to imagine any big and complex Rails project without background jobs processing. There are many gems for this task: Delayed Job, Sidekiq, Resque, SuckerPunch and more. And Active Job has arrived here to rule them all.
Active Job provides unified interface to hide real background jobs library from our eyes and to simplify migration from one background jobs processing library to another. Also it is cool that Active Job provides a generator to create jobs. I really don’t like to write almost the same code over and over again and a good tool should take all routine work upon itself.
That looks cool and useful. So it’s time to use Active Job in our project.
Move Delayed Job to Backend
We already use Delayed Job in a project. So, first of all, we should tell Active Job which backend it should use.
We should create initializer for active jobs in the config/initializers folder:
We will take as example one of our workers (we used “worker” term for classes which we use in a background):
And this is the way how we used it:
Let’s rewrite it for Active Job. We use generator for create new jobs:
We can see that generator creates a test file for us too and this is a good reminder for you to write tests for a job. Before committing changes you will need to choose between deleting a file (we don’t leave empty files in projects) or writing some tests.
Let’s see what a generator has created.
It has created a new class which is descendant of ActiveJob::Base with name ending with Job. Also it is set to use a default queue (can be changed by --queue another_queue generator’s option but simple replacing this in code is much quicker).
It is left to change #perform method in the created job:
And replace old calls SendNewFeedbackNotificationWorker.new(arguments).delay.perform to new calls SendNewFeedbackNotificationJob.perform_later(arguments).
Enqueue a job with options
You can change a queue and time for running a job by #set method on job. It can accept these options:
:wait- enqueues the job with the specified delay;:wait_until- enqueues the job at the time specified (override:waitif both specified;:queue- enqueues the job on the specified queue.
Examples:
Note: you can check available features for your backend of choice in Rails documentation.
Pass models instances to your jobs
It is a common recommendation to pass models ids instead of models instances to background jobs. Because in this case we already know that model will have the latest saved state when a job will start processing it and this prevents possible issues in serializing and deserializing.
And Global ID was created to simplify jobs. Because using Global ID allows you to pass models to jobs without fear and with less code.
We can rewrite our job using models instead of ids.
And use it in the following way:
All the magic is done by Active Job and Active Record using Global ID.
Active Job serializes arguments which you pass to perform_later. And it has a special case for models which mixin GlobalID::Identification module. In this case Active Job serializer calls .to_global_id.to_s on the model and passes returned string to queue adapter instead of a model.
Before performing job Active Job deserializer detects Global ID identifier, finds a model using GlobalID::Locator.locate and passes the found model as an argument to job’s #perform method.
Testing of Jobs
Active Job also contains a useful module ActiveJob::TestHelper. When we include this module to our test class it overwrites before_setup and after_teardown methods.
In before_setup it sets Active Job to use a test queue adapter instead of the original one and clears lists of enqueued and performed jobs in this adapter. And it restores original adapter in the after_teardown to not interfere on next tests.
Also this module provides several useful methods which allow us to verify that our jobs are working properly.
Let`s assume that we create a job for sending notification to user in the controller:
Then we can use these helpers to check that this action works right.
assert_enqueued_jobs(number) - checks that exact number of jobs were added to queue:
assert_enqueued_with(args) - checks that block enqueues job with given arguments:
perform_enqueued_jobs - performs jobs created in the passed block instead of queuing them:
What we have done
So let’s have a look once again on how we have changed the code.
Worker before:
Job after:
Enqueueing worker before:
Enqueuing job after:
Looks like our jobs became much cleaner with Active Job.
And a small notice about deploying these changes to production. We should not delete previous SendNewFeedbackNotificationWorker class right now. Because during deploy it may happen that previously used worker was delayed but has not been processed before the deploy. And after deploy this job fails because DelayedJob couldn’t create instance of already deleted class. Adding and deleting of a job shouldn’t be done in single deploy.
Paul Keen is a Chief Technology Officer at JetThoughts. Follow him on LinkedIn or GitHub.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories.
