First Working Version
The first working version brought together all the architectural decisions into a functioning client SDK. The
Syncraft class became the single entry point, and event sourcing emerged as the natural approach for change tracking.
Event Sourcing: Change Logs as Source of Truth
The initial architecture had entities, use cases, repositories, and gateways—but no public API. App developers had
to wire everything up manually. The Syncraft class solved this by owning all internal components.
The bigger insight was adopting event sourcing. Instead of just storing documents, the SDK now tracks what happened:
- Documents — current state (full data, local storage)
- Change Log — what happened (partial events, persisted)
- Snapshot — full document state at a point in time (compacted from change log)
Nested Field Diffs
Instead of tracking “document X changed,” the SDK tracks exactly which fields changed. Dot notation for nested objects, bracket notation for arrays:
{
"name": { "old": "Hammer", "new": "Drill" },
"address.city": { "old": "Berlin", "new": "Munich" },
"tags[0]": { "old": "tool", "new": "power-tool" }
}This enables minimal changes with the least chance of conflicts when syncing across multiple backends.
Multi-Backend Convergence
The sync mechanism handles 0 to n backends. After pull, merge, and push, all backends converge to the same state. New backends get full documents as initial sync. Offline backends catch up on the next cycle.
The snapshot mechanism compacts the change log when it exceeds 100 entries or 30 days—enabling efficient bootstrapping without replaying all history.
The shift to event sourcing transforms Syncraft from a simple sync library into a proper data synchronization platform. The change log becomes the audit trail, nested field diffs minimize conflict surface area, and the snapshot mechanism enables efficient bootstrapping. These are the foundations for future features like fine-grained access control and collaborative editing.