PSR-14 EventDispatcher which is capable of dispatching both regular and async listeners.

v1.4.0 2020-03-13 19:18 UTC

This package is auto-updated.

Last update: 2020-08-31 00:36:29 UTC


This library provides a PSR-14 EventDispatcher which is capable of dispatching both regular listeners and async listeners which are executed using swoole's task system.

Most of the elements it provides require a PSR-11 container, and it's easy to integrate on mezzio applications thanks to the ConfigProvider it includes.

Build Status Code Coverage Scrutinizer Code Quality Latest Stable Version License Paypal donate


Install this library using composer:

composer require shlinkio/shlink-event-dispatcher

This library is also an expressive module which provides its own ConfigProvider. Add it to your configuration to get everything automatically set up.


This module allows to register both regular and asynchronous event listeners on a PSR-14 EventDispatcher.

Regular listeners are executed on the same process, blocking the dispatching of the HTTP request, while asynchronous listeners are delegated to a swoole background task, making the request to resolve immediately.

If swoole is not installed, async listeners are ignored by default, but you can choose to make them to be registered as regular listeners instead.

In order to register listeners you have to use a configuration like this:


return [

    'events' => [

        'regular' => [
            'foo_event' => [
            'bar_event' => [

        'async' => [
            'foo_event' => [

        'fallback_async_to_regular' => true, // Defaults to false



The events config entry has these blocks.

  • regular: A list of events with all the listeners tha should be dispatched synchronously for each one of them.
  • async: A list of events with all the listeners tha should be executed as swoole tasks for each one of them.
  • fallback_async_to_regular: Tells if async event listeners should be dispatched as regular ones in case swoole is not installed. It is false by default.

In both cases, listeners are identified by their service name, making the services to be lazily resolved only when their corresponding event gets dispatched.