The Show Calendar project explores developing an app with the Event Sourcing and CQRS patterns. The goal is to understand how good these patterns are for fast-changing projects, like startups.
One day I ran into a talk by Greg Young's about Event Sourcing, and the concept was super interesting to me. In short, Event Sourcing means that you store all events that happen in your app.
Event Sourcing done right allows you to recreate your app's state at any point in time.
By replaying your events you can recreate your database... but if you think about it, the contents of your database is only a result of all the events that have happened.
Having a log of events isn't a new idea—banks have been doing this for ages. The bank records each change to your bank account in a ledger, and the amount of money in your account is a result of all the entries in that ledger.
The result of producing a value by looking at every recorded event is sometimes called a projection. Events are projected onto a projection, and a projection can be whatever you want—a bank account balance or your app's database contents.
The contents of your database is only one way of looking at the event history.
It turns out that having a record of all the events that have happened in you app—or business—allows you to view those events in different ways.
You'll be able to reinterpret history if you keep a record of what lead up to it.
That's super interesting from a "startup-y" perspective.
If there's anything certain about new ventures it is that, for most things, we're not really certain. And from a coding perspective this means we have to be flexible. Event Sourcing might help us achieve some of that flexibility by giving us the the option to "reinterpret" history.
And this is the reason I'm interested in exploring Event Sourcing from a "startup perspective" where refactoring and flexibility is important.
I was introduced to the "Event Sourcing is good for startups" hypothesis by Mike Mogosanu of Sapiensworks in his article Using DDD, CQRS, Event Sourcing With A Vague, Fast Changing Domain.
Node.js / GraphQL Starter Kit
Install dependencies with
npm install and then start the server with
npm start. The server is then available on
http://localhost:3000 and has the following two routes.
/graphql- GraphQL API endpoint
/graphiql- GraphiQL (<- notice the
Why am I using GraphQL for this project?
Mutation types map really nicely onto the CQRS pattern's Query and Command concepts. In addition to that, the GraphiQL playground is a really nice way to test the API as we go.