Difference between Laravel queued event listeners vs jobs Difference between Laravel queued event listeners vs jobs laravel laravel

Difference between Laravel queued event listeners vs jobs


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.


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).