Table of contents
Simplicity
Delayed_job is easy to set up and use, especially for small to medium-sized projects. It integrates seamlessly with Rails applications and allows you to quickly configure and run background jobs without much overhead.
Database-backed
Since delayed_job relies on your existing database to store job information, it doesn't require additional infrastructure. This can be an advantage for teams with limited resources or those who prefer not to manage additional services.
Rails Integration
Delayed_job is well-integrated with Rails, making it a good choice for Rails applications. It supports ActiveRecord and provides Rails-specific features like hooks and logging.
Mature and Proven
Delayed_job has been around for a long time and is considered stable and reliable. It has a large user base and a wealth of community resources, including plugins and extensions.
Delayed Job is one of the earliest job processing libraries in the Rails ecosystem. It leverages Active Record to store jobs in the database. - Source: dev.to / 4 months ago
Let's look at an example using Delayed Job, a popular and easy-to-manage queueing backend for Active Job. Delayed Job provides a setting to enable queueing. By default, the setting is true and jobs are queued as per usual. However, if set to false, jobs run immediately. - Source: dev.to / 8 months ago
It is hard to imagine any big and complex Rails project without background jobs processing. There are many gems for this task: **Delayed Job, Sidekiq, Resque, SuckerPunch** and more. And Active Job has arrived here to rule them all. - Source: dev.to / 11 months ago
Obviously, that is not what I’ve expected from Delayed::Job workers. So I took the shovel and started digging into git history. Since the last release the only significant modification has been made in the internationalization. We’ve moved to I18n-active_record backend to grant the privilege to modify translations not only to developers but also to highly-educated mere mortals. - Source: dev.to / 11 months ago
So how do we trigger such a long-running process from a Rails request? The first option that comes to mind is a background job run by some of the queuing back-ends such as Sidekiq, Resque or DelayedJob, possibly governed by ActiveJob. While this would surely work, the problem with all these solutions is that they usually have a limited number of workers available on the server and we didn’t want to potentially... - Source: dev.to / about 3 years ago
Several gems support job queues and background processing in the Rails world — Delayed Job and Sidekiq being the two most popular ones. - Source: dev.to / about 3 years ago
Back in the day, before Sidekiq and such, we used Delayed Job https://github.com/collectiveidea/delayed_job. Source: over 3 years ago
There are a few of popular systems. A few need a database, such as Delayed::Job, while others prefer Redis, such as Resque and Sidekiq. - Source: dev.to / about 4 years ago
Do you know an article comparing delayed_job to other products?
Suggest a link to a post with product alternatives.
This is an informative page about delayed_job. You can review and discuss the product here. The primary details have not been verified within the last quarter, and they might be outdated. If you think we are missing something, please use the means on this page to comment or suggest changes. All reviews and comments are highly encouranged and appreciated as they help everyone in the community to make an informed choice. Please always be kind and objective when evaluating a product and sharing your opinion.
