Events
Last updated
Last updated
The principle update required at the software level to support the changes outlined as part of this document is an adoption of "" architecture for handling application requests.
An "event-drive" architecture is a software structure that functions by responding to "events". In a normal API software paradigm (what we currently use), an application responds to a single request directly after performing some action.
Instead, in an event-driven system, the application's processing components are broken into "listeners" that typically perform a single, discrete function.
This methodology allows for a more distributed and decoupled application of individual processes, which offers significant improvements to software flexibility.
In the above example, all processing is initiated from an event, with zero or many "listeners" attached to that event which are triggered when the event fires.
Additionally, those listeners can trigger other events which invoke other listeners and so on down the chain. This is where we achieve our flexibility. Each of these processes are decoupled from the others, and bear no influence on each other.
In a more traditional request model, our application processes are typically linear, which means each process is dependent on the success of the one that came before it.
Here, we suffer from circumstances where failures in previous processes can interrupt our path towards providing our response to the requester.
As previously mentioned, individual processes are decoupled from each other. This has a profound effect on the technical debt we incur by allowing us to both logically and physically separate processes from each other.
Individual systems can be maintained and built separately, reducing our vertices for regressions and improving development scalability.
These types of systems also lend themselves incredibly well to microservice-type architectures, which fits well with our other development objectives regarding delivery and scalability.
The more our application is decoupled, the easier it is to allow external functionality to live inside it. Logically separating our application's processing into events and the listeners that respond to them provides a simple structure to apply externally for development partners.
This model also allows our internal teams to work using the same methodologies as our external partners. Improvements to one system automatically improve the other.
We've determined as part of our that extensibility is a vital component of meeting the growing and varied needs of our clients.
Our primary method for allowing partners to develop functionality for the Spoonity platform will be "".
