Downloaded 11 times
![Maurice De Beijer [MVP], profile picture](https://cdn.slidesharecdn.com/profile-photo-mauricedb-48x48.jpg?cb=1756998088)
Uploaded byMaurice De Beijer [MVP]
Event Sourcing your Angular and React applications
This document discusses event sourcing for Angular and React applications. It introduces a data storage maturity model ranging from 0 to 3, with event sourcing being level 3. Level 2 is Command Query Responsibility Segregation (CQRS), which separates read and write operations. Event sourcing stores all state changes as a sequence of events and allows reconstructing the entire state of an application. Projections are used to transform events into data views.
More Related Content
Similar to Event Sourcing your Angular and React applications
More from Maurice De Beijer [MVP]
Event Sourcing your Angular and React applications
- 1. Event-Sourcing your Angular andReact applications MAURICE DE BEIJER - @MAURICEDB
- 2. Who am I? Mauricede Beijer The Problem Solver Microsoft Integration MVP Freelance developer DevelopMentor instructor Twitter:@mauricedb Blog: http://msmvps.com/blogs/TheProblemSolver/ Web: http://www.TheProblemSolver.nl E-mail: maurice.de.beijer@gmail.com
- 7. Data Storage MaturityModel 3 - Event Sourcing 2 - CQRS 1 - Structured storage 0 – Data Dump
- 8. Data Storage MaturityModel 3 - Event Sourcing 2 - CQRS 1 - Structured storage 0 – Data Dump
- 12. (Semi) Structured storage DatabaseCRUD Server HTTP Browser
- 15. Data Storage MaturityModel 3 - Event Sourcing 2 - CQRS 1 - Structured storage 0 – Data Dump
- 16. Command Query ResponsibilitySegregation
- 17. Command Query ResponsibilitySegregation Database Query Service Browser Command Service Read Update
- 21. Data Storage MaturityModel 3 - Event Sourcing 2 - CQRS 1 - Structured storage 0 – Data Dump
- 24.
- 25.
Editor's Notes
- #4 Why? I want to create better applications Most applications store the current state http://www.flickr.com/photos/celestinechua/9661913835
- #5 Everyone can build on frozen specifications. In practice they hardly ever are! https://www.flickr.com/photos/josephers/3147837163
- #6 We refactor to improve an application. https://www.flickr.com/photos/nyuhuhuu/4442144329
- #7 The database is the hardest part of the application to refactor https://www.flickr.com/photos/wackystuff/15438012366/
- #8 Levels of working with data Create Read Update Delete Command Query Responsibility Segregation Event-Sourcing
- #9 Data dumps and CRUD actions against database is very similar as seen from the front end
- #10 Most applications store the current state If you are lucky there is an audit trail of sorts http://www.flickr.com/photos/ell-r-brown/4011702143
- #11 http://www.flickr.com/photos/willowbl00/12459211923
- #12 http://www.flickr.com/photos/sukiweb/10223596316
- #13 The server is often just a simple gateway with just some validation logic
- #14 $resource and noSQL database make CRUD applications really easy
- #15 There is nothing wrong with a CRUD application if the problem domain is simple http://www.flickr.com/photos/juhansonin/5144239690
- #16 Command Query Responsibility Segregation
- #17 CQRS = Command Query Responsibility Segregation Use a different model to update information than the model you use to read information http://www.flickr.com/photos/usnavy/8220344431
- #18 Still storing just the current state Database structure is often normalized and optimized for updating Most application read far more frequently then update
- #19 Commands should be modeled after business actions A business user can understand command names and have a reasonable expectation of the outcome http://www.flickr.com/photos/micahdowty/4630801442
- #21 We are stil storing only the current state No trace of how we got there http://www.flickr.com/photos/danrocha/15602018982
- #22 Event sourcing doesn’t depend on CQRS but that structure is often used.
- #23 Event Sourcing is a very old idea that has become popular again over recent years. Events provide insight into how the system came to be in its current state The current state is a left fold of the events http://www.flickr.com/photos/dragontomato/5174914835
- #24 Domain Event is something that has happened in the past The result of a Command to change something Very similar to the audit trail in a database http://www.flickr.com/photos/lendingmemo/11747440176/
- #25 No longer storing the current state but all event leading up to it The current state is a left fold of all events The projection parts are not really part of ES but CQRS and usually combined
- #26 Flux has a very similar and explicit way of working with data.
- #27 Events are never erased or updated An append only model Updates may happen during application updates http://www.flickr.com/photos/horiavarlan/4263326117
- #29 Events are projected out to the read model Observed facts = events Derived facts = projections http://www.flickr.com/photos/fotnmc/7172465908
- #31 Eventual consistency both good and bad Better scalability Harder to program the UI Block until done Fake it on the client Use long polling or push notifications http://www.flickr.com/photos/epsos/5732013768
- #32 Event Sourcing adds complexity Don’t do it where it doesn’t make sense It’s perfectly fine to use CRUD for static reference and ES for domain in the same app http://www.flickr.com/photos/10912969@N03/2046600021/
- #33 Sample application: https://github.com/mauricedb/Movies-GES Main technologies used: https://angularjs.org/ http://geteventstore.com/ http://redis.io/ http://www.asp.net/ https://www.flickr.com/photos/kevandotorg/6229660191
- #34 More info: Martin Fowler: http://martinfowler.com/eaaDev/EventSourcing.html Greg Young: http://goodenoughsoftware.net/ Daniel Whittaker: http://danielwhittaker.me/tag/event-sourcing/ João Bragança: https://github.com/thefringeninja/derp.inventory Damian Hickey: http://dhickey.ie/?tag=/Event-Sourcing https://www.flickr.com/photos/stevendepolo/4582437563/