How jlongster/crdt-example-app works
This is a demo collaborative todo app illustrating CRDT-style local edits and multi-device synchronization. Users edit todos and todo types in the browser; client code records timestamped changes, syncs them through a server, and uses Merkle differences to find missing messages. The server stores messages and returns changes for clients to apply. The graph covers the sampled app, client state and sync logic, shared ordering/consistency primitives, and server storage. Some source was only partially sampled, so relationships not shown there are omitted.
Main entry points: sync.js Sync engine · index.js Message API · main.js Todo interface · db.js Todo data
Components 9
Browser app
- Todo interface
client/main.js
Client data and sync
- Todo data
client/db.js - Client clock
client/clock.js - Sync engine
client/sync.js
Shared primitives
- Logical timestamps
shared/timestamp.js - Merkle comparison
shared/merkle.js
Sync server
- Message API
server/index.js - SQLite message store
server/init.sql
Other components
- App user
Connections 12
- App user → Todo interface: edits todos
client/main.js - Todo interface → Todo data: reads and updates
client/main.js - Todo interface → Sync engine: requests sync
client/main.js - Todo data → Sync engine: sends changes
client/db.js - Todo data → Client clock: gets timestamps
client/db.js - Sync engine → Client clock: uses clock
client/sync.js - Sync engine → Logical timestamps: parses timestamps
client/sync.js - Sync engine → Merkle comparison: compares trees
client/sync.js - Sync engine → Message API: posts messages
client/sync.js - Message API → SQLite message store: stores and queries
server/index.js - Message API → Merkle comparison: updates and diffs
server/index.js - Message API → Logical timestamps: parses message times
server/index.js