Making a Writing App Work Offline: Service Workers and Cache Strategies

Writers write everywhere — coffee shops with flaky wifi, airplanes, parks. A writing app that requires an internet connection is failing its users. Here's how I made TaleForge work offline.

The Requirements

1. The editor must work without internet


2. Changes must sync when connectivity returns


3. No data loss — ever


4. The user shouldn't have to think about any of this

Service Worker Strategy

I use a cache-first strategy for static assets (JS, CSS, images) and a network-first strategy for API calls.

// service-worker.js (simplified)

self.addEventListener('fetch', (event) => {

  const url = new URL(event.request.url);



  if (url.pathname.startsWith('/api/')) {

    // Network first for API calls

    event.respondWith(

      fetch(event.request)

        .catch(() => caches.match(event.request))

    );

  } else {

    // Cache first for static assets

    event.respondWith(

      caches.match(event.request)

        .then(cached => cached || fetch(event.request))

    );

  }

});

The Sync Problem

When a writer is offline and making edits, those changes need to be queued and synced later. I use IndexedDB as a local write-ahead log:

1. Every edit is saved to IndexedDB immediately (instant feedback)


2. A sync queue tracks pending changes


3. When online, the queue flushes in order


4. Conflicts are resolved by timestamp (last-write-wins)

Last-write-wins isn't perfect for collaborative editing, but for a single-author tool it's the right tradeoff — simple, predictable, and never loses the most recent work.

Auto-Save

The editor auto-saves every 30 seconds and on every significant pause (2 seconds of no typing). This is more aggressive than most writing tools, but data loss anxiety is real. Writers who've lost work to a crash never fully trust an app again.

The save indicator shows three states:

• ✓ Saved (green)


• ● Saving... (amber)
  


• ⚠ Offline — saved locally (gray)

That third state is crucial. The user needs to know their work is safe even without internet.

PWA Installation

TaleForge is installable as a PWA. The manifest.json defines:

{

  "name": "TaleForge",

  "short_name": "TaleForge",

  "start_url": "/dashboard",

  "display": "standalone",

  "background_color": "#0a0a0a",

  "theme_color": "#7c3aed"

}

When installed, it launches like a native app — no browser chrome, no URL bar. Writers get a clean, focused environment.

Cache Invalidation

The hardest problem in computer science, applied to a writing app.

Static assets use content-hashed filenames (Next.js does this automatically). When code changes, the hash changes, and the service worker fetches the new version.

For the editor itself, I version the service worker. Each deploy bumps the version, which triggers the activate event, which clears old caches:

const CACHE_VERSION = 'v2';



self.addEventListener('activate', (event) => {

  event.waitUntil(

    caches.keys().then(keys => 

      Promise.all(

        keys

          .filter(key => key !== CACHE_VERSION)

          .map(key => caches.delete(key))

      )

    )

  );

});

Results

• Average time-to-interactive on repeat visits: ~800ms (cache-first)


• Offline editor latency: indistinguishable from online


• Data loss incidents since launch: 0

The best infrastructure is invisible. Writers using TaleForge don't know about service workers, IndexedDB, or sync queues. They just know their writing is always there when they open the app.

TaleForge — write anywhere, even offline