milesmcc
WIP - Generic event tracking (#42)
I've decided to take a shot at #42 as it seemed like an interesting idea. This is still a work in progress.
Some feedback about the domain modelling would be helpful. I thought of reusing Hit, adding an additional tracker , but ended up creating a separate model
The idea behind EventListener is to whitelist event types we want to accept. We could also include a feature flag ACCEPT_ALL_EVENTS so that any new event type we receive would create a new entry to EventListener
Hey! Thanks for putting this together.
One thing I want to consider is potentially leveraging the existing 'hit' model. Maybe that complicates things, but I do like keeping our data model simple. We could simply add a "type" to the hits, and leverage all the existing associations to sessions that hits have.
I worry that this approach could create unnecessary complexity?
@milesmcc Thanks for your feedback. I made some adjustments according to your comments and generalised the Hit model to include events.
It has the byproduct of turning the Hit into a more sparse table. Do you want to give additional feedback before I proceed?
Next step it's a bit intimidating, as I need to refactor the ingress task a bit. Do you have any advice there?
Closing due to inactivity; feel free to reopen if you're still interested in this change.
(Happy to chat about architecture if you'd like; we can setup a time to chat synchronously?)