Getting started with Active Job in Ruby on Rails

Feb 24, 2016

Table of contents:

1. Why do we need Active Job?
2. Creating a new Job
3. Queuing a Job
4. Configuring your Queue
5. Conclusion

Once you get past the basic request response cycle of building a web application, you begin to realise there are yet more things to consider.

For example, typically you might be required to crunch data, send email notifications, or pass data into third-party analytics systems.

None of these things should be executed during the normal request response cycle because you should aim to make this process as quick as possible.

So instead of kicking things off in the main process, we can push this work onto a queue so that is can be dealt with later.

Active Job is Ruby on Rails’ queue framework for creating, queueing, and running jobs.

In today’s tutorial we will be looking at getting started with Active Job in Ruby on Rails.

Why do we need Active Job?

So hopefully you understand why we need to queue certain types of work, but why do we need a special framework such as Active Job?

The problem arrises when it comes to choosing your queue infrastructure.

They are a couple of different choices (which I won’t get into today) when it comes to choosing your queue infrastructure.

But your choice of infrastructure should not dictate the code you write.

In much the same way that you use Active Record as an abstraction of the database, Active Job is an abstraction of the queue.

This means you can write your code using the Active Job API, and the choice of what queue you decide on using is simply an operational decision.

This makes it easy to switch providers without having to totally rewrite your application!

Creating a new Job

As with a lot of things in Ruby on Rails, there is a generator to create a new Job so you don’t have to concern yourself with writing the boilerplate or getting the filename correct:

bin/rails generate job add_user_to_mail_chimp
invoke test_unit
create test/jobs/add_user_to_mail_chimp_job_test.rb
create app/jobs/add_user_to_mail_chimp_job.rb

This will create a new file called add_user_to_mail_chimp_job under the jobs directory:

class AddUserToMailChimpJob < ActiveJob::Base
  queue_as :default

  def perform(*args)
    # Do something later
  end
end

Alternatively you can also specify a queue that the job should be run on:

bin/rails generate job add_user_to_mail_chimp -queue urgent

Queuing a Job

Once you have your Job ready to go, you can queue it from your application.

I find the majority of the time I simply want the Job to be dealt with at the first opportunity when the queue is not busy:

AddUserToMailChimpJob.perform_later(user)

However, sometimes you want to execute the Job at a given time:

AddUserToMailChimpJob.set(wait_until: DateTime.now.midnight).perform_later(user)

Or perhaps a period of time from now:

AddUserToMailChimpJob.set(wait: 1.day).perform_later(user)

Configuring your Queue

You now have everything set up to add Jobs to the Queue during the normal execution of your application

However, because we currently don’t have a Queue configured, Active Job will simply execute the job immediately.

You have a number of choices when it comes to choosing what Queue provider you want to use:

• Backburner
• Delayed Job
• Qu
• Que
• queue_classic
• Resque
• Sidekiq
• Sneakers
• Sucker Punch
• Active Job Inline

To start using a particular queue, you would simply add the gem to your GemFile and install it and then set your chosen queue in the application.rb file under the config directory:

module Culttt
  class Application < Rails::Application
    config.active_job.queue_adapter = :sidekiq
  end
end

Conclusion

If you are just getting started with building web applications, queues and background jobs can seem overwhelming.

There are a lot of things to think about when building a web application.

However, something as “relatively simple” as the on-boarding flow when a new user signs up, is likely going to trigger a lot of things you probably didn’t even think about to begin with.

The good thing is, Rails is built upon making things as easy as possible for you as a developer. Rails makes the hard decisions so you don’t have to.

Active Job is a good example of this in practice. Active Job is an abstraction over queues and background jobs so you can concentrate on what is important for your application and not worry about operational or infrastructure concerns that won’t make a big difference to your success or to your customers or users.