3 ms·
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
by 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 agoI'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 agoI 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 agoThe 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.