trevorpan's avatar

Which class to use "implements ShouldQueue"? notifications v. queue job

I've watched the Queue it Up series which is really helpful. However, my queued jobs seem to fail in horizon when using a custom console command.

Here's the steps I'm taking in a Laravel 6 app.

  1. console command via cron job is run
  2. handle() does some logic and fires email notifications
  3. php artisan queue:work redis is up and running. horizon status is Active.
//queue connection
        'redis' => [
            'driver' => 'redis',
            'connection' => 'default',
            'queue' => 'default',
            'retry_after' => 90,
            'block_for' => 5,
        ],
// console command handle()
//here are the various emails in isolation
logic
...
	$lost->user->notify(new SendJobBiddedLosingBiddersNotified($lost));
	$winningBid->user->notify(new SendJobBiddedWinningBidderNotified($winningBid));
        $biddedJob->user->notify(new SendJobBiddedBuyerNotified($biddedJob));
...



// sample notification class
class SendJobBiddedLosingBiddersNotified extends Notification implements ShouldQueue
{
    use InteractsWithQueue, Queueable;

VS.

// queue job class
class SendDeadlineExpiredEmails implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

Should I even use a queue job? Should the console command call a job which then fires notifications?

0 likes
6 replies
Tippin's avatar

@trevorpan If you are using horizon, is there a reason you are using: php artisan queue:work redis and not php artisan horizon ?

trevorpan's avatar

IDK? uh oh

Was trying to make sure I exhausted all possibilities. Sounds like I should x the redis tag?

Tippin's avatar

If you are running the worker without horizon, you would run the artisan:work command as you stated above. If you have horizon installed and are using that to work your queue, than you have to use it's startup command php artisan horizon and do not run the regular worker command

trevorpan's avatar

gotcha, ok thank you. This is all new to me.

As for the classes, which one do you declare the implements ShouldQueue?

Tippin's avatar
Tippin
Best Answer
Level 13

I queue all of my notifications and jobs. The only items I do not queue are my realtime events that I want broadcasted immediately. The main difference between notification and a job is notification allows specifying multiple channels to send the data on and injects the notifiable model class automatically. I usually use jobs for business logic that does not need to directly notify one person or loops through multiple models to run actions/notification on. I notify for single case uses and house no business logic inside a notification class.

trevorpan's avatar

Ok, @tippin

That actually helps out a lot. Each tool is so useful, but I think it's not till you have a real world case where it flushes out..which one, in which way, is the best path.

In this case, I think I'll use the console command to call a job (on queue, with the business logic & loops, etc) which then fires notifications (on queue).

Thank you for sharing your approach!

Edit: Ok, wired everything up as mentioned - console command

SendDeadlineExpiredEmails::dispatch();

Fired properly! Switched all the logic to the queue job - and each one sent beautifully to their own queue. Wish I could post the screenshot of the horizon interface.

Awesome.

Please or to participate in this conversation.