RFC: Jobify - quick background job generation

rubyonrails-talk
1

So I am not sure if this gem is a good idea, or maybe I am overlooking something?

I built this to lower the activation energy to use bg jobs in Rails:

(Note: Not battle-tested in production yet. Use with caution)

It makes it possible to turn most methods into a background job by adding

jobify :my_method

Now my_method can be run async as perform_my_method_later

The gem does this by creating the active job class behind the scenes through the jobify call.

WDYT? Valuable or not? Am I missing something that means this will not work?

2

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.

1 Like
3

Thanks for the feedback! I see what you mean regarding the generators. However in most rails shops I have seen, this was still not done very often. Maybe also due to other reasons.

As for different queues etc. that is on the Todo list. But first I want to see if there is any interest, or some technical reason I missed meaning this is a terrible idea.

Regarding begin / rescue those you can also add to the method you are “jobifying”.

In essence though, this is mostly thought as something to easily turn a small method into a bg job.

Your instinct was correct btw, jobify is class level. You add it after a method definition to create a bg version of that method.

4

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:

5

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.