Rails 4.2 Overview, Part 1 of 2

A new version of Rails is right around the corner, so I wanted to take this opportunity to cover three of the five biggest features in Rails 4.2.

We’ll cover the others, plus some miscellaneous items in the second installment of our Rails 4.2 overview.

1. Active Job

DHH called ActiveJob the “headline feature” of 4.2. What is ActiveJob? ActiveJob is a common adapter framework for many of the popular background job frameworks for Rails.

Right now, changing job queues or using different queue frameworks in different environments involves substantial code rewrites. The purpose of this adapter framework is that you can use a common API for background jobs, regardless of the job backend you use. Swapping out different job queue frameworks will be only require changing a setting. Think of it like ActiveRecord. With ActiveRecord, you write to one common set of methods to access the database, regardless of which database backend you choose. Later, if you need to change databases, you simply update your configuration. Active Job will provide similar swapability for job backends.

Here’s an example job, which checks the poke API, which is just too slow to check in the foreground:

Currently, ActiveJob has adapters for nine major background job systems:

2. Deliver Later

Deliver later is closely related to ActiveJob. The most common use of background job queues in Rails applications is to send email in the background, since mailers are generally very slow compared to web transactions.

#deliver_later is a new method on ActionMailers that will deliver mail using the configured ActiveJob queue. Background mailing has never been easier.

3. GlobalID

GlobalID is a system for giving every model instance an ID which is unique across all model classes. It differs from the existing primary key because in addition to the primary key, the global ID field also includes application and model class identifiers. This means you can use one field to uniquely identify any object in your application (or applications), regardless of the model class.

For example, if my rails application is called foo, and I have two model classes, Bar and Baz, I can use the global ID like so:

ActiveJob makes use of GlobalID as an easy way to serialize and deserialize models for background jobs. For example, you can do this with deliver_later:


ActiveJob will automatically convert my_bar to a global id when creating the job and then automatically retrieve my_bar when the task runs.

Part 2 of our overview of Rails 4.2.

Part 2 will cover Web Console, AdequateRecord, and more.

Special Thanks

Thanks to hansondr for catching an error in the global ID example. Thanks for Abdelkader Boudih for pointing out an update to the global ID API. We’ve updated the example code to correct both of these issues.