PWA আর service worker — অফলাইনেও চলা ওয়েব অ্যাপ

১ · PWA কী — যে ওয়েবসাইট অ্যাপের মতো আচরণ করে

লঞ্চে বরিশাল যাচ্ছেন। নদীর মাঝখানে মোবাইলের নেটওয়ার্ক একবার আসে, একবার যায়। একটি সাধারণ ওয়েবসাইট খুললে দেখবেন ব্রাউজারের ডাইনোসর আর “No internet”. অথচ একই সময়ে আরেকটি সাইট খুলল সাথে সাথে — গতকাল লেখা খরচের হিসাব দেখা যাচ্ছে, নতুন খরচ যোগও করা যাচ্ছে, আর ওপরে ছোট্ট লেখা: “অফলাইন — সংযোগ ফিরলে সেভ হবে”. দ্বিতীয় সাইটটি একটি Progressive Web App, সংক্ষেপে PWA.

PWA আলাদা কোনো প্রযুক্তি বা ভাষা নয়। এটি একটি সাধারণ ওয়েবসাইট — HTML, CSS আর JavaScript দিয়েই বানানো — যার সাথে কয়েকটি বাড়তি জিনিস যোগ করা হয়েছে। ফলে সাইটটি তিনটি নতুন ক্ষমতা পায়:

এই ক্ষমতাগুলোর কেন্দ্রে আছে একটি বিশেষ script — service worker. ব্রাউজার একে পাতা থেকে আলাদা চালায়, আর পাতা থেকে নেটওয়ার্কে যত অনুরোধ যায়, সব এর হাত দিয়ে যায়। প্রতিটি অনুরোধে এটি সিদ্ধান্ত নেয় — জমানো কপি থেকে উত্তর দেব, নেটওয়ার্কে পাঠাব, নাকি দুটোই। এমন মধ্যস্থতাকারীকে বলে proxy; service worker হলো JavaScript-এ আপনার নিজের লেখা proxy, যা ব্যবহারকারীর ব্রাউজারের ভেতরেই বসে।

কেন এটি আমাদের দেশে বিশেষ গুরুত্বপূর্ণ? মোবাইল ডেটা কিনতে হয় টাকা দিয়ে, প্যাকেজের মেয়াদ শেষ হয়, গ্রাম বা নদীপথে সংযোগ বারবার কাটে, আর লোডশেডিংয়ে Wi-Fi রাউটার বন্ধ। যে সাইট প্রতিবার সব ফাইল নতুন করে নামায়, সে ব্যবহারকারীর টাকা আর ধৈর্য দুটোই খরচ করে। যে সাইট দরকারি ফাইল একবার নামিয়ে জমিয়ে রাখে আর অফলাইনেও কাজ চালিয়ে যায়, সে ঠিক এই বাস্তবতার জন্য বানানো।

২ · তিনটি উপাদান — HTTPS, manifest আর ইনস্টলযোগ্যতা

HTTPS — বাধ্যতামূলক, ব্যতিক্রম শুধু localhost

Service worker প্রতিটি অনুরোধ বদলে দিতে পারে — তাই কেউ যদি পথের মাঝে (যেমন খোলা Wi-Fi-তে) একটি ক্ষতিকর service worker ঢুকিয়ে দিতে পারত, সেটি সাইট বন্ধ করার পরও মাসের পর মাস ব্যবহারকারীর সব অনুরোধ চুরি করত। এজন্য ব্রাউজার service worker শুধু secure context-এ চালায়: https:// দিয়ে আসা পাতা, অথবা ডেভেলপারের সুবিধার জন্য http://localhost আর http://127.0.0.1. HTTPS আর HSTS কেন জরুরি, তা পর্ব ৪৩-এ দেখেছেন।

Web app manifest — অ্যাপের পরিচয়পত্র

ইনস্টল হওয়ার পর অ্যাপটির নাম কী দেখাবে, আইকন কোনটি, খুললে কোন পাতা আসবে, ব্রাউজারের বার থাকবে কি না — এসব লেখা থাকে একটি JSON ফাইলে, যার নাম web app manifest. ফাইলটি পাতার <head>-এ যুক্ত করতে হয়:

<link rel="manifest" href="/manifest.webmanifest">
<meta name="theme-color" content="#0d6e4f">
<link rel="apple-touch-icon" href="/icons/192.png">   <!-- iPhone/iPad-এর হোম স্ক্রিন আইকন -->

{
  "name": "অফলাইন খাতা — খরচের হিসাব",
  "short_name": "খাতা",
  "start_url": "/?source=pwa",
  "scope": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0d6e4f",
  "lang": "bn",
  "icons": [
    { "src": "/icons/192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/512.png", "sizes": "512x512", "type": "image/png" },
    { "src": "/icons/maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ]
}

ইনস্টলযোগ্যতা — নিয়ম বদলায়, তাই সাবধানে

ব্রাউজার কখন “Install app” বা “হোম স্ক্রিনে যোগ করুন” প্রস্তাব দেবে, তার নিয়মকে বলে installability criteria. এখানে সতর্ক থাকুন — নিয়মগুলো ব্রাউজারভেদে আলাদা আর বছরে বছরে বদলেছে:

• Chrome/Edge (Chromium): HTTPS, আর একটি manifest যাতে name বা short_name, 192px ও 512px আইকন, start_url আর উপযুক্ত display আছে। আগে fetch handler-সহ service worker-ও বাধ্যতামূলক ছিল; সাম্প্রতিক সংস্করণে সেই শর্ত তুলে নেওয়া হয়েছে, আর এখন মেনু থেকে প্রায় যেকোনো সাইটই অ্যাপ হিসেবে যোগ করা যায়। তবে অফলাইনে চলার জন্য service worker তো লাগবেই।
• Safari (iPhone/iPad): কোনো স্বয়ংক্রিয় প্রস্তাব নেই; ব্যবহারকারীকে নিজে Share → “Add to Home Screen” চাপতে হয়। Manifest পড়ে, তবে আইকনের জন্য apple-touch-icon দেওয়া এখনো নিরাপদ। macOS-এ Safari 17 থেকে “Add to Dock”.
• Firefox: Android-এ হোম স্ক্রিনে যোগ করা যায়; ডেস্কটপে দীর্ঘদিন ইনস্টলের সুবিধা ছিল না।

তাই কোনো tutorial বা AI-এর “এগুলো থাকলেই ইনস্টল হবে” তালিকা কোন বছরের, কোন ব্রাউজারের — যাচাই করুন; সবচেয়ে বিশ্বাসযোগ্য হলো DevTools-এর Application → Manifest প্যানেল।

নিচের কোডে একটি ছোট manifest যাচাইকারী বানানো হয়েছে, যা প্রচলিত শর্তগুলো পরখ করে। সাথে দেখুন feature detection-এর একটি সূক্ষ্ম ফাঁদ — এই কোড-বক্সের sandbox-এ service worker-এর অনুমতি নেই:

function checkManifest(m) {
  const problems = [];
  if (!m.name && !m.short_name) problems.push("name বা short_name নেই");
  if (!m.start_url) problems.push("start_url নেই");
  if (!["standalone", "fullscreen", "minimal-ui"].includes(m.display))
    problems.push(`display "${m.display}" — অ্যাপের মতো খুলবে না`);
  const sizes = (m.icons ?? []).flatMap((icon) => icon.sizes.split(" "));
  for (const s of ["192x192", "512x512"]) if (!sizes.includes(s)) problems.push(`${s} আইকন নেই`);
  if ((m.short_name ?? m.name ?? "").length > 12) problems.push("ছোট নাম ১২ অক্ষরের বেশি");
  return problems.length ? problems.join("; ") : "ঠিক আছে";
}
const khata = { name: "অফলাইন খাতা", short_name: "খাতা", start_url: "/?source=pwa", display: "standalone",
  icons: [{ src: "/i/192.png", sizes: "192x192" }, { src: "/i/512.png", sizes: "512x512" }] };
console.log("খাতা:", checkManifest(khata));
console.log("দোকান:", checkManifest({ name: "Rahim Store Online", display: "browser",
  icons: [{ src: "/logo.png", sizes: "192x192" }] }));
console.log("navigator-এ আছে?", "serviceWorker" in navigator);
try { navigator.serviceWorker.register("/sw.js"); }
catch (e) { console.log("কিন্তু ব্যবহার করা গেল না:", e.name); }

৩ · Service worker-এর জীবনচক্র — register, install, activate

Service worker একটি আলাদা ফাইল — সাধারণত সাইটের মূলে /sw.js. পাতার কাজ শুধু ব্রাউজারকে বলা: “এই ফাইলটিকে আমার service worker হিসেবে নিবন্ধন করো।” এই নিবন্ধনের নাম register:

if ("serviceWorker" in navigator) {
  window.addEventListener("load", async () => {      // পাতা আগে লোড হোক, তারপর
    try {
      const reg = await navigator.serviceWorker.register("/sw.js");
      console.log("SW নিবন্ধিত, scope:", reg.scope);   // https://khata.example/
    } catch (err) {
      console.warn("SW নিবন্ধন ব্যর্থ — সাইট সাধারণভাবেই চলবে", err);
    }
  });
}

খেয়াল করুন তিনটি জিনিস। এক, পুরো কাজটি একটি if-এর ভেতরে — service worker না থাকলে সাইট সাধারণ ওয়েবসাইট হিসেবেই চলে। দুই, load-এর পর নিবন্ধন, যাতে প্রথম লোডের ব্যান্ডউইথে ভাগ না বসে। তিন, ফাইলটির অবস্থান ঠিক করে তার scope — কোন পাতাগুলো সে নিয়ন্ত্রণ করবে। /sw.js পুরো সাইট নিয়ন্ত্রণ করে; কিন্তু /js/sw.js ডিফল্টভাবে শুধু /js/-এর নিচের পাতা। (সার্ভার Service-Worker-Allowed header পাঠালে scope বাড়ানো যায়, তবে মূলে রাখাই সহজ।) এখানে “scope” মানে JavaScript-এর ভ্যারিয়েবলের scope নয় — URL-এর পরিধি।

এবার sw.js-এর ভেতরটা। Service worker কোনো DOM দেখে না, window নেই — তার global object self (একটি ServiceWorkerGlobalScope). পর্ব ৪২-এর Web Worker-এর মতোই এটি পাতার main thread-এর বাইরে চলে, কিন্তু উদ্দেশ্য আলাদা: Web Worker ভারী হিসাব সরিয়ে নেয় আর পাতার সাথে বাঁচে-মরে; service worker নেটওয়ার্কের দারোয়ান, একটি origin-এর সব ট্যাবের জন্য একটিই, আর পাতা বন্ধ থাকলেও event এলে ব্রাউজার তাকে জাগিয়ে তোলে। কাজ শেষে ব্রাউজার তাকে থামিয়েও দেয়, তাই global ভ্যারিয়েবলে কিছু জমানো নিরাপদ নয়।

const VERSION = "v3";
const SHELL = `khata-shell-${VERSION}`;          // সংস্করণ নামের ভেতরেই
const RUNTIME = "khata-runtime";
const SHELL_FILES = ["/", "/index.html", "/app.3f9a1c.css", "/app.8b2e7d.js",
                     "/offline.html", "/icons/192.png", "/manifest.webmanifest"];

self.addEventListener("install", (event) => {
  // সব ফাইল জমা না হওয়া পর্যন্ত install শেষ হবে না; একটি ব্যর্থ হলে পুরো install ব্যর্থ
  event.waitUntil(caches.open(SHELL).then((cache) => cache.addAll(SHELL_FILES)));
});

self.addEventListener("activate", (event) => {
  event.waitUntil((async () => {
    for (const name of await caches.keys()) {
      if (name !== SHELL && name !== RUNTIME) await caches.delete(name);   // পুরোনো সংস্করণ মোছা
    }
  })());
});

অ্যাপের যে ন্যূনতম কাঠামো — HTML, CSS, JavaScript, আইকন, অফলাইন পাতা — যা ছাড়া পর্দাই আঁকা যায় না, তাকে বলে app shell. Install-এর সময় এগুলো আগে থেকে জমিয়ে রাখাকে বলে precache. event.waitUntil(promise) ব্রাউজারকে বলে “এই Promise শেষ না হওয়া পর্যন্ত আমাকে থামিও না, আর এর ফল দিয়েই ঠিক করো ধাপটি সফল কি না।” এবার প্রথমবার সাইটে আসা একজন ব্যবহারকারীর দিক থেকে পুরো জীবনচক্রটি দেখুন:

navigator.serviceWorker.register("/sw.js")
// ব্রাউজার: ফাইল নামাও → parse করো → একবার উপর থেকে নিচে চালাও
// (addEventListener-গুলো এখানেই বসে)
// syntax error থাকলে register-এর Promise reject — সাইট সাধারণভাবে চলে

caches.open("khata-shell-v3")
  .then(c => c.addAll(["/", "/app.3f9a1c.css", "/offline.html", …]))
// ৭টির মধ্যে ১টিও 404 হলে → install ব্যর্থ, SW বাতিল
// পরের ভিজিটে ব্রাউজার আবার চেষ্টা করবে

caches.keys()  // ["khata-shell-v3", "khata-runtime"]
// প্রথম ভিজিটে মোছার কিছু নেই; পরের সংস্করণে v2-এর cache এখানে যাবে
// পুরোনো SW এখানে কোনো ট্যাব চালাচ্ছে না, তাই মোছা নিরাপদ

navigator.serviceWorker.controller   // null
// পাতাটি SW ছাড়াই লোড হয়েছিল — মাঝপথে নিয়ন্ত্রণ বদলায় না
// চাইলে activate-এ: self.clients.claim()  → এখনই নিয়ন্ত্রণ

self.addEventListener("fetch", (event) => {
  event.respondWith(caches.match(event.request) …)
});
// HTML, CSS, ছবি, fetch() — এই scope-এর সব অনুরোধ এখানে আসে
// নেটওয়ার্ক বন্ধ থাকলেও app shell cache থেকে খোলে

৪ · আপডেটের সমস্যা — waiting, skipWaiting আর “নতুন সংস্করণ আছে”

আপনি sw.js-এ একটি বাগ ঠিক করে নতুন সংস্করণ সার্ভারে তুললেন। ব্যবহারকারী পাতা রিফ্রেশ করলেন — অথচ পুরোনো আচরণই দেখছেন! কারণ: ব্রাউজার প্রতিটি পাতা খোলার সময় (আর অন্তত ২৪ ঘণ্টায় একবার) sw.js আবার নামিয়ে byte ধরে মিলিয়ে দেখে। এক byte-ও আলাদা হলে নতুন সংস্করণ install হয় — কিন্তু সাথে সাথে চালু হয় না। কেন, ধাপে ধাপে দেখুন:

1সোমবার: v2 চলছে, খাতার ৩টি ট্যাব খোলা2মঙ্গলবার: v3 সার্ভারে, একটি ট্যাব রিফ্রেশ3v3-এর install — নতুন cache তৈরি4v3 waiting — v2 এখনো সব ট্যাব চালায়5সব ট্যাব বন্ধ, বা skipWaiting → v3 active

এই “ব্যবহারকারী চাপলে তবেই আপডেট” প্যাটার্নটি কোডে এমন — পাতার দিকে নতুন সংস্করণ খোঁজা আর ব্যানার দেখানো, service worker-এর দিকে বার্তা পেলে skipWaiting:

// ---- পাতায় ----
const reg = await navigator.serviceWorker.register("/sw.js");
const offerUpdate = (worker) => {
  updateBar.hidden = false;                     // "নতুন সংস্করণ আছে — রিফ্রেশ করুন"
  updateBar.querySelector("button").onclick = () => worker.postMessage({ type: "SKIP_WAITING" });
};
if (reg.waiting && navigator.serviceWorker.controller) offerUpdate(reg.waiting);
reg.addEventListener("updatefound", () => {
  const nw = reg.installing;
  nw.addEventListener("statechange", () => {
    // controller থাকলে এটি আপডেট; না থাকলে প্রথম install — ব্যানার নয়
    if (nw.state === "installed" && navigator.serviceWorker.controller) offerUpdate(nw);
  });
});
let reloading = false;
navigator.serviceWorker.addEventListener("controllerchange", () => {
  if (!reloading) { reloading = true; location.reload(); }   // নতুন SW এল → নতুন পাতা
});

// ---- sw.js-এ ----
self.addEventListener("message", (event) => {
  if (event.data?.type === "SKIP_WAITING") self.skipWaiting();
});

৫ · Cache API আর fetch event — অনুরোধ ধরে উত্তর বানানো

Service worker-এর জমানো ফাইল থাকে Cache API-তে — ব্রাউজারের ভেতরের একটি সংরক্ষণাগার, যেখানে চাবি হলো একটি Request (মূলত URL) আর মান একটি Response. এটি ব্রাউজারের সাধারণ HTTP cache থেকে আলাদা: HTTP cache চলে সার্ভারের Cache-Control header দেখে, নিজের নিয়মে, যখন খুশি মুছে দেয়; Cache API পুরোপুরি আপনার নিয়ন্ত্রণে — আপনি না মুছলে (বা জায়গার অভাবে ব্রাউজার পুরো সাইটের storage না মুছলে) থেকে যায়। প্রধান method-গুলো সবই Promise ফেরত দেয়:

পর্ব ৩৫-এর একটি নিয়ম এখানে খুব জরুরি: Response-এর body পড়া যায় একবারই। Network থেকে উত্তর এলে আপনাকে দুটি কাজ করতে হয় — পাতাকে দেওয়া আর cache-এ রাখা। দুটোই body পড়ে। তাই একটি কপি বানাতে হয় response.clone() দিয়ে, body ছোঁয়ার আগেই:

async function cacheFirst(request) {
  const hit = await caches.match(request);
  if (hit) return hit;                                  // জমা আছে → network-এ যাই না
  const res = await fetch(request);
  if (res.ok) (await caches.open(RUNTIME)).put(request, res.clone());   // কপি cache-এ
  return res;                                           // আসলটি পাতায়
}

async function networkFirst(request, fallbackUrl) {
  try {
    const res = await fetch(request);
    if (res.ok) (await caches.open(RUNTIME)).put(request, res.clone());
    return res;
  } catch (err) {                                       // network error = অফলাইন
    const hit = await caches.match(request);
    if (hit) return hit;
    if (fallbackUrl) return caches.match(fallbackUrl);  // যেমন /offline.html
    throw err;
  }
}

এবার এই function-গুলোকে fetch event-এ জোড়া দিন। একটি service worker-এ সাধারণত একটিই fetch listener থাকে, যা অনুরোধের ধরন দেখে রাস্তা ঠিক করে দেয় — পোস্ট অফিসের বাছাই-টেবিলের মতো:

self.addEventListener("fetch", (event) => {
  const req = event.request;
  const url = new URL(req.url);
  if (req.method !== "GET") return;                    // POST/PUT/DELETE: ছুঁই না → সরাসরি network
  if (url.origin !== location.origin) return;          // অন্য সাইটের ফাইল: ব্রাউজারের হাতে
  if (url.pathname.startsWith("/api/pay")) return;     // পেমেন্ট: network-only
  if (req.mode === "navigate")                          // পুরো পাতা খোলা
    return event.respondWith(networkFirst(req, "/offline.html"));
  if (url.pathname.startsWith("/api/products"))
    return event.respondWith(staleWhileRevalidate(event));   // অংশ ৬
  if (url.pathname.startsWith("/api/")) return event.respondWith(networkFirst(req));
  event.respondWith(cacheFirst(req));                  // বাকি সব: hashed static ফাইল
});

return করে চলে যাওয়া (respondWith না ডাকা) মানে “আমি এতে নেই” — অনুরোধটি এমনভাবে যায় যেন service worker নেই। এবার একটি অনুরোধের চারটি সম্ভাব্য পথ পাশাপাশি দেখুন — দুটি strategy, অনলাইন আর অফলাইন অবস্থায়:

SW → cache.match()  → পাওয়া গেল → পাতায়   (১–৫ ms, ০ byte ডেটা খরচ)
network-এ অনুরোধ যায়ইনি — অনলাইন থাকলেও
cache-এ না থাকলে: network → clone() cache-এ → পাতায়

SW → cache.match()  → পাওয়া গেল → পাতায়
অফলাইন কি না, টেরই পাওয়া গেল না — app shell এভাবেই খোলে
cache-এ না থাকলে: fetch() → TypeError → পাতায় network error

SW → fetch()  → 200 OK → res.clone() cache-এ → আসলটি পাতায়
ব্যবহারকারী সবসময় সর্বশেষ খবর পান
cache-এ এখন একটি ব্যাকআপ কপি রইল

SW → fetch()  → TypeError (Failed to fetch)
   → catch → cache.match()  → গতবারের কপি পাতায়
পাতা দেখাবে: “অফলাইন — সর্বশেষ আপডেট গতকাল রাত ৯টা”
কপিও না থাকলে (পুরো পাতা হলে) → /offline.html

অফলাইন পাতাটি নিজেও precache করা থাকতে হবে, আর এর ভেতরের সব কিছু (CSS, ছবি) হয় precache করা, নয়তো পাতার ভেতরেই লেখা:

<!doctype html>
<html lang="bn">
<meta charset="utf-8"><meta name="viewport" content="width=device-width">
<title>অফলাইন — খাতা</title>
<style>body{font-family:sans-serif;text-align:center;padding:3rem 1rem}</style>
<h1>আপনি এখন অফলাইনে</h1>
<p>এই পাতাটি আগে খোলা হয়নি, তাই ফোনে জমা নেই।</p>
<p>আপনার খাতার আগের হিসাব আর নতুন খরচ যোগ করা অফলাইনেও চলবে।</p>
<p><a href="/">খাতায় ফিরে যান</a> · <button onclick="location.reload()">আবার চেষ্টা করুন</button></p>

৬ · Caching strategy — কোনটি কখন

Service worker-এর আসল দক্ষতা কোড লেখা নয়, প্রতিটি ধরনের অনুরোধের জন্য সঠিক নিয়ম বাছাই। পাঁচটি প্রচলিত caching strategy:

তৃতীয়টির নামের অর্থ: “stale” (বাসি) কপি এখনই দাও, “while revalidate” — একই সময়ে পেছনে নতুন কপি যাচাই করে আনো। পণ্যের তালিকার ক্ষেত্রে এটি চমৎকার: ক্রেতা অ্যাপ খুলেই তালিকা দেখেন, আর দাম এক-আধ ঘণ্টা পুরোনো হলেও ক্ষতি নেই, কারণ অর্ডারের সময় দাম ঠিক করবে সার্ভার। ধাপে ধাপে দেখুন:

1const hit = await cache.match(req);2const update = fetch(req).then(res => { cache.put(req, res.clone()); return res; });3event.waitUntil(update.catch(() => {}));4return hit ?? update;   // পাতা পায় hit5// ... পরের বার অ্যাপ খুললে: cache.match → নতুন দাম

পুরো ধারণাটি চালিয়ে দেখুন। আসল Cache API আর service worker এই কোড-বক্সে চলে না (অংশ ২), তাই নিচের কোডে cache হলো একটি সাধারণ Map, আর network একটি নকল async function, যাকে ইচ্ছামতো “অফলাইন” করা যায়। Strategy-র যুক্তি হুবহু একই:

const cache = new Map([["/app.css", "app.css v1"], ["/api/products", "চাল ৭০৳ (গতকাল)"]]);
let online = true;
const netGet = async (url) => { if (!online) throw new TypeError("Failed to fetch");   // নকল network
  return url === "/api/products" ? "চাল ৭২৳ (আজ)" : `${url} (নেট থেকে)`; };
const fetchAndStore = async (url) => { const body = await netGet(url); cache.set(url, body); return body; };
const cacheFirst = async (url) =>
  cache.has(url) ? `${cache.get(url)} ← cache` : `${await fetchAndStore(url)} ← network`;
const networkFirst = (url) => fetchAndStore(url).then((body) => `${body} ← network`,
  () => `${cache.get(url) ?? "offline.html"} ← cache (অফলাইন)`);          // ব্যর্থ হলে cache
function staleWhileRevalidate(url) {
  const update = fetchAndStore(url).catch(() => {});        // পেছনে চলবে, অপেক্ষা নয়
  return { now: `${cache.get(url) ?? "(খালি)"} ← cache`, update };
}
(async () => {
  console.log(await cacheFirst("/app.css"), "|", await cacheFirst("/logo.png"));
  const swr = staleWhileRevalidate("/api/products"); console.log("এখনই:", swr.now);
  await swr.update; console.log("পরের বারের জন্য cache-এ:", cache.get("/api/products"));
  online = false; console.log(await networkFirst("/api/products"), "|", await networkFirst("/news"));
  try { await caches.open("v1"); console.log("আসল Cache API চলছে"); }
  catch (e) { console.log("আসল Cache API এখানে বন্ধ:", e.name); }
})();

৭ · অফলাইন ডেটা — IndexedDB, Background Sync আর Push

Cache API ফাইলের জন্য, IndexedDB ডেটার জন্য

অফলাইনে লেখা ১৫টি খরচ কোথায় থাকবে? Cache API-তে থাকে Request→Response জোড়া — ফাইল আর API উত্তরের জন্য উপযুক্ত, কিন্তু ব্যবহারকারীর নিজের তৈরি record খোঁজা, বদলানো বা গোনার জন্য নয়। সেই কাজের জন্য ব্রাউজারের ডেটাবেস IndexedDB (পর্ব ৪০), যা পাতা আর service worker দুই জায়গা থেকেই ব্যবহার করা যায়। localStorage service worker-এ নেই, কারণ সেটি synchronous. এই নকশাকে বলে offline-first: অ্যাপ সবসময় আগে স্থানীয় ডেটাবেসে লেখে আর সেখান থেকে পড়ে, সার্ভারের সাথে মেলানো হয় পরে, সুযোগমতো।

জায়গা কিন্তু অসীম নয়। প্রতিটি origin-এর একটি storage quota আছে — ব্রাউজারভেদে আলাদা, সাধারণত ডিস্কের খালি জায়গার একটি অংশ। await navigator.storage.estimate() জানায় কত ব্যবহার হয়েছে আর কত পাওয়া যাবে। জায়গা কমলে ব্রাউজার কম ব্যবহৃত সাইটের পুরো storage মুছে দিতে পারে (navigator.storage.persist() দিয়ে না মোছার অনুরোধ করা যায়); Safari কিছুদিন ব্যবহার না হওয়া সাধারণ সাইটের storage মুছে ফেলে, হোম স্ক্রিনের অ্যাপ বাদে। তাই runtime cache-এ সীমা রাখুন (যেমন সর্বোচ্চ ৫০টি ছবি), আর গুরুত্বপূর্ণ ডেটা দ্রুত সার্ভারে পাঠান। বিস্তারিত পর্ব ৪০-এ।

অফলাইনে অর্ডার, অনলাইনে পাঠানো — Background Sync

পর্ব ৩৬-এ একটি প্রশ্ন রেখে আসা হয়েছিল: নেটওয়ার্কহীন জায়গায় একজন মাঠকর্মী ফর্ম জমা দিলেন — পাতা বন্ধ করে ফেললেও কীভাবে পরে পাঠানো যাবে? উত্তর Background Sync: পাতা কাজটি IndexedDB-র একটি “outbox”-এ রেখে service worker-কে বলে “সংযোগ পেলে আমাকে ডেকো।” সংযোগ ফিরলেই ব্রাউজার service worker-কে sync event দেয় — পাতা খোলা না থাকলেও। পাঠাতে ব্যর্থ হলে (Promise reject) ব্রাউজার পরে আবার চেষ্টা করে।

// ---- পাতায়: "অর্ডার দিন" চাপলে ----
await outbox.add({ id: crypto.randomUUID(), items, createdAt: Date.now() });  // IndexedDB (পর্ব ৪০)
showToast("অর্ডার জমা আছে — সংযোগ পেলে পাঠানো হবে");
const reg = await navigator.serviceWorker.ready;
if ("sync" in reg) {
  await reg.sync.register("send-orders");            // Chromium-এ
} else {
  window.addEventListener("online", sendOutbox);     // অন্য ব্রাউজারে: পাতা খোলা থাকলে
  if (navigator.onLine) sendOutbox();
}

// ---- sw.js ----
self.addEventListener("sync", (event) => {
  if (event.tag === "send-orders") event.waitUntil(sendOutbox());
});
async function sendOutbox() {
  for (const order of await outbox.getAll()) {
    const res = await fetch("/api/orders", { method: "POST",
      headers: { "Content-Type": "application/json", "Idempotency-Key": order.id },
      body: JSON.stringify(order) });
    if (!res.ok) throw new Error(`HTTP ${res.status}`);   // reject → ব্রাউজার পরে আবার চেষ্টা করবে
    await outbox.delete(order.id);
  }
}

তিনটি সতর্কতা। এক, Background Sync এখন পর্যন্ত শুধু Chromium-ভিত্তিক ব্রাউজারে (Chrome, Edge, Samsung Internet, Opera) আছে; Firefox আর Safari-তে নেই — তাই "sync" in reg দেখে online event-এর বিকল্প পথ রাখা বাধ্যতামূলক। দুই, প্রতিটি অর্ডারের সাথে Idempotency-Key — sync বারবার চলতে পারে, আর একই অর্ডার দুবার যাওয়া চলবে না (পর্ব ৩৫-এর idempotent ধারণা)। তিন, navigator.onLine সত্য মানেই ইন্টারনেট আছে, এমন নয় — প্রমাণ শুধু সফল fetch.

Push notification — পাতা বন্ধ, তবু খবর

Service worker-এর আরেকটি ক্ষমতা হলো সার্ভার থেকে বার্তা পাওয়া, যখন সাইটের কোনো ট্যাব খোলা নেই। এর জন্য দুটি API একসাথে কাজ করে: Push API বার্তা পৌঁছায়, আর Notification API পর্দায় দেখায় (Notification-এর মূল কথা পর্ব ৪১-এ)। পথটি এমন: ব্যবহারকারী অনুমতি দিলে ব্রাউজার তার নিজের push service-এর (Chrome-এ Google-এর, Firefox-এ Mozilla-র, Safari-তে Apple-এর) একটি ঠিকানা দেয় — subscription. আপনি সেটি নিজের সার্ভারে রাখেন। পরে সার্ভার সেই ঠিকানায় এনক্রিপ্ট করা বার্তা পাঠায়, push service সেটি ফোনে পৌঁছে দেয়, আর ব্রাউজার আপনার service worker-কে জাগিয়ে push event দেয়। আপনার সার্ভার যে আসল প্রেরক, তা প্রমাণ করতে একজোড়া key লাগে — VAPID key; public key যায় subscribe-এর সময়, private key থাকে শুধু সার্ভারে।

// ---- পাতায়: "অর্ডারের খবর পেতে চাই" বোতামে চাপ দেওয়ার পর — পাতা খোলামাত্র নয় ----
if (await Notification.requestPermission() === "granted") {
  const sub = await reg.pushManager.subscribe({
    userVisibleOnly: true,                       // প্রতিটি push-এ দৃশ্যমান notification দেখাতে হবে
    applicationServerKey: VAPID_PUBLIC_KEY,      // public key — গোপন নয়
  });
  await fetch("/api/push/subscribe", { method: "POST",
    headers: { "Content-Type": "application/json" }, body: JSON.stringify(sub) });
}

// ---- sw.js ----
self.addEventListener("push", (event) => {
  const msg = event.data?.json() ?? { title: "অফলাইন খাতা", body: "নতুন খবর আছে" };
  event.waitUntil(self.registration.showNotification(msg.title, { body: msg.body, icon: "/icons/192.png" }));
});
self.addEventListener("notificationclick", (event) => {
  event.notification.close();
  event.waitUntil(clients.openWindow("/orders"));
});

সমর্থনের অবস্থা সাবধানে বলা দরকার। Chrome, Edge আর Firefox ডেস্কটপ ও Android-এ বহু বছর ধরে web push দেয়। Safari macOS-এ (Ventura থেকে) standard web push দেয়, আর iPhone/iPad-এ iOS/iPadOS 16.4 (২০২৩) থেকে — কিন্তু শুধু তখন, যখন ব্যবহারকারী সাইটটি হোম স্ক্রিনে যোগ করেছেন; সাধারণ Safari ট্যাবে নয়। আর ব্যবহারিক নিয়ম: অনুমতি চাইবেন কোনো অর্থবহ মুহূর্তে, ব্যবহারকারীর কাজের পর (“অর্ডার দিয়েছেন — ডেলিভারির খবর পেতে চান?”), পাতা খোলামাত্র নয়। একবার “Block” চাপলে আর জিজ্ঞেস করার সুযোগ থাকে না।

৮ · বাস্তবে — Workbox, DevTools, নিরাপত্তা আর PWA বনাম native অ্যাপ

নিজের কম্পিউটারে চালিয়ে দেখুন

উপরের sw.js, manifest.webmanifest, offline.html আর একটি সাধারণ index.html এক ফোল্ডারে রাখুন। ফাইলটি সরাসরি ডাবল-ক্লিক করে খুললে (file://) service worker চলবে না — একটি ছোট সার্ভার লাগবে:

cd khata-pwa
npx serve .                    # Node থাকলে — ঠিকানা দেখাবে, সাধারণত http://localhost:3000
# অথবা Python থাকলে:
python -m http.server 8000     # তারপর http://localhost:8000

এবার DevTools (F12) → Application প্যানেল খুলুন — PWA-র নিয়ন্ত্রণকক্ষ:

• Manifest: ব্রাউজার manifest কীভাবে পড়ল, আইকনগুলো, আর ইনস্টলযোগ্যতার সমস্যা থাকলে সতর্কবার্তা।
• Service workers: কোন সংস্করণ active, কোনটি waiting (পাশে “skipWaiting” লিংক)। Update on reload চালু রাখলে ডেভেলপমেন্টের সময় প্রতিটি রিফ্রেশে নতুন service worker সাথে সাথে চালু হয় — waiting-এর ঝামেলা ছাড়া। Offline চেকবক্স দিয়ে নেটওয়ার্ক বন্ধ করে দেখুন অ্যাপ টিকে থাকে কি না। Push আর Sync বোতাম দিয়ে event নকল করা যায়।
• Cache storage: প্রতিটি cache-এর নাম আর ভেতরের প্রতিটি উত্তর — khata-shell-v3-এ সত্যিই সব ফাইল আছে কি না।
• Storage → Clear site data: সব cache, IndexedDB আর service worker একসাথে মুছে “প্রথম ভিজিট” থেকে আবার শুরু।

Network tab-এ cache থেকে আসা উত্তরের পাশে লেখা থাকে “(ServiceWorker)”. আগে Lighthouse-এ একটি আলাদা “PWA” মূল্যায়ন ছিল; ২০২৪ সালে Lighthouse 12-এ সেটি সরিয়ে দেওয়া হয়েছে, তাই পুরোনো tutorial-এর “PWA score ১০০” লক্ষ্য এখন আর প্রযোজ্য নয়। ইনস্টলযোগ্যতা দেখুন Application → Manifest-এ, আর গতির জন্য Lighthouse-এর Performance অংশ।

Workbox — হাতে লেখার বদলে পরীক্ষিত library

এই পর্বের হাতে লেখা কোড ধারণা বোঝার জন্য। বাস্তব প্রজেক্টে precache-এর তালিকা বানানো (প্রতিটি build-এ ফাইলের নাম বদলায়!), cache-এর আকার সীমিত রাখা, পুরোনো cache মোছা, Background Sync না থাকলে বিকল্প — এসব বারবার নির্ভুল লেখা কঠিন। Google-এর Workbox library এগুলো তৈরি অবস্থায় দেয়, আর Vite-এর vite-plugin-pwa-এর মতো build টুল (পর্ব ৪৬) এর ওপর ভিত্তি করেই চলে:

import { precacheAndRoute } from "workbox-precaching";
import { registerRoute } from "workbox-routing";
import { NetworkFirst, StaleWhileRevalidate, CacheFirst } from "workbox-strategies";
import { ExpirationPlugin } from "workbox-expiration";

precacheAndRoute(self.__WB_MANIFEST);           // build টুল এখানে hash-সহ ফাইলের তালিকা বসায়
registerRoute(({ request }) => request.mode === "navigate", new NetworkFirst({ cacheName: "pages" }));
registerRoute(({ url }) => url.pathname.startsWith("/api/products"),
  new StaleWhileRevalidate({ cacheName: "products" }));
registerRoute(({ request }) => request.destination === "image",
  new CacheFirst({ cacheName: "images", plugins: [new ExpirationPlugin({ maxEntries: 50 })] }));

নিরাপত্তা — একটি খারাপ service worker পুরো সাইট আটকে দিতে পারে

Service worker ব্যবহারকারীর ফোনে থেকে যায় আর প্রতিটি অনুরোধ নিয়ন্ত্রণ করে। ভুল কোড — যেমন HTML-কে cache-first করে দেওয়া — মানে আপনি সার্ভারে যত নতুন সংস্করণই তুলুন, ব্যবহারকারী পুরোনো পাতাই দেখবেন, কারণ নতুন পাতা চাওয়ার অনুরোধ সার্ভারে পৌঁছাচ্ছেই না। সৌভাগ্যক্রমে sw.js-এর আপডেট-যাচাই সবসময় সার্ভারে যায়, তাই উদ্ধারের পথ আছে — একটি kill switch service worker:

self.addEventListener("install", () => self.skipWaiting());
self.addEventListener("activate", (event) => {
  event.waitUntil((async () => {
    for (const name of await caches.keys()) await caches.delete(name);   // সব cache মোছা
    await self.registration.unregister();                                 // নিজেকে সরিয়ে নেওয়া
    for (const client of await self.clients.matchAll({ type: "window" }))
      client.navigate(client.url);                                        // খোলা পাতাগুলো আবার লোড
  })());
});

একই ঠিকানায় (/sw.js) এটি তুললে ব্যবহারকারীর পরের ভিজিটে পুরোনো service worker সরে যায়। সার্ভার থেকে Clear-Site-Data: "storage" header পাঠানোও একটি বিকল্প। আরও নিয়ম: service worker ফাইলের ঠিকানা কখনো বদলাবেন না (sw-v2.js দিলে পুরোনো sw.js কারও ফোনে থেকে যেতে পারে); scope যতটুকু দরকার ততটুকু রাখুন; আর পর্ব ৪৩-এর XSS থেকে সাইট রক্ষা করুন — XSS দিয়ে আক্রমণকারী service worker নিবন্ধন করাতে পারলে ক্ষতি সাময়িক থাকে না।

PWA, native অ্যাপ আর Play Store

মাঝামাঝি একটি পথও আছে: Trusted Web Activity (TWA) দিয়ে একটি PWA-কে Android অ্যাপ হিসেবে মুড়ে Play Store-এ দেওয়া যায় — ভেতরে আসলে Chrome-এ আপনার সাইটই চলে, ঠিকানার বার ছাড়া। Bubblewrap-এর মতো টুল এই কাজ সহজ করে। বাস্তব উদাহরণ হিসেবে প্রায়ই নাম আসে Twitter Lite (২০১৭, এখন X-এর মোবাইল ওয়েব), Starbucks-এর অর্ডারের PWA আর ভারতের Flipkart Lite-এর (২০১৫) — এদের লক্ষ্য ছিল ঠিক আমাদের মতো ধীর নেটওয়ার্ক আর কম দামি ফোনের ব্যবহারকারী। প্রকাশিত বিভিন্ন “এত শতাংশ বেড়েছে” সংখ্যা কোম্পানির নিজস্ব দাবি; সংখ্যার চেয়ে নকশার শিক্ষাটি বেশি কাজের।

৯ · AI-এর যুগে — service worker-এ AI-এর চেনা ভুল

“আমার সাইটকে PWA বানিয়ে দাও” — AI এক মিনিটে manifest আর sw.js লিখে দেবে, আর প্রথম দিন সব ঠিকঠাক চলবে। সমস্যা ধরা পড়ে দ্বিতীয় deploy-এ: নতুন সংস্করণ কারও কাছে পৌঁছায় না, বা কেউ অন্যের তথ্য দেখেন। AI-এর লেখা কোডে বারবার দেখা ভুলগুলো:

AI-এর লেখা service worker — যাচাইয়ের চেকলিস্ট

• fetch handler শুধু GET আর নিজের origin ধরে; POST, পেমেন্ট, লগইন আর ব্যক্তিগত API-র পথ বাদ
• cache-এর নামে সংস্করণ আছে, আর activate-এ পুরোনো cache মোছা হয়
• শুধু res.ok উত্তর জমানো হয়, আর cache-এ রাখার আগে clone()
• HTML পাতা cache-first নয়; অফলাইন পাতা precache করা আর বাংলায়
• skipWaiting শুধু ব্যবহারকারীর সম্মতিতে, তারপর একবার reload
• Background Sync, Push-এর মতো API-র আগে feature detection আর বিকল্প পথ আছে
• DevTools-এ Offline চালু করে, আর দুবার deploy করে (আপডেট-পথ) নিজে পরীক্ষা করেছি; kill switch পরিকল্পনা জানা