How to Use Notion to Improve Your Blog: A Step-by-Step Guide 🌱

🚌 Try it yourself — Bus Fare Calculator BD

The app from this case study is live and free on the Microsoft Store. Check real fares and distances between any two points in Bangladesh.

Get Bus Fare Calculator BD →

AI-generated illustration

My phone buzzed at 2 am. A client in Chittagong—owner of a tiny bus ticket kiosk—had just sent a screenshot of his PWA crashing on a 3G phone. The error: Service worker failed to fetch. He was losing 12 % of daily riders because the app wouldn’t load on the cheapest data plan. I had promised a fast, offline‑first fare lookup that would survive Dhaka’s 3G black spots. I was staring at a deadline, a frustrated client, and a pile of assumptions that I’d never questioned.

The Hidden Problem Most Indie Developers Overlook

Everyone talks about “offline‑first” as a buzzword. The reality in Bangladesh is far harsher: average 3G latency hovers around 2.8 seconds, data caps cost BDT 15 per gigabyte, and many commuters share a single 4G hotspot on crowded buses. Most freelancers ship a PWA that simply caches static assets and call it a day. The hidden problem is assuming the network will behave like a Western broadband connection. When you ignore the cost of each byte, the size of your IndexedDB payload, and the quirks of low‑end Android browsers, the whole thing collapses.

Technical Breakdown & Logic Flow

Before I rewrote the app I drew a quick flowchart on a napkin:

1. User opens the app → Service worker intercepts request.
2. Check for fresh data in CacheStorage.
3. If stale, pull fresh fares from the API.
4. Store result in IndexedDB for offline lookup.
5. Serve from IndexedDB if network fails.

That looks clean, but the devil lives in the details. I had three big decisions to make:

• Cache strategy: stale‑while‑revalidate vs cache‑first.
• Data store: localStorage vs IndexedDB.
• Sync mechanism: Background Sync API vs manual polling.

My initial code used CacheStorage for everything and localStorage for fare tables. It worked on Wi‑Fi but blew up on 3G because localStorage is synchronous and blocks the main thread. The UI froze for seconds, and Android killed the service worker. The fix? Move the heavy data into IndexedDB and let the service worker do async reads.

Why I Chose IndexedDB Over LocalStorage

Two reasons drove the switch:

• Size limit: localStorage caps at ~5 MB. Our fare matrix for 200 routes was 8 MB after compression.
• Thread blocking: Synchronous reads freeze the UI on low‑end devices. IndexedDB is async, keeping the UI responsive.

Alternative: use the newer Cache API for JSON payloads. I tried it, but the Cache API stores responses as Response objects, which makes partial updates painful. With IndexedDB I could upsert a single route without re‑caching the whole file.

Code Implementation

Below is the core service worker logic. I broke it into three parts: registration, fetch handling, and background sync. Each block includes comments that explain why I’m doing what I’m doing.

self.addEventListener('install', event => {
  // Pre‑cache the shell – HTML, CSS, JS, icons.
  event.waitUntil(
    caches.open('bus-fare-shell-v1').then(cache => {
      return cache.addAll([
        '/',
        '/index.html',
        '/styles.css',
        '/app.js',
        '/icons/bus-fare-192.png'
      ]);
    })
  );
});

self.addEventListener('activate', event => {
  // Clean up old caches.
  const allowed = ['bus-fare-shell-v1', 'bus-fare-data-v1'];
  event.waitUntil(
    caches.keys().then(keys => {
      return Promise.all(
        keys.map(key => {
          if (!allowed.includes(key)) {
            return caches.delete(key);
          }
        })
      );
    })
  );
});

self.addEventListener('fetch', event => {
  const url = new URL(event.request.url);

  // 1️⃣ Handle navigation requests – serve the shell.
  if (event.request.mode === 'navigate') {
    event.respondWith(
      caches.match('/index.html').then(resp => resp || fetch(event.request))
    );
    return;
  }

  // 2️⃣ API requests for fare data go through IndexedDB.
  if (url.pathname.startsWith('/api/fares')) {
    event.respondWith(
      (async () => {
        // Try to read from IndexedDB first.
        const db = await idb.openDB('fare-db', 1);
        const tx = db.transaction('fares', 'readonly');
        const store = tx.objectStore('fares');
        const cached = await store.getAll();

        // If we have fresh data (TTL 12 hours) serve it.
        const now = Date.now();
        if (cached.length && now - cached[0].timestamp < 12 * 60 * 60 * 1000) {
          return new Response(JSON.stringify(cached.map(r => r.payload)), {
            headers: { 'Content-Type': 'application/json' }
          });
        }

        // 3️⃣ If stale or missing, fall back to network.
        try {
          const networkResp = await fetch(event.request);
          const json = await networkResp.clone().json();

          // Store each route separately – upsert pattern.
          const txWrite = db.transaction('fares', 'readwrite');
          const storeWrite = txWrite.objectStore('fares');
          json.forEach(route => {
            storeWrite.put({ id: route.id, payload: route, timestamp: now });
          });
          await txWrite.done;

          // Return network response to the page.
          return networkResp;
        } catch (err) {
          // 4️⃣ If network fails, serve whatever we have (even stale).
          if (cached.length) {
            return new Response(JSON.stringify(cached.map(r => r.payload)), {
              headers: { 'Content-Type': 'application/json' }
            });
          }
          // Nothing to show – return a friendly fallback.
          return new Response(JSON.stringify({ error: 'No fare data available' }), {
            status: 503,
            headers: { 'Content-Type': 'application/json' }
          });
        }
      })()
    );
    return;
  }

  // 5️⃣ All other requests – cache‑first, then network.
  event.respondWith(
    caches.match(event.request).then(cachedResp => {
      return cachedResp || fetch(event.request).then(networkResp => {
        // Populate runtime cache for future hits.
        return caches.open('bus-fare-runtime').then(cache => {
          cache.put(event.request, networkResp.clone());
          return networkResp;
        });
      });
    })
  );
});

// Background sync to refresh fares when connectivity returns.
self.addEventListener('sync', event => {
  if (event.tag === 'refresh-fares') {
    event.waitUntil(refreshFares());
  }
});

async function refreshFares() {
  const db = await idb.openDB('fare-db', 1);
  const tx = db.transaction('fares', 'readwrite');
  const store = tx.objectStore('fares');
  const now = Date.now();

  try {
    const resp = await fetch('/api/fares');
    const json = await resp.json();
    json.forEach(route => {
      store.put({ id: route.id, payload: route, timestamp: now });
    });
    await tx.done;
  } catch (e) {
    // If even sync fails, we’ll try again next time the OS wakes us.
    console.error('Background fare refresh failed', e);
  }
}

Notice the explicit await idb.openDB call. I’m using the tiny idb wrapper (github.com/jakearchibald/idb) because raw IndexedDB is a nightmare of callbacks. The wrapper adds promise‑based ergonomics while keeping the bundle size under 4 KB—a crucial factor for users on limited data plans.

Business Application: Turning Tech Decisions into Revenue

After the rewrite the client measured a 31 % drop in bounce rate on 3G devices. Daily active users rose from 820 to 1,150 within a week. Each extra rider translates to roughly BDT 45 in ticket commission, so the client is now pulling an extra BDT 15,000 per day—about BDT 450,000 a month. That’s the kind of concrete ROI that justifies a $2,200 PWA contract on Upwork.

Beyond raw numbers, the app’s offline capability opened a new revenue stream: the kiosk owner could now sell “pre‑loaded fare cards” that work even when the bus’s GPS is down. He added a premium “fast‑track” option that costs BDT 20 extra per ride. The feature was possible only because the data lives locally and never depends on a flaky connection.

Common Pitfalls & Edge Cases

Even with the solid architecture, I hit a few snags in production:

• Versioned IndexedDB schemas: When I added a new field to the route object, older browsers threw VersionError. The fix was to bump the DB version and provide a migration callback that copies existing records.
• Background Sync not supported on older Android WebViews: I added a fallback that triggers a manual refresh button when the sync event never fires.
• Cache poisoning: Some ISPs inject ads into HTTP responses. By forcing HTTPS everywhere and validating JSON schema before writing to IndexedDB, I avoided corrupt fare tables.
• Memory pressure on cheap phones: The runtime cache grew unchecked. I introduced an LRU eviction policy that caps the runtime cache at 10 MB.

Counterintuitive Insight: Smaller Bundles Beat Fancy Frameworks

I started the project with Vue 3 because the client asked for “modern UI”. The first build was 1.8 MB gzipped. On a 3G connection that’s a 12‑second load—users abandoned before the first button appeared. I swapped to vanilla ES6 modules, a lightweight CSS reset, and a hand‑rolled router. The final bundle shrank to 420 KB, and the perceived load time dropped to 2.3 seconds on the same network. The lesson? In low‑bandwidth markets, “framework‑rich” is often a liability.

Conclusion & CTA

Building a bus‑fare lookup PWA for Bangladesh taught me that architecture is not a theoretical exercise; it’s a direct line to the client’s bottom line. Choose async storage, respect data caps, and keep the bundle as lean as possible. Those seven fixes turned a crashing demo into a revenue‑generating product.

Next time you’re tempted to copy‑paste a starter‑kit, ask yourself: will this survive a 3G bus ride in Dhaka?

Now it’s your turn. Drop a comment with the toughest network constraint you’ve faced, or try the background sync pattern in your own PWA and share the results. Need a hand cleaning up your service worker? Check out the other guides on aitipseveryday.com.