Laravel 5: Events – Subscribers

Scheduler: Events – Subscribers

Subscribers – multiple listening.

Subscriber is nothing but a class, that allows to define many event handlers, not just one.

Creating Subscriber

Take Laravel example:

So, you have 2 listeners.

Each one has 2 elements:

  1. event being fired, e.g.: ‘Illuminate\Auth\Events\Logout’
  2. listener dealing with even defined in #1, e.g.: ‘App\Listeners\UserEventSubscriber@onUserLogout’

Entry #2, shows after ‘at’ which method inside of Subscriber is going to do the job: ‘@onUserLogout‘.


Registering Subscriber

Besides internal subscriber mapping in subscribe() method, you must register it with EventServiceProvider via protected $subscribe:

Now, you are done.


Laravel 5: Events – Firing Events

Scheduler: Events – Firing Events

Firing Events – usage.

This is where you actually initiate all eventing process.

You invoke event process with proper even describing data, so Laravel knows, which event is being fired.

As in above code, you can pass event as an object:

Or you can use class name and pass it as a string, like this:

If you want, you can pass it the old way, like this:


Helper function event() refers to method fire():

(via interface for decoupling).


Laravel 5: Events – Queue Events Listener

Scheduler: Events – Queue Events Listener

Queue Events Listener – Usage.

This is just about feeding Event Listeners to a queue.
There is much more about queues to be learned.
By default, queue is set to ‘sync’, which means that jobs are run one after another, which defeats actual purpose queues are designed for.
So, go to this page and find out more about queues.
What is this queue?

Since events are being looped, as registered in EventServiceProvider $listen property, it means each listener gets a chance to do job, and then loop moves to another,

Imagine, that some listeners are busy and it may take them some time to get their task done.

Unless we do something about that, is may force user to wait looooong time for all event triggered tasks (and other jobs) to complete.

In most cases, these heavy lifting tasks can be done in a bit, not right away, so stuff goes fast in front of a user and does not wreck user experience.

That ‘something’ to be done to unload workflow is a queue.
We simply detach some tasks from workflow, stuff it in a queue of tasks to do, first chance system gets.

It sort of resembles jQuery asynchronous actions.

Getting queue ready for action
Lets see our Artisan-generated Listener file:

If you look at it, you will see interface:

All you have to do, is to implement it and Laravel will do the rest.
This is what I mean by implementing:

That is all.

If no exceptions (errors) are thrown when the listener is added to a queue, processed asynchronously, thus not clogging workflow. After it is processed, queued job will automatically be deleted.


As you see above, it is mentioned, that job will be automatically deleted, if there are no problems.
What if there is a problem?

If you run this code in Artisan:

You will get all console queue commands:

You can use e,g, queue:failed  console commands  from within your Laravel project and scheduler to e.g. get yourself a regular report with failed queues.
Or you can store such failed queues in a table.

Interacting with queues manually.

Sometimes, you may want to delete, or release task from queue when you want it and not when Laravel decides to do it.

For that you have some methods provided by trait InteractsWithQueue:

Here are these methods:

  • delete (Delete the job from the queue.)
  • release (Release the job back into the queue. – units used are seconds)
  • attempts (Get the number of times the job has been attempted.)

You can take a look at this Trait here:

Usage is simple.
You use them inside of Listener’s method handle (most likely).

Above code counts attempts and on 10th attempt it deletes task from queue.


Laravel 5: Events – Listener

Scheduler: Events – Listener

Listener – Usage.

When you register event using Artisan command, e.g.:

… you get this template:


… will be your worker here.

This is where you are going to respond to Event, that activated this Listener.
This is, where you will gather your army of tools to get the job done.

Your event listeners may also type-hint any dependencies they need on their constructors.
All event listeners are resolved via the Laravel service container, so dependencies will be injected automatically.

In other words, you will be able to do this:


Laravel 5: Events – Event

Scheduler: Events – Event

Event – Usage.

When you register event using Artisan command, e.g.:

… you get this template:

 But even something like this would work:

Since almost all work happens in Listeners, Event file can be really quite barren.

We need it to fire events.

We need it to associate events to Listeners, which BTW will do some real heavy lifting, responding to Event.

But that is about it.

Of course, I am not saying to get rid of all that stuff from auto-generated template.
Keep it.

Sometimes, you can pass some specific data via Event class.
e.g., take a look at this code:

We are assigning particular Order object, which triggered event and we are passing it to Listeners via __construct().

But, this is pretty much, what Event is going (in general) sweat for you.


Laravel 5: Events – EventServiceProvider

Scheduler: Events – EventServiceProvider

Registering with EventServiceProvider.

Register events and listeners:

Array of events each with sub-arrays of listeners associated with (listening to) given event.

Register subscribers:

One subscriber per line.

Closure, manually registering events.
Best way to register events and listeners is via property $listen.
There is a way to register closure based events via EventServiceProvider boot() method, like this:

Wildcard events.
You may even register listeners using the * as a wildcard parameter, allowing you to catch multiple events on the same listener.

It is also done via EventServiceProvider boot() method.



Laravel 5: Events – Creating, Registering Events and Listeners

Scheduler: Events – Creating, Registering Events and Listeners

Events and listeners.

Eloquent has its own eventing system – see: here.

We have two ways to create/register event.

WAY 1: Using event:generate.
step 1: register event and its listeners with EventsServiceProvider:

We use protected method $listen, to register events and associated listeners.

step 2: run Artisan command to create files (and categories, if still not there)
Using this method, you will also create all events and listeners defined in method $listen, that are not created yet.

Above method will not generate subscribers.
You have to create it by hand and place it in Listeners directory, or you can put them in separate Subscribers directory.


WAY 2: Using separate Artisan commands for event and listener.
step 1: register event and its listeners with EventsServiceProvider:

This step is the same as above, where we used event:generate.

step 2: create event file

step 3: create listener file

step 4: create subscriber file

More in the next article.