Get events to return iterator or channel insted of slice
Closed this issue · 3 comments
ar3s3ru:
I would try to leverage channels instead of returning slices from the Event Store (this might cause issues with apps with very large streams, although snapshotting is always an option.) I've implemented this in eventually-go, you could check it out to gain inspiration.
Kirides:
i would rather not use channels, but instead prefer some sort of a cursor to iterate.
Channels are something i do not want to see in function return values, but are more-or-less fine in a closure over them, eg Iter(fn func(events <-chan Event)).
In any case, a stream approach is way better than just returning 100-1000 events per aggregate (our maximum number of events per object until a snapshot is made, depending on prod-early/prod)
ar3s3ru:
Channels are something i do not want to see in function return values
Absolutely agree, that's why in eventually channels are injected into functions.
The idea is: callers know about the concrete concurrency requirements of the application, so they should be the one creating channels. However, callees (e.g. Event Store) are the producers. So it's important that each implementation correctly closes the channel once done (and absolutely not do that on the caller side)
Check out eventually to get a better idea: https://github.com/eventually-rs/eventually-go
A good staring point would be to experiment with replacing the []Event response with an iterator in the GlobalEvents method.
Merged