Detecting Connectivity and Triggering Sync

To push these queued mutations to your server, you need to listen for network state changes. Browsers provide the navigator.onLine property alongside online and offline window events.

window.addEventListener('online', () => {
  console.log('Connection restored. Starting sync process...');
  processSyncQueue();
});

window.addEventListener('offline', () => {
  console.log('Connection lost. Switching to offline mode.');
});

While navigator.onLine is useful, it is not foolproof. A user might technically be connected to a Wi-Fi router that has no actual internet access. To handle this, your sync function should wrap API requests in robust error handlers. If a request fails due to a network timeout, the sync worker should pause and back off.

Handling Conflict Resolution Strategies

Sooner or later, you will run into a scenario where a piece of data was modified locally while offline and also modified on the server by another device or user. How do you resolve the mismatch?

There are three common strategies I use depending on the product requirements:

1. Last-Write-Wins (LWW)

This is the simplest approach. Every record gets a timestamp (updatedAt). When syncing, the server compares the client's timestamp with its own. The most recent timestamp wins and overwrites the older data. While easy to implement, it can lead to silent data loss if an older update overwrites important newer edits.

2. Client-Wins or Server-Wins Flags

For specific use cases, you can enforce a deterministic rule. For example, in a personal offline habit tracker, local edits made by the user almost always take precedence over stale server states.

3. Manual Merge / Diff Resolution

For collaborative apps, you can store both versions and prompt the user to resolve the conflict manually, similar to how Git handles merge conflicts. This provides maximum safety but adds significant complexity to the user interface.

Keeping Server and Local IDs Aligned

One tricky issue when syncing offline-created records is handling primary keys. If your client generates a temporary ID (like a UUID) for a new record, the server needs to recognize that ID or return its own authoritative ID upon successful insertion.

When the server responds with a 201 Created and provides the official database ID, your sync worker must update the local IndexedDB record, replacing the temporary client ID with the permanent server ID, and update any foreign key relationships pointing to it.

Wrapping Up

Building offline-first applications requires shifting how you think about data flow. Instead of treating the server as the single source of truth at all times, you treat the client as an autonomous node that eventually reconciles its state with the backend.

By combining IndexedDB for structured local storage with a robust mutation queue and clear conflict-resolution rules, you can deliver lightning-fast, privacy-friendly web applications that never leave your users hanging when the Wi-Fi drops.

Need help architecting an offline-first web app or robust API backend for your next product? Let's talk about your project requirements. Get in touch and tell me what you are building.