Full Stack Flux (was" The future of JavaScript layout systems")
summary
Argues for running Flux on the server: every update becomes a replayable message log and stores act like a store-as-reducer that persist derived state, letting rebuilds and migrations be trivial. Implements stores consuming a message queue (RabbitMQ today, moving to Kafka), enriches actions to avoid unsafe cycles, shards work per-store, and accepts eventual consistency. Demo uses a photo site to show reduced cache invalidation, faster feature rollout, and what worked versus what needed tuning.
AI-written summary · about
chapters (25)
- 0:00Intro
- 1:09Interesting abstraction
- 1:32Solvers are unpredictable
- 1:59Full-stack Flux
- 2:32The current state of the backend
- 2:44A review of Flux
- 3:11The old way
- 4:21A new question
- 5:03A new action
- 6:10Alternative: observe a data model
- 7:39Shared mutable state is the root of all evil.
- 8:28Flux helps you scale actions and questions
- 8:42What about the backend?
- 12:19Your app == derived data ...using the history of every action that ever happened
- 13:09Process every action for every query request.
- 13:24Can we make it fast enough?
- 17:41Lots of advantages Manage the trade-atts of your data store granularly
- 18:04Choose the best data store for your question.
- 19:12Closing the loop
- 21:16Things that don't work
- 23:16Option 2: Enrich data Consume action, emit new action with additional data.
- 24:35Strong consistency Only individual answers to questions may be consistent
- 25:12Strong consistency Lack of strong consistency is a more accurate worldview
- 26:01Read about stream processing frameworks.
- 26:11Turning the Database Inside Out
related talks
07mWhy React is Eating the World
49mReactive Spring
42mGoing Reactive With Spring Data
37mWhy it is harder to scale with stateful, data-driven systems
35mGoing fullstack React(ive)
52mReactive Programming with Spring Webflux
46mGet Reactive! Programming, Systems, and Microservices
27mGitOps Evolution Through the Lens of a Flux Maintainer