New events can be added for several system processes to remove horizontal dependencies.

For example, when fetching a service from the Services model, often more data is appended to the returning service object. Currently, the Services model has to know of and implement this itself, but instead, it could defer to an event. This would loosely-couple the model with the appended actions, which should lower cohesion for data that is not necessary for the model to know.

There are several things we can do with events that would be useful:

1. Add events for before and after actions. The primary application for this is currently models, but could be used by plugins so other plugins can listen for them
   • Example: When Services::add is called to create a new service, we can trigger a before event to notify listeners after we have validated the service, but before we have created it. It can be passed the data being used to create the service. Likewise, after the service is created, we can trigger another event to notify listeners that the service has been created
   • Deprecate existing events when before/after is supported. Existing events will need to call their new before or after events, whichever the case may be for backward compatibility with their current implementation. We should also note this in the documentation.
2. Allow events to be processed asyncrhonously. Currently, since php is a single process, all events are processed synchronously, which means that they block. If any event triggered should take a long time or fail, the user that triggered the action that led to the event will also have to wait. This is not good for the user experience
   • Consider integrating a daemon service. Cross-platform independence would be very useful so that we Blesta can be installed with Windows/Mac/Linux OS's and still function. We can trigger the event to be processed by a daemon, triggering all listeners in a queue.
     • Laravel's artisan queue system appears to be very good, but it looks like there are a lot of dependencies, and we would need to create Jobs using it
     • Someone wrote a cross-platform daemon manager @ https://github.com/cubiclesoft/service-manager/
   • I think all requests should typically be asyncrhonous to avoid blocking, except appending content to fetched resources. There should be an option for the event to be triggered asynchronously or synchronously when called, or the event itself should operate on either sync/async. Preferably the latter.
3. If events can be asynchronous, this may cause some cron tasks to be unnecessary because they can be replaced by the asynchronous event. We'll need to check each cron task to be sure, such as delivering invoices.
   • Each cron task, or set of cron tasks, could be a separate asynchronous call. This will allow one failing cron task to not affect whether others are run that come after it
   • Delivering invoices could be it's own asynchronous task
   • Creating services and creating invoices and paying them may need to be a cron task set that are run together, to maintain order.