Difference between Laravel queued event listeners vs jobs

Question

I'm trying to wrap my head around Laravel's queued event listener vs jobs.

To me, it seems like that both are very similar:

1. Both implement the ShouldQueue interface (in the case of event listener, this is an option)
2. Both implement the handle() and failed() (optional) methods to perform their respective tasks.

Essentially, to me, both are queued items that can be run asynchronously.

What I am able to distinguish so far is that jobs have more "advanced" features/configurations like $timeout, $tries properties and you may also delay the 'trigger' of a job (courtesy of the Illuminate\Bus\Queueable trait).

There are more I'm sure, but I'm pointing out the one that pops out to me.

So, the question is, what's the actual difference between the two and more importantly, when do you favor one over the other?

Solution 1

Good question, I will begin by how laravel docs explains it

Events : Laravel's events provides a simple observer implementation, allowing you to subscribe and listen for various events that occur in your application. Events serve as a great way to decouple various aspects of your application, since a single event can have multiple listeners that do not depend on each other.

Where as

Jobs : Job classes are very simple, normally containing only a handle method which is called when the job is processed by the queue.

Essentially both are pushing jobs on to queues and/or do some processing its asked to do, the main difference I would say is how they are called.

Events are on the lookout to be called where as Jobs are always explicitly called.

Power of Events is that we can register multiple listeners for a single event and the event helper will dispatch the event to all of its registered listeners without us calling them explicitly. where in case of Jobs we would have to call them each one explicitly.

In short if you have a scenario where an event would trigger multiple method calls event would help. If its a single method call Jobs are good.

Events Scenario: user signs up -> Send email, Dispatch complimentary swag, Create a subdomain for a user profile userxyz.site.com etc etc

Jobs Scenario: user signs up -> Send email.

In the exact context of the question: "Event" is a "Queued Event Listener". Every Laravel Event has a Listener bound to it (the event listener), then, when we queue that event (in the listener) it is magically a "Queued Event Listener"

Solution 2

Well, they are very similar, the eventlistener takes an event as a parameter in the handle method, jobs don't.

Events are good in situations where you want to decouple the triggering part from the action part. For instance when you have several modules in the project and you want one module to react on an event in another.

One limitation of events compared to jobs are job chaining. If you for instance trigger several events from a controller you can't be sure that the worker dispatches them in sequence and that the first is completed before the other is started.

In these (rare) situations I sometimes end up with (non queued) listeners that in turn dispatches (queued) jobs that do the actual work (chained or unchained).