You're Building a Distributed System!
summary
A team ships an Ember app to Uganda, experiences the internet going down about five times and power outages three times, and treats the browser as a node in a distributed system. The solution stores UI edits in IndexedDB as semi-permanent state, uses Orbit.js to queue and replay changes, and evaluates CouchDB + PouchDB or CRDTs for sync; offline writes enable zero‑latency UI but conflict resolution and web drivers remain work in progress.
AI-written summary · about
chapters (16)
- 0:00Intro
- 0:45Youre Building a Distributed System
- 7:35Permanent State
- 8:30Application Architecture
- 9:49SemiPermanent State
- 12:15Synchronization
- 17:06Distributed System
- 18:08Cap Theorem
- 18:57Consistency
- 19:32Availability
- 21:22Partition Tolerance
- 21:37Partition in Practice
- 24:23Going Offline
- 25:17Synchronisation
- 25:59CouchDB and PouchDB
- 29:49Conclusion
related talks
27mTaking Ember Offline
45mThe Future of Data in Ember
24mBuilding a real ambitious application using Ember, Node & CouchDB
31mBest Practices for Architecting Server-Driven Web/Mobile Apps
30mFault Tolerant UX
19mBuilding Real-Time Applications with Ember
33mGoing realtime with Ember
46mArt and Science of Shipping Single Page Apps with Ember.js