Recovering Perfectionist

Flux and Event Sourcing / CQRS

In late 2014 I was working on an iPhone app for LASU, a shoppable instagram for yuppies and Facebook was releasing their React Native project. I remeber being excited by it thinking how it would make the development experience I had with Titantium much nicer. Unfortunately it wasn't available yet and I had to get the app done.

So I poored over the documentation in hope of finding some nuggets of wisdom that might help me do what I was doing, better. It turns out that the declarative UI stuff was a little out of my reach at the time (no time to develop a React for Titanium) but the flux approach to manging state in the app was.

Soon after I started to understand what it was the value of separating the actions that manipulated state from the stores of state themselves I rushed to implment my own flux system with actions, stores etc. It worked amazingly and made debugging the app 100x easier. I could store All of the actions that were sent through the dispatcher, log them fromone point and then, play them back through the dispatcher to find the application state that was causing my issues!

Unfortunately LASU fell apart, mainly becuase we failed to assess the needs of our target audience. Which is a long way of saying we never talked to anyone.

The flux implementation left a mark on me though. It just made it much easier for me to understand the flow of state through my app. As I moved more into web services development for our next projects I longed for that clarity.

I recently started reading about distributed logging, event sourcing and CQRS. The premise of these things is:

Distributed Logging
This is about having a single list of events from which services can build up views into the state of those services. This was the post that really got me into it Post.
Event Sourcing (ES)
This is about building up your read state from an immutable list of events. A great presentation on this is here.
Command, Query Responcibility Seperation (CQRS)
This about separating the code you write that has side effects from the code you write that doesn't have side effects (There is some debate about this definition).

Anyway, the point is I realized that Flux, CQRS and ES are all attempting to achieve the same goal: sanely managing application state, via the same means: Separating reads from writes.

This is a work in progress / brain dump