[Feature Request] Allow registering subclass of Minion::Job as task

[reinierk]

It would be nice if it is possible to register a (homebrew) subclass of Minion::Job with add_task. This would allow to factor common code into the subclass for several similar tasks.

[kraih]

I've been thinking about doing something like this many times. But not sure yet what the best way to implement it would be.

[kraih]

Whatever we end up with, i do want using job classes to be as easy as $minion->add_task(foo => 'Some::FooJobClass').

[kraih]

I imagine a simple job class would look like this (translated from our basic example):

package MyApp::Task::PokeMojo;
use Mojo::Base 'Minion::Job', -signatures;

sub run ($self, @args) {
  $self->app->ua->get('mojolicious.org');
  $self->app->log->debug('We have poked mojolicious.org for a visitor');
});

1;

And then you'd register it in your app with:

$minion->add_task(poke_mojo => 'MyApp::Task::PokeMojo');

And enqueue it like any other job:

$minion->enqueue('poke_mojo');

Keeping the task a Minion::Job subclass will ensure that event based extensions (using the dequeue event from Minion::Worker) keep working. And give us access to all the lower level APIs in Minion::Job for new extensions on the task level.

[rabbiveesh]

Just a thought, sometimes jobs have shared logic, so maybe instead of being similar to Mojo plugins, they could be more similar to controllers, and have similar shortcuts? so in your case, you'd register it as $minion->add_task(poke_mojo => 'poke_mojo#poke') It would fit with the way that I structure my jobs, where related jobs are in plugins and share some code.

…

On Mon, Jun 1, 2020 at 6:06 PM Sebastian Riedel ***@***.***> wrote: I imagine a simple job class would look like (translated from our basic example <https://mojolicious.org/perldoc/Minion#BASICS>): package MyApp::Task::PokeMojo;use Mojo::Base 'Minion::Job', -signatures; sub run { my $self = shift; $self->app->ua->get('mojolicious.org'); $self->app->log->debug('We have poked mojolicious.org for a visitor'); }); 1; And then you'd register it in your app with: $minion->add_task(poke_mojo => 'MyApp::Task::PokeMojo'); Keeping the task a Minion::Job subclass will ensure that event based extensions (using the dequeue event from Minion::Worker) keep working. And give us access to all the lower level APIs in Minion::Job for new extensions on the task level. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#93 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFURPKT5GVFUKPGW33JIWLLRUO7VPANCNFSM4K2DQUCQ> .

[kraih]

@rabbiveesh There will definitely not be any routing shenanigans with name translation. Multiple methods are worth considering though.

$minion->add_task(poke_mojo => 'MyApp::Task::RandomStuff#poke_mojo');

[rabbiveesh]

Never meant any proper shenanigans, just figured it's a familiar syntax. What you have there also makes me happy.

…

On Mon, Jun 1, 2020, 18:26 Sebastian Riedel ***@***.***> wrote: @rabbiveesh <https://github.com/rabbiveesh> There will definitely not be any routing shenanigans with name translation. Multiple methods are worth considering though. $minion->add_task(poke_mojo => 'MyApp::Task::RandomStuff#poke_mojo'); — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#93 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFURPKQGSWR3AKQYBUGHVSDRUPCB5ANCNFSM4K2DQUCQ> .

[reinierk]

If you want to factor out "base" code just stick your own base class between Minion::Job and PokeMojo

[kraih]

One problem i do see with multiple job methods per class is that extending Minion::Job would become rather tricky. So the feature will probably not be in the first proposal.

[kraih]

We'll start experimenting with the feature in the next Minion release. 3fd1014...8ac422a

[shadowcat-mst]

Also, Role::Tiny exists

[reinierk]

Minion::Job determines that "Run" is the run method. Fiddle with that if you want in your sub class. So I do not see that as any problem

[simonecesano]

I've tried using the subclass feature, and found it too rigid - one subclass per task doesn't seem to offer (to me at least) great advantages compared to registering tasks in a module.

I was looking for a way to add behaviours to tasks as in a question I'd asked on stackoverflow (https://stackoverflow.com/questions/65626783/setting-the-finish-event-on-a-mojolicious-minionjob).

It turned out that adding roles to tasks looks IMHO more fluent.

The way I did it was

• a task builder function that takes a subref as argument, plus options
• the task builder function wraps the subref in a job, adds roles to it
• and returns another subref that runs the job

It works ok with two roles I built - a timeout that kills the job if it runs longer than a given time, and one that posts to a URL when the job is finished or failed

app->minion->add_task(some_task => task(sub { my $job = shift; sleep 5; $job->app->log->info('I am a task'); return 'Done!'; }, { roles => { '+Alerter' => { 'alert_on' => [qw/finished failed/ ] } } }));

I am an amateur - not a pro - and new to this so bear with me pls. My code kind of sucks right now, but I could share after a little cleanup it if it helps. I found this approach more inline with the general Mojolicious/MInion way of doing things, so I thought I'd share it, I hope it's ok.

[kraih]

The feature is done. More additions can be discussed in new issues.