Event Driven Frontends: What, Why and How
summary
Brings raw business events from an append-only event store into the browser, building client-side state from daily snapshots plus incremental logs so initial loads can take minutes but subsequent visits fetch only recent events via HTTP range requests. Stores a SQLite DB (SQLite.org WASM) on the Origin Private File System, runs heavy processing in web workers, and recommends the sync access handle VFS for performance. Uses Azure blob signed URLs (NDJSON), reduces backend cost, and proves viable for large-returning-user dashboards.
AI-written summary · about
chapters (25)
- 0:00Event-driven frontends intro
- 1:04What they really mean
- 2:08Limitations and use cases
- 2:30Why explore this pattern
- 3:34Backend reporting challenges
- 4:59High infrastructure costs
- 7:05Slow cross-team cycles
- 7:46Faster agile development
- 8:53Event sourcing basics
- 10:39Event sourcing in browser
- 13:29Why it enables frontend freedom
- 14:10Data size reduction methods
- 15:34How snapshots work
- 17:46Daily snapshots explained
- 18:29Browser data fetching
- 19:53Using Origin Private File System for persistence
- 21:17SQLite in WASM tips
- 22:21Load performance limits
- 23:25Memory constraints and OPFS
- 25:17Web workers offloading
- 26:00Potential user experience issues and solutions
- 27:21Mobile limitations
- 27:43Cost efficiency benefits
- 28:30Explorative development
- 28:50Q&A
related talks
20mEvent Driven Frontends. What, why and how.
13mUsing events and modern sm tools to clean up local-first logic
19mThe Eventful API: Rethinking Frontend State from the Server Down
28mDynamic UI at the Edge
21mEvent is the new Model
29mThe Design and Evolution of Event-Driven Databases
47mEvent Driven UIs
49mData on the Frontend