Evaluating IssueTracker scenario - learning playground

EventStoreDB
1

Hi,

I’m checking out the capabilities of EventStore and I’m playing with simple IssueTracker. Basics of my approach so far are described here: https://github.com/bprzygoda/IssueTracker/wiki/Approach

While the issue events coupled with state changes are pretty straightforward, I was having some difficulties with giving a way to grab the list of reported/taken issues for specific user. At first I was filtering for specific events (Reported, Taken), creating new streams: ReportedIssues, TakenIssues and then using partitionBy to partition per user and build state (list of ids).

Reading through various sources, the general conclusion was that building state that grows proportionally with the amount of objects is bad idea, and it helped me to come with better approach - I just generate new streams (per user) which contain Reported and Taken events. Then, client app would just use such stream to build its internal list (and use live subscription to keep them up to date).

The real reason why I’m posting this, is that I wanted some help with this issue, but I solved it while I was writing this post so…I’m sharing my experiences anyway.

2

It is good that you solved your own query. You said you read through various sources; which source pointed you in the right directions?

3

Mostly Rob Ashton’ blogposts about ponies, there is discussion about avoiding building up large states in one of his posts comments: http://codeofrob.com/entries/creating-a-projection-per-stream-in-the-eventstore.html

What I like is that I was being able to end up with just new streams with linked events (should be nice for performance I think) instead of trying to rely on some external storage.