Today marks the first day when a new feature of xAppOS goes live on several websites. It is a feature that has been in development for several months and finally reached a state deemed stable enough for being let out in the wild. This system is an Event+Action system where actions can be run by triggering events. This system solves a challenge that has been becoming more and more apparent as the xAppOS platform grows and matures. A growing portion of the functionality is not user-driven, in that it's not triggered by a user's interaction with the website. Instead, the use of cron jobs to trigger such actions was being used on an increasing basis and the task of managing a growing number of cron jobs across several websites was a growing headache, highly inefficient from management and server resource standpoints.
This new Events system operates on a steady heartbeat — a cron job job triggered once a minute — and on each beat, the system checks for any queued events. Attached to the events are the actions to be run. Some events might be scheduled for a particular date and time, so those are skipped until that time is reached. But many are simply waiting to be triggered at the next heartbeat.
The beautiful thing about this system is that it can operate entirely on an on-demand basis. For example...
- The PostOffice module has been upgraded to trigger an event to send queued messages any time a message is queued. See how sweet that is? No longer does PostOffice have to be polled to see if there are queued messages... now that only happens *when* there are queued messages.
- The MyBlog module now only checks to see if there are posts to be syndicated when there are posts to be syndicated.
Every module is an equal player in this system, and even xAppOS itself (the foundation framework) can participate in event handling. Its "housekeeping" method, which was originally triggered by a cron job has been upgraded to utilize the events system. The Administrator simply needs to manually enter a single queued event to trigger housekeeping, and then it triggers itself from that point forward, scheduling itself to run every 30 hours.
This Events system was originally envisioned to solve two main challenges: (1) the extensive processing that sometimes occures as databases become more complex and several things need to be updated; and (2) execution of programming that needs to happen in a certain order, but was not possible to achieve this with the linear programming used for normal request handling. Keeping the overall framework speedy for end users is a very important goal for the platform, so a new approach was needed. Actions that are run separately from the user's requests was needed. As this system came together, it became clear just how useful it would be at solving the growing number of cron tasks being put into place.
It's a whole new world of opportunity with this feature in place...