This is neat, but I feel like it takes away too much flexibility. Job classes can be customized to use certain queues, rescue/retry/discard on specific errors, and can be extended quickly when necessary. I can see this being useful in very simple situations, but the syntax is a little confusing (my instinct was to think that the jobify method was class level, like delegate or has_one).
In your README you mentioned that one barrier for writing more jobs is “activation energy”, which I think is referring to the time it takes to write a new job class. That’s sort of invalidated when you can rails g job MyTinyJob.
Sidekiq used to have this feature and called it “Delayed extensions”. It was disabled by default in version 5.0 and removed in version 7.0. You can find the author’s reasoning here, and check if it applies to your own implementation:
Thanks! It did not apply. Jobify did not suffer from the same issue. However, I have since decided against the whole thing in favour of Subclasses like User::SomeTaskJob < ApplicationJob, which are almost as clean and without all the bells and whistles and much less complexity added.