7 ms·
GoodJob author here. The core reason I wrote it was to see how lean/simple I could write a database-backed ActiveJob adapter today. And hope In practice any a
by sideofbacon 6y ago
GoodJob author here.
The core reason I wrote it was to see how lean/simple I could write a database-backed ActiveJob adapter today. And hope
In practice any adapter should _just work_, but also all the other adapters pre-date ActiveJob (Rails 4.2) and Concurrent::Ruby (adopted in Rails 5.0 I think). The assumption is that building GoodJob on top of what already exists in Rails today, it can be performant (enough) and simple (easy to understand, maintain, keep compatible with new versions of Rails, etc). That's not a big claim, but maybe it's compelling.
- rubyn00bie 6y agoAwesome! Thank you so much for the reasoning behind it. I haven't had a chance to look at Concurrent::Ruby but that _sounds_ like a pretty good reason all by itself! As a big plus for a lot of folks who don't need absurd throughput, this makes for one less dependency by using the same db you already have. I'd be sold given the right use-case, thanks for sharing this, mate and _good job!_ ;)
- sideofbacon 6y agoYay!