Event Sourcing made Simple
If you're already using react/redux, there's one really nice pattern to make eventsourcing easy to implement. I learned it from the boardgame.io google project[1].<p>Basically redux is more or less already doing eventsourcing on the client. You have actions("events") that tells your global state what the next state should be, and replaying the history of all actions will deterministically get you to your current state. The only thing you need to do is persist that history of actions in your state also (which is already commonly done for implementing undo and time-travel).<p>Then all that is left is to make your server use these same events too! This means whenever you save to the server, rather than doing GraphQL/REST-style per resource updates, you just sync any unsaved redux actions from the client. The server will save these actions and optionally replay them to get a snapshot of current state (or don't - that's just an optimization. The queue of actions is the first class citizen now).<p>Afterwards realtime collaboration, undo/time-traveling, history/audit logging, etc all come for free.<p>This is a really nice way to unify event shape design that is consistent on client and server.<p>[1] <a href="https://news.ycombinator.com/item?id=15946425" rel="nofollow">https://news.ycombinator.com/item?id=15946425</a> or <a href="https://github.com/google/boardgame.io" rel="nofollow">https://github.com/google/boardgame.io</a>.<p>(I am making it sound a little simpler than it is. There's <i>a lot</i> of details to get right with state design, tagging actions as relevant to be persisted, multiplayer conflict resolution, app versioning issues, event queue compaction, serverside permissions validation, etc. But to get a prototype up and running quickly what I said above will work. Boardgame.io didn't worry about those details but it's still a nice codebase to study)