This is about event sourcing, not EventStore specifically.
I watched this great talk about event sourcing. One of the points I really liked was about using small streams and folding them for each read in lieu of a read model. I really like how simple this approach is and how it eliminates some of the client complexities involved with eventual consistency.
However, there was one concept I struggled with: projections. His suggestion was to create streaming projects, which is basically a collection of smaller streams. His example was: get all the users whose age is > 18 (adult users). He showed how you can just select the streams for these users and add them to a stream projection.
My questions for this approach:
You’d have to keep editing the projections, ideally in a simple way through the event handler. For example, a user who was 17 is going to turn 18, so the projection is going to have to update itself to include events from that user’s stream. How is this done without first computing the state?
His example is a fairly persistent project (“adult users”), but commonly a query is dynamic (e.g., get all users where age is between X and Y). It’s unclear how streaming projections get this done; do you compute the state for every aggregate, then point the events for the aggregates that match the condition to a stream?
Even if you have a “persistent” projection (e.g., adult users), we need a way to “remove” streams. For example, we may have a “children” projection that needs to remove events for aggregate instances that turn 18. How do you remove streams from a projection?