5 ms·
I've been using Sidekiq for years, rock solid and no complaints. However, this recent addition to the space seems to be gaining traction and appears to have an
by xiljin 5y ago
I've been using Sidekiq for years, rock solid and no complaints.
However, this recent addition to the space seems to be gaining traction and appears to have an excellent feature set -
https://github.com/bensheldon/good_job https://github.com/bensheldon/good_job
- Railsify 5y agorocket job is pretty solid too, has a lot of the pro sidekiq features for free https://rocketjob.io/ https://rocketjob.io/
- Lio 5y agoYeah I'm a big fan of Good Job too. As long as you stick to pure ActiveJob features it really shouldn't be too difficult to scale from in memory based queue to PostgresSQL backed Good Job and then to Redis backed Sidekiq if and only if you need to.
- stephenhuey 5y agoYes, I wanted a PG-based one and reached for Good Job on a new project since it was recently created and with Active Job in mind from the start. Check out the intro: https://island94.org/2020/07/introducing-goodjob-1-0 https://island94.org/2020/07/introducing-goodjob-1-0
- grk 5y agoThe problem with postgres-backed queues is they can't be used with connection pooling, so your workers are unnecessarily using up DB connections.
- waffle_maniac 5y agoI thought that was an ActiveRecord problem. We use MYSQL and have a lot of long-lived connections.
- grk 5y agoNot sure how it works with MySQL, but with postgres the most common pooling options use transactional mode, which doesn't support LISTEN/NOTIFY.
- waffle_maniac 5y agoWithout the pro version it's not reliable: > If a Sidekiq process crashes while processing a job, that job is lost. [0] We use Sidekiq Pro at work but I find it unfortunate that reliability is a pro feature. It's really hard to tell a product owner: Yeah, we might lose a few jobs once in a while. [0] https://sidekiq.org/products/pro.html https://sidekiq.org/products/pro.html
- deleted 5y ago[deleted]
- aaronbrethorst 5y agoSeems like a good reason to pay Mike.
- jdc0589 5y agoagree. its not a lot of money, or it didn't used to be last time I looked. If your org relies heavily on it just pay
- waffle_maniac 5y agoWe do pay for it. Perhaps you could address my point? Open source background job software that isn't reliable by default? That makes sense?
- aaronbrethorst 5y agoI just looked this up. It's $995/year, or approximately 4% of the fully loaded cost of an FTE software engineer at most companies. i.e. about 3 weeks of a developer's time.
- waffle_maniac 5y agoI understand paying extra for niche features. Isn't reliability a core feature of background job software?
- deleted 5y ago[deleted]