← Lessons

quiz vs the machine

Platinum1820

Frontend

The Offline First and Sync

Let the app work without a network by queuing changes locally and syncing when connectivity returns.

6 min read · advanced · beat Platinum to climb

Work first, sync later

An offline first app treats the network as optional. Reads come from a local store, and writes are recorded locally and applied to the UI immediately, then queued to send when the connection returns.

  • The local store, often IndexedDB, holds the working copy.
  • Writes go into an outbox queue with their intent.
  • A sync engine drains the queue once online.

Handling conflicts

When two clients change the same data offline, their edits can conflict on sync. You need a resolution policy.

  • Last write wins is simple but can silently drop edits.
  • Merge by field keeps non overlapping changes from both sides.
  • CRDTs let edits merge automatically without a central referee.

Sync mechanics

The sync engine sends queued changes, applies the server response, and reconciles. It must be resilient.

  • Make sends idempotent with client generated ids so retries are safe.
  • Track a per record version to detect conflicts.
  • Surface a clear state for pending, synced, and failed changes.

Key idea

Offline first apps read and write to a local store and queue changes in an outbox, then sync with idempotent retries and a clear conflict policy when the network returns.

Check yourself

Answer to earn rating on the learn ladder.

1. How does an offline first app handle a write with no network?

2. Why use client generated ids and idempotent sends?

3. What is a drawback of last write wins conflict resolution?