For me the first thing I needed and worked on were the IRepository implementation for GetEventStore and the Event Dispatcher that Andrii and yourself helped me out with. Once I had those pieces of infrastructure I felt that I could actually do domain work. I never went to production ready, but I think the work done to get the event store as a Windows Service would also be extremely helpful.
Cheers
Phil
Phil,
Are you using the rc of 1.1.0 in the client API - the subscribe and catchup code is now built in there so there’s a lot less code required on your part
Cheers,
James
Hey James
I haven’t upgraded yet. I plan on updating the gist to use the new “goodness” of 1.1.0, but real life has been taking precedence lately. I have a long weekend coming up, so hopefully I get to do some fun coding.
Unless I am misunderstanding the features in the latest release it seems that some kind of EventDispatcher is still something that may be needed early on if you are building your own read stores as opposed to using pure projections?
That was my reasoning in thinking that the dispatcher and an IRepository concrete implementation for GetEventStore would be good to have in the getting started docs.
Cheers
Phil
Phil,
1.1.0 is now released properly rather than just in RC.
It adds an operation named SubscribeToStreamFrom and SubscribeToAllFrom which respectively take a sequence number and a logical position, and will push all events since then to you. If you store the “last seen” position transactionally with the result of your read model generation (say inside the same database transaction), you can recover by subscribing from that point.
Does that help clarify? (I’m updating the docs for that area at the moment)
Cheers,
James
Yes. That’s great. It will simplify the catch up code immensely. I am hoping to get to updating my event dispatcher gist this weekend. If I do I will definitely use 1.1.0 and the new methods you are suggesting.
Just to make sure I am getting this… I could do a SubscribeToAllFrom(…) and each time I read I could store the slice’s LastEventNumber. In the event of a dispatcher failure/restart I would use that stored event position to re-subscribe?
Cheers
Phil
Yes, that’s the idea. Also, if you need at-least-once messaging then you only need to store it every so often.
I think I have convinced myself that exactly-once messaging is easier as I don’t have to enforce idempotentcy in each of my event handlers. I’m not sure if I have convinced myself of a fallacy in this case though :).
Don’t be confused by LastEventNumber on EventsSlice and event number of last event in slice. LastEventNumber is
///
/// The last event number in the stream.
///
public readonly int LastEventNumber;
so that’s not what you want to store transactionally.
This is a precious little addition and I will immediately start using it…
Andrii
Is this still the way to store the last processed event?
_lastProcessed = evnt.OriginalPosition.Value;
Then pick back up reading at that point on dispatcher restart?
Phil
Linking to the vids on vimeo / skillsmatter would be cool!
And about that, I recall that Greg said at NDC that while you could use eventstore as your queue - please don’t. Does this advice still apply?
João, links to the videos are in the GitHub wiki (also where our docs are now hosted).
Whether or not you use the event store as a queue depends on context. For populating read models there's nothing wrong with using it as queue - also for some use cases it can be a perfectly good queue in its own right. I'm fairly sure that what Greg was warning against was building complex routing rules and having it act as a broker.
Cheers,
James