Laravel Mail ShouldQueue vs Job ShouldQueue

Question

Okay, so I get the idea of ShouldQueue and that it lets the application run more smooth.

But what I don't get, is the difference between using a Mailable with ShouldQueue vs using a Job with ShouldQueue.

If I use Mailable with ShouldQueue and send the mail as I normally would, the mail is queued and should then be send by a worker.

If I use Job with ShouldQueue it does the same thing but with 1 more class (It feels a bit redundant). So in my use case it looks like using Job is a waste of time?

Can anyone please tell me what benefits I would get with using Job over Mailable? :)

Answer 1

When you dispatch a Job with the ShouldQueue contract it will be added to a queue (if not specified the default queue). During this process execution, when you create a Mailable with the same contract, it will be enqueued to the same queue or to another.

As in most of these cases, the answer to your question is it depends .

For example:

• If you have to dispatch a job with a specific logic that requires a lot of time to be executed and, when this task is over, you have to notify tons of users, than the answer is enqueue both the job and the Mailable and in 2 different queues.
• If you have to notify just a user, enque the job and send the Mailable directly.
• If you have to notify a user for a password reset and you have just a few requests for a password reset, send the Mailable directly.
• .....

The benefits, IMHO depend on what you have to do. Usually, more tasks you have to complete, more queues are necessary. Anyway it's always better to use the queues in order to return a simple, fast response to the User and handle the rest separately.

For example, if a user registration succeed, but the mailable throws an error, it will create a record on the failed_job_table without telling the User that his / her registration failed.