

ActiveJob – gem for defining background jobs in Rails - Gonzih
https://github.com/rails/activejob

======
rubiquity
Rails 4.x was originally supposed to come with a Queueing API, but it was
delayed/removed for reasons. It's nice to see this being picked back up and
implemented. There's a ton of fragmentation out there in terms of background
job libraries, there's also a lot of apps still using DelayedJob and others
that "can't" upgrade to something better such as Sidekiq due to the sheer
amount of work required. Standardizing on an API for this will help a lot and
enable easily moving to the Latest and Greatest™ queueing library.

------
callumjones
I like idea of standardising a way for jobs to be defined and then shipped off
to a background server. The adapter registration looks neat.

But by the looks of it the library bundles in the adapters to talk directly to
these worker frameworks (currently it only is Resque). Are we going to see an
active merging in of adapters or will at some point will the response be 'we
won't be allowing any more adapters to bundled'.

~~~
byroot
You don't really need the adapters to be bundled. The queue libraries can
easily bundle their adapters in their gem or in 3rd party gems like sidekiq-
rails etc

~~~
callumjones
Totally, I see that in the class variable. I'm just curious when this library
will blow out.

------
jayroh
I ran into this a few days ago when I was searching for a common background
job / queue interface:

[https://github.com/dwbutler/multi_worker](https://github.com/dwbutler/multi_worker)

Haven't tried it yet but looks promising.

------
timtas
Having recently migrated from Resque to Sidekiq, I can attest that this solves
a problem, albeit not terribly a big one. As with any abstraction,
implementation-specific features make leaks. So far, the README doesn't say
how I will control features like retries and queue weights, but maybe that's
coming soon.

------
dpeck
I don't really see the need for this. A unified interface could be nice, but
this will also limit the scope that background processors will operate in.
Besides that the amount of rails projects that need background jobs aren't
that large of a percentage comparatively.

I'd rather see some more interesting things going into core, such as
[https://github.com/kickstarter/rack-
attack](https://github.com/kickstarter/rack-attack), that should be used by
nearly every app.

------
kalleth
Sigh. This is like that timecop thing -- dumping _more_ stuff in core that
lives better as part of a gem.

Resque, DelayedJob, Sidekiq... All have their drawbacks/benefits. I know this
can just work as a 'wrapper', but in an agency environment, i've used queueing
on about 20% of sites.

Absolutely no reason to want to put this in core imo.

~~~
unfunco
It being included will have no performance overhead since it's only loaded if
it's used.

I'm personally for this idea, I've used DJ, Resque and Sidekiq, all in the
same project (increasing load), and in that order; It would have been much
nicer to have to only change the Gemfile when I made the switch.

Your comment, whilst a perfectly valid concern, reminds me of an article DHH
posted: [http://david.heinemeierhansson.com/2012/rails-is-
omakase.htm...](http://david.heinemeierhansson.com/2012/rails-is-omakase.html)

~~~
kalleth
Performance wasn't my concern at all.

Overcomplicating the rails 'core' is my concern. I'd much rather start from a
lightweight 'base' which solves most of the common cases and pull in extras as
required for what i'm working on.

Rails should be a framework that allows you to layer extra functionality ontop
of it.

~~~
_pius
_Overcomplicating the rails 'core' is my concern. I'd much rather start from a
lightweight 'base' which solves most of the common cases ..._

Background jobs _are_ a common case. How many web applications never send an
e-mail?

~~~
mackwic
He probably sends emails synchronously.

------
igravious
How does this differ from good ol' cron and friends? Could someone tell me?

~~~
patio11
Generally one runs defined cron jobs on a schedule set in advance. This allows
you to queue up arbitrary methods to fire at arbitrary times, generally "a
short while after this HTTP request has been dealt with."

This is an extraordinarily common pattern in web applications. My Rails apps
do it hundreds of thousands of times per day, often to avoid hitting an
external API during a request/response cycle. (I use Delayed::Job. This would
not be my #1 recommendation for this pattern in 2014. Take a look at Sidekiq,
Resque, or this new thing instead.)

~~~
igravious
I see, cron is absolute time events (every 5 minutes say or 2 minutes past the
hour or once a week) and Active Job standardizes an interface to queue events
relatively (5 minutes from this HTTP request, ten minutes from now). Is there
a way cron could be extended to handle the relative case?

~~~
tomblomfield
The main value of these systems is normally not "relative queuing" (although
that is sometimes done).

Often, there are certain activities you might want to do in a way that doesn't
block the request/response cycle, but still have them performed as soon as
possible. For example, a user buys a widget on your site - send a receipt
email. You don't want the "Thanks for buying" success page response to wait
for your servers to compose & send the email, so you offload the email to your
queue system.

