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!
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