5 ms·

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

byroot 12y ago
It just has nothing to do with cron. Cron is a POSIX task scheduler, this is a Ruby normalized API for background job systems.
patio11 12y ago
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.)
- jhuckestein 12y ago
  I'm pretty sure ActiveJob is just a standardized interface to delayed job, resque, sidekiq etc. If you ever wanted to upgrade form delayed job, this could come in handy for you.
- igravious 12y ago
  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 12y ago
    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.
djkz 12y ago
To give an example let's say you have a mailing list with 1000 people and you want to send out notification. You push "notify " button, but you don't want to wait for your app to go through 1000 people and send them email until it responds again. You also don't want to wait until midnight for crontab to start processing all requests. Background jobs takes that 1000 deliveries job and puts it into the background queue, then a worker starts sending those emails right away. Meanwhile your app returns from your request instantly so you can continue doing what you were doing while the job is executed in the background.
netghost 12y ago
Just to pile on to the answers. Cron is for scheduling work, delayed jobs are for out of band work. For instance: * Use cron to dump a database backup nightly * Use some job system to send a user an email after they sign up There's a lot of overlap, and if used cleverly (which may not be smart), they can both achieve the same goals.
rmchugh 12y ago
Another thing to bear in mind is that cron won't have access to your Rails environment per default. If for example you used cron to call a rake script which needed the Rails environment, you would be loading the Rails env every time, which is pretty heavy.

It just has nothing to do with cron. Cron is a POSIX task scheduler, this is a Ruby normalized API for background job systems.

patio11 12y ago

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.)

jhuckestein 12y ago
I'm pretty sure ActiveJob is just a standardized interface to delayed job, resque, sidekiq etc. If you ever wanted to upgrade form delayed job, this could come in handy for you.
igravious 12y ago
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 12y ago
  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.

djkz 12y ago

To give an example let's say you have a mailing list with 1000 people and you want to send out notification. You push "notify " button, but you don't want to wait for your app to go through 1000 people and send them email until it responds again. You also don't want to wait until midnight for crontab to start processing all requests. Background jobs takes that 1000 deliveries job and puts it into the background queue, then a worker starts sending those emails right away. Meanwhile your app returns from your request instantly so you can continue doing what you were doing while the job is executed in the background.

netghost 12y ago

Just to pile on to the answers. Cron is for scheduling work, delayed jobs are for out of band work. For instance: * Use cron to dump a database backup nightly * Use some job system to send a user an email after they sign up There's a lot of overlap, and if used cleverly (which may not be smart), they can both achieve the same goals.

rmchugh 12y ago

Another thing to bear in mind is that cron won't have access to your Rails environment per default. If for example you used cron to call a rake script which needed the Rails environment, you would be loading the Rails env every time, which is pretty heavy.