getLastEventOfEachAggregate, onBeforeSet middleware #90
Conversation
- set data to rev guard store via onBeforeSet middleware - new cocatenatedId format with delimiters to better parse the value - get data from rev guard store via exposed getLastEventsOfEachAggregate fn
|
lib/denormalizer.js
Outdated
| }, | ||
|
|
||
| getLastEventOfEachAggregate: function (callback = (err, aggregateHandleFns) => {}) { | ||
| this.revisionGuardStore.getValueOfEachKey(this.options.revisionGuard.prefix, callback); |
There was a problem hiding this comment.
idk, getValueOfEachKey sounds very specific to the redis implementation...
What about mongodb, etc...?
There was a problem hiding this comment.
how would you like getValueOfEachId?
There was a problem hiding this comment.
I will now add the getValueOfEachId version and update the PR :)
|
can you explain the purpose of the PR a bit? |
we use the even'ts occuredAt date to fetch events that we missed. Our implementation of the queue / bus to our denormalizers are not persistent and therefore it can happen that we miss some events. We then fetch them using a replayer service - common pattern - to which we send a request to retrieve the missed events beginning a certain from date to the last saved event in the store. We have to find the oldest / smallest occuredAt date for all our aggregates in the denormalizer. To do so, having only the revision wihtin the revision guard per aggregate, we'd have to make a query to the eventstore (in our case via the replayer service) for each aggregate and it's revision to retrieve the from date. Putting that traffic onto the denormalizers db is better since it won't affect the evenstore and therefore the rest of the ecosystem. To achieve that the middleware got added, so that we can save the occuredAt or any other data to the denormalizers db and off-load the traffic from the eventstore. The last_seen_event can't be used since the handle fn is per aggregate and therefore an other aggregate can be behind the last_seen_event's time or any other meta data that would be stored there. |
|
|
| callback(null, new ObjectID().toString()); | ||
| }, | ||
|
|
||
| get: function (id, callback) { | ||
| get: function (prefix, id, callback) { |
There was a problem hiding this comment.
i.e. Instead of this...
keep the old signature
get: function (id, callback) {
// and within the function
this.options.prefix
// ...
}There was a problem hiding this comment.
it made the untit testing easier because we don't have to connect again to test the prefix itself more isolated.
also, it makes it more agnostic towards the denormalizer functionality. e.g. when we want to add a sharding feature, one denormalizer might need to handle multiple prefixes. also,
I thought it is more transparent/ guessable when e.g. using the "set" function to see what kind of key will be generated.
these were the thoughts when implementing it.
I don't mind changing the signature back - for our current use case, both works. Just let me know if I should.
There was a problem hiding this comment.
@nanov IMO having the same interface as before and working with this.options.prefix sounds more suitable for me...
There was a problem hiding this comment.
any decision so far? Else i'll just change it back to the old api and hope to get it merged soon then.
fn