Mail, Notifications, Queueable, ShouldQueue, InteractsWithQueue

It's funny Jeff Way just posted the video about Mail vs Notifications because I was struggling to understand some things today...

Question 1: Does simply implementing "ShouldQueue" on Mail, Notifications or Listeners suffice for making something queue?

https://laravel.com/docs/6.x/queues#generating-job-classes it says...

The generated class will implement the Illuminate\Contracts\Queue\ShouldQueue interface, indicating to Laravel that the job should be pushed onto the queue to run asynchronously.

Question 2: Do you also HAVE to use the Queueable trait, or does that just give access to extra queue functionality?

https://laravel.com/docs/6.x/notifications#queueing-notifications says...

To speed up your application's response time, let your notification be queued by adding the ShouldQueue interface and Queueable trait to your class.

https://laravel.com/docs/6.x/mail#queueing-mail says...

Since all mailable classes generated using the make:mail command make use of the Illuminate\Bus\Queueable trait, you may call the onQueue and onConnection methods on any mailable class instance, allowing you to specify the connection and queue name for the message:

https://laravel.com/docs/6.x/events#manually-accessing-the-queue says...

If you need to manually access the listener's underlying queue job's delete and release methods, you may do so using the Illuminate\Queue\InteractsWithQueue trait. This trait is imported by default on generated listeners and provides access to these methods:

Question 3: Has anyone done a deep-dive on all of these things that can give a short synopsis of the purpose of Mail, Notification, ShouldQueue, Queueable and InteractsWithQueue? I know that's a big ask, just curious if anyone has a solid answer to this.

Thanks in advance!!!

fylzero

6 years ago

Best Answer

Level 67

Well, I've come to the conclusion that the Queueable trait IS required to queue Jobs, Notifications and Mail. I wasn't sure of this from the Laravel documentation.

I'm still confused why Listeners don't include the Queueable trait by default but do include use Illuminate\Contracts\Queue\ShouldQueue; and use Illuminate\Queue\InteractsWithQueue; at the top unimplemented. Seems inconsistent.

So I'm calling Question #1 and Question #2 answered. Queueable needs to be used if you want to queue the class.

InteractsWithQueue seems like it just gives access to a few helpers to see how many attempts have been made to run the job, you can delete and fail the job, etc. I'm thinking I won't need that much right now.

Mail vs. Notifications:

Seems like Notifications are probably better most of the time for short messages coming from direct actions that can be sent to multiple channels...

BUT, notifications can be sent to the database... which could actually act as a communication history log... which is nice and actually a business requirement I have.

Would be nice if mail could be sent to the database for this reason. It would also nice to be able to send both to a Log channel.

I also think it would be cool if when you generate a Mail if the system created a blade view for that based on the name you provided as well. Currently it just spits out return $this->view('view.name'); and leaves the view file creation up to you. Which is fine, just seems like something that could also be automated with the command.

1 like

Please or to participate in this conversation.