Should we continue to use Sidekiq as our preferred queuing backend? #1298
Replies: 6 comments
-
|
If we're not ready to use Solid Queue in favor of Sidekiq, we should skip it with |
Beta Was this translation helpful? Give feedback.
-
|
Another thing to consider is hosting. If we don't call |
Beta Was this translation helpful? Give feedback.
-
|
I haven't tried solid queue yet. Does anyone have some pros/cons on it versus sidekiq? |
Beta Was this translation helpful? Give feedback.
-
Pros
Cons
|
Beta Was this translation helpful? Give feedback.
-
|
I've used solid queue and think it's at a point where it can be used in production without issue. That said, it's really hard to beat the total volume of resources, gems, and documentation that exist in the sidekiq ecosystem. So while I'd normally really want to stick to whatever rails defaults to, I'd still pick sidekiq if it were up to me. Either way I think this highlights the value of sticking to the ActiveJob interface. That way, the pathway to switching adapters in the future doesn't have quite so many barriers. |
Beta Was this translation helpful? Give feedback.
-
|
Noting that as of the latest release: We skip the Solid ecosystem since we prefer Sidekiq, and because Solid Queue has rails/solid_queue#330 on Heroku. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The upcoming release of Rails 8 is slated to use Solid Queue as the default queuing backend.
We currently default to Sidekiq.
Should we continue to use Sidekiq as our preferred queuing backend, or, should we use the new Rails default?
Beta Was this translation helpful? Give feedback.
All reactions