Playground Checkpoint
Design and build a real schema — no auto-grading, just a real attempt.
The Challenge
Five chapters of real realtime sync, all converging on one real challenge: sync GreenMart's actual live order tracker, the way this whole Act argued it should work — this Act's own hero incident, reproduced and genuinely resolved end to end.
Open the Playground and build it for real: subscribe both clients to the same order, write a real update and watch it push automatically, then send one client offline, create a real conflicting write from the other, and reconnect — watching the conflict get detected, resolved, and pushed out to both sides as one final, consistent answer.
What Your Live Order Tracker Needs
- Both clientA and clientB subscribed to the same order path before any writes happen.
- At least one write that both clients receive as a real, automatic push notification — no .get() calls needed for it.
- One client sent offline (goOffline()), followed by an optimistic local write from that same client.
- One real, conflicting write from the other client — still online — to the exact same path, while the first client is offline.
- The offline client reconnecting (goOnline()) — producing a real, logged conflict, resolved by last-write-wins, and pushed to both subscribed clients as the final value.
Stuck? A Few Hints
- Reread optimistic-ui-and-offline-first's own worked example — this checkpoint reuses the exact same shape, just with both clients subscribed from the start this time.
- Subscribing the online client too (not just the offline one) is what makes the final, resolved value actually reach it as a real push notification — try it both with and without that second subscription to see the difference.
- The conflict log line is the checkpoint working correctly, not a bug — it's proof the simulator genuinely detected two real, competing writes to the same path.
Ready to Build It?
Opens the Playground, right in your browser — nothing to install.
Every command should produce a real result — a write confirmation, a push notification, or a logged conflict. The final goOnline() should produce a real ⚠ conflict line, followed by both clients ending up with the exact same, resolved value — that's the checkpoint working correctly, not a sign something went wrong.
Before You Move On
Two subscribed clients, a real push notification, an offline write, a genuine conflict, and one final, resolved value pushed to both sides — that's the whole Act, in one script: the database isn't just where data sits, it's part of how the app actually communicates with the data, honestly, even when two people were looking at two different truths a moment before. The next Act steps back from any one database to a harder, more honest question: does GreenMart really need six or seven of them running at once?