Hacker News Reader

Comment by shay_ker | Hacker News Reader

I'm excited about ActiveJob because, finally, people will be able to build background jobs on things that aren't Redis. No hate on Redis - I'm a huge fan of it - but sometimes you have stronger consistency reqs that Redis does not have, and stronger availability reqs that SQS or PG don't have (aka multi-region jobs).

If the concurrency in ActiveJob become as good or better than Sidekiq, we can really get a lot of interesting stuff out there.

View on HN

I used Que [0] in a number of projects in the last few years that had stronger consistency demands. It can plug into ActiveJob. Those projects are still humming along without trouble today.

[0]: https://github.com/que-rb/que

As a fellow Que user, I'm happy to see this line in the README:

> For example, GoodJob is currently ~600 lines of code, whereas Que is ~1,200 lines,

I've tried to dig into the Que internals before (looking into deadlocks) and they were gnarly; skimming through the GoodJob internals, it looks a lot more like what I'd hope for.

Unfortunately its no longer maintained and his 2.0 branch is completely broken for me. I've been very stressed trying to find a que replacement, as almost all of my needs for job need ACID guarantees, and Sidekiq/Redis "best effort" is nowhere near what I need. I also refuse to pay $xxxx for Sidekiq pro just to get those guarantees.

Good job looks pretty awesome, I'll have to give it a shot at some point.

Sk pro is really not that much?

Que also has a Golang port [1], which can be a tool to get towards The Citadel [2] for performance or dependency-heavy jobs without going full SOA

[1] https://github.com/bgentry/que-go

[2] https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Reply on news.ycombinator.com