So in my absence the past 2 months I’ve now decided to tackle this daunting topic in this post. Keep in mind this is rigged more towards writing something more in line with a repository abstraction that uses EventStore as storage mechanism. This abstraction will be aware of how we’ll be grouping domain aggregates with their ids to create a stream. How to go about actually event sourcing an application is way more complex and possibly above my abilities of explanation.

How to do this?

So before we just jump in on how to do this we’ll have to investigate what API to use. There are 3 available as we can see here. We are excluding the HTTP-based interface as we’re interested in something that fits would work easier from a server side perspective rather than exposing Event Store to consuming layers. This will allow us to keep a closer eye on our data store but also have us build our own server without the need to worry for consumers to know how to consume these events.

So looking at the 3 Node.js APIs we can use you’ll notice that at time of writing only two of the APIs are actually maintained. I have thus ignored the use of ges-client as it’s latest update was more than a year ago. That leaves us with event-store-client by x-cubed and eventstore-node by nicdex. I’ll be looking at both as each on has their own way of handling the asynchronous nature of loading events from Event Store.

eventstore-node by nicdex

This is an interesting API option as the author has decided to try and mimic more closely what Greg Young has done with the .NET API. He’s taken the liberty of utilising promises to mimic .NET Task as events are loaded in batches. This has the API feeling quite like the OO approach which might be problematic knowing the nature of JavaScript. If one is careful however it should not be a problem.

Having looked at the code samples provided in the GitHub repository it was clear that the author also makes use of raising some events that can be bound to during the process. I haven’t used it myself so I’m not completely sure how much flexibility there is in using it, but it might also be an interesting option to use in this API.

event-store-client by x-cubed

Looking at this API it’s quite obvious the author opted for the traditional callback approach. This feels like the more functional approach and I’ll most likely also use either lodash-fp or ramda in conjunction with this in order to allow for some nice currying and composition. Note that I’m no expert on Functional Programming and I’m not writing pure functions doing it this way, I’ve just found that applying some of the FP concepts allow for some easier reasoning in what the code is actually doing.

I’d also suggest having a look at what Event Store is actually doing under the hood in order to get a better grip on what we’re actually trying to achieve before we tackle nice code samples. This is quite a big topic though so I’m splitting up the articles a bit and will be looking at using eventstore-node in the next post.

Edit: I’d really suggest going and watching some of his talks on CQRS and Event Sourcing. It will likely help a lot with some of the concepts that are applied for the process of saving events.