Should GoodJob extend ActiveJob::Base by default?

[bensheldon]

To date, I've been opinionated about not extending/polluting ActiveJob::Base by default, and instead:

• Asking developers to add GoodJob extensions manually for specific functionality
• Adding interface to GoodJob itself that wraps and interacts with the ActiveJob system (usually by storing some state in Thread local variables)

I'm seeing a few features in the future, like Batches and Bulk Enqueuing as well as feature requests like disabling NOTIFY on enqueue, that would be much easier to implement if GoodJob did reach into ActiveJob::Base by default. And by extend, I mainly mean:

• Adding additional configuration options to ActiveJob::Base#set that GoodJob would serialize/deserialize.
• Adding class methods, like good_job_control_concurrency_with, that extend job behavior in specific ways

I currently like making strong distinctions between "this is ActiveJob behavior" and "this is GoodJob behavior", but as GoodJob becomes more complex, holding those strongly itself becomes a source of complexity both for me as an implementer, and also (I think!) for trying to explain/document it for developers to use.

[gap777]

My vote is to combine. I realize that you've put great effort into designing a system whereby "this is ActiveJob behavior" and "this is GoodJob behavior", but as a client /user of AJ/GJ, I really don't want to know the difference... I want to just use as standard a mechanism as possible.