Client-Side and Mobile Data Persistence Questions

High-level approach

Use an offline-first client with Service Worker + Background Sync for retries, IndexedDB as single source-of-truth, an operation queue (op-log) persisted in IndexedDB, optimistic UI updates, server-side versioning, and conflict resolution strategies (merge or manual).

Storage choices

• IndexedDB (via idb or localForage) for documents, metadata, and the op queue — durable, large, works offline.
• Cache API / blob storage for attachments.
• In-memory indices for UI performance; rebuild from IndexedDB on startup.

Queue format (op-log item)

• id (uuid), docId, type (create/edit/delete), payload (delta or full), baseVersion (server version client knew), clientTs, retryCount, backoffUntil, status (pending/processing/failed).
• Use deltas (patches) for small ops; occasionally emit full snapshot to simplify recovery.

Retry & backoff

• Background Sync + periodic sync when online.
• Exponential backoff:
  • backoffMs = base * 2^retryCount + jitter
  • update backoffUntil; stop after maxRetries => mark failed and surface to user.
• Use BroadcastChannel or postMessage to update open tabs.

Conflict detection & resolution

• Detect: server responds with 409 + currentVersion or returns divergent patches.
• Strategies:
  • For structured documents, use CRDT (Automerge/Yjs) to auto-merge.
  • For text-only, use OT/CRDT library or three-way merge using baseVersion + client patch.
  • Fallback: present human-readable diff and allow the user to accept/merge.
• Always store both server and local versions so UI can show a conflict view.

UI feedback

• Per-document status badges: Pending (spinner), Syncing, Synced (green), Failed (red), Conflict (yellow).
• Inline indicators for specific fields changed offline.
• Actionable conflict modal: show local vs server, quick-merge suggestions, accept server/local, or manual edit.
• Toasts for global sync errors and progress bar for batch sync.

Bounding queue size

• Collapse ops: consolidate consecutive edits to same doc into one op (apply patch squashing).
• Periodic snapshotting: after N ops compress into a single snapshot and remove prior ops.
• Hard caps (e.g., 500 ops or X MB): when reached, evict oldest non-critical ops or prompt user to sync/clear.
• Respect browser storage quota APIs; surface warnings if nearing quota.

Why this works (frontend perspective)

• IndexedDB + Service Worker gives durable offline UX; optimistic updates keep UI responsive; op-log + versioning makes sync deterministic; CRDT/merge strategies reduce manual conflict load; UI signals keep users informed and able to act.

Requirements & constraints

• Offline view of previously visited product pages and images
• Allow “Add to cart” while offline and sync reliably when online
• Low-latency UX, secure data, cross-browser support (use fallbacks)

High-level architecture

• App shell cached (HTML/CSS/JS) via service worker; product JSON and images cached on demand
• IndexedDB for offline cart and metadata (product id, quantity, price snapshot, timestamp)
• Background Sync (or periodic retry/fallback) to push cart actions when online
• Server endpoints: idempotent cart API with client-generated op IDs for dedupe

Service worker caching strategies

• App shell: Cache-first with versioned cache name (v1.0.3)
• Product pages/API: Network-first with runtime cache fallback to cache for offline reads (use stale-while-revalidate for freshness)
• Images/assets: Cache-first with max entries and LRU-like cleanup (workbox expiration)
• Use separate caches: static-assets, runtime-api, images to enable selective invalidation

IndexedDB schema & usage

• Store object store "offline-cart" with key = opId, fields {opId, productId, qty, priceSnapshot, status, createdAt}
• Store "product-cache-meta" for content hashes and ETags to validate cached product JSON

Background sync & retry

• On offline add-to-cart: write op to IndexedDB and show optimistic UI
• Register Background Sync tag "sync-cart"
• Sync handler reads pending ops, attempts POST to /cart/ops with retries, exponential backoff, and marks status on success
• Fallback: when background sync unsupported, use online event + periodic retry via setInterval or Service Worker periodicSync (if available)

Cache invalidation & versioning

• Use semantic cache names (app-shell-v{semver}), update SW to delete old caches on activate
• For API resources use ETag/If-None-Match; on 304 keep cache, on 200 replace
• Store content-hash in IndexedDB to detect stale product data and trigger revalidate

Security considerations

• Serve SW and resources over HTTPS; set Service-Worker scope carefully
• Use SameSite and Secure cookies or token-based auth (Authorization header) for cart API
• Sanitize and validate all IndexedDB data before sending; sign ops with short-lived JWT to prevent replay
• Avoid caching sensitive user info in public caches; use Cache-Control headers
• Protect against XSS (CSP, input encoding) because XSS can hijack SW and IndexedDB

Observability & UX

• Surface sync state in UI (pending, synced, failed) and provide manual retry
• Log telemetry for sync failures, queue lengths, and stale-content hits

This approach balances offline reliability, consistency, and security while keeping frontend responsibilities clear and testable.