Event Driven Architecture #670
Conversation
|
@tkallady looking forward to looking at the code, but first - I'm curious as to why you chose answer recalculation for this example event-based PR? I see the value of this approach for tasks where some asynchronicity is acceptable (e.g. emails; notifications; PDF creation). But for answer-recalcutation, in my mind, data integrity is critical and some eventual consistency is not acceptable. Presumably a changed guardian answer needs to be immediately reflected in the guardians - we don't want these to be out of sync. I'd argue that answer-recalculation is better suited to an atomic transaction approach than an event-driven approach. Ditto with audit log entries. Surely these are not demanding calculations for the DB and can be processed almost instantly. |
Resolves #669
Adds foundation for event based actions, and implements an event based approach for answer recalculation. This can easily be extended to audit logs, notifications, sending email, etc.
yarn devhas been updated to also spin up event bus and worker.The basic flow is:
processEventmethod (what to do with any given event).For testing, minor changes are needed to ensure events are handled before proceeding with tests. I have created a helper function
processEventsfor this.Currently, the event bus is implemented with redis, but it could easily be replaced with any other event bus. I've held off on building too much on redis in case we decide to use a different approach.
To do: