[arnioxux]

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].

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).

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).

Afterwards realtime collaboration, undo/time-traveling, history/audit logging, etc all come for free.

This is a really nice way to unify event shape design that is consistent on client and server.

[1] https://news.ycombinator.com/item?id=15946425 or https://github.com/google/boardgame.io.

(I am making it sound a little simpler than it is. There's a lot 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)

[mpfundstein]

A month ago I was trying to implement something redux-like on the backend. Check it out [1]. Its a PoC, events a stored into mongo and a reducer is applying them to produce state (projection). I added another component called decider, which essentially has access to state and then decides for each event whether to process or not! Could be part of reducer but I thought it was nice to split that!

Next step for improvement would be to split event receiving side and event displaying side to get CQSR pattern.

I didn’t write any docs or so, it was just playing around! In the index.js there are some routes that store events and some that show you projection of state.

I really hope event sourcing will get more traction. The idea that you defer building your state model is in my opinion incredibly strong. But there are some open questions that i find hard to answer! Like instant feedback to client, replayabolity of side effects, ensuring ordering when having multiple services etc!

[1] https://github.com/MarkusPfundstein/event-sourcing-node

[latchkey]

An alternative to redux is mobx-state-tree, which has something along these lines as well. Very cool. https://github.com/mobxjs/mobx-state-tree/blob/master/packag...

[codebje]

Side effects and non-determinism can break the relationship between action ("command") and event. You'd need to take care with things such as random number generation, to use a PRNG whose call sequence is determined only by the actions, and whose seeding is an action itself.

Side effects caused by action handlers are also something to beware - don't launch the missiles when you're replaying the past.

[DougBTX]

Reminds me of eg: https://gafferongames.com/post/deterministic_lockstep/