Future of first-party, first-generation, ActiveJob adapters?

I’m the author of GoodJob, a multithreaded, Postgres-backed, ActiveJob backend. GoodJob is designed solely for ActiveJob (“Second Generation”) and recently reached Version 1.0.

Rails currently ships with a number of first-party adapters for ActiveJob. And the documentation is very clear “We are not accepting pull requests for new adapters.”

This situation creates a challenge for new ActiveJob backends to have visibility, and also has the effect of encouraging developers to potentially choose an ActiveJob adapter that is not well-maintained or even compatible with the current version of Rails. The situation also may be a disincentive for developers to create new/better backends that have closer compatibility with ActiveJob and thus strengthen the ecosystem.

I don’t have many solutions, but I’m curious (and self-interested as GoodJob’s author) to shine more light on ActiveJob. To suggest a couple of ideas:

  • Have the docs reference RubyGems or link to an outside list of backends. Elevate that link above the 1st-party adapters.
  • Ship ActiveJob with a database-backed backend adapter. I modeled GoodJob on the AsyncAdapter and I think it would be fairly reasonable to extend.

What other thoughts do you have?

6 Likes