Featured image of post Potensi dan Implementasi PWA (Progressive Web Apps) (Kekuatan Service Worker)
Frontend Web

Potensi dan Implementasi PWA (Progressive Web Apps) (Kekuatan Service Worker)

Menjelaskan secara menyeluruh mulai dari gambaran keseluruhan PWA, siklus hidup Service Worker, cache luring, hingga pemberitahuan Push.

1. Pendahuluan: Apa itu PWA?

Teknologi web telah mengalami evolusi dramatis selama beberapa dekade terakhir. Dimulai dari kumpulan tautan dokumen HTML statis, operasi DOM dinamis, komunikasi asinkron melalui Ajax, hingga munculnya SPA (Single Page Application), saat ini dimungkinkan untuk membangun aplikasi yang menawarkan pengalaman pengguna (UX) yang sebanding dengan atau bahkan melebihi aplikasi asli (native). Di garis depan evolusi ini adalah PWA (Progressive Web Apps).

Singkatnya, PWA adalah “Aplikasi web yang menggabungkan aksesibilitas web dengan kinerja tinggi dan UX dari aplikasi asli”. Dalam aplikasi web tradisional, hal yang wajar jika layar kesalahan (seperti layar permainan dinosaurus yang terkenal di Chrome) yang bertuliskan “Anda tidak terhubung ke internet” ditampilkan saat mengakses secara luring (offline). Namun, jika teknologi PWA diimplementasikan dengan benar, bahkan dalam keadaan luring, Anda dapat meluncurkan aplikasi, melihat konten yang di-cache, atau menyinkronkan data di latar belakang.

Artikel ini akan menjelaskan secara sangat rinci dan komprehensif mulai dari gambaran umum PWA, siklus hidup Service Worker yang merupakan intinya, strategi cache tingkat lanjut, integrasi dengan IndexedDB, hingga prospek masa depan.

2. Aplikasi Asli vs PWA

Saat mengembangkan aplikasi web, topik yang selalu diperdebatkan adalah “Apakah harus mengadopsi aplikasi asli atau PWA”. Dengan memahami secara mendalam kelebihan dan kekurangan masing-masing, Anda dapat membuat pilihan teknologi terbaik untuk proyek Anda.

2.1. Kekuatan dan Kelemahan Aplikasi Asli

Kekuatan terbesar dari aplikasi asli (aplikasi yang dikembangkan dengan Swift/Objective-C untuk iOS, Kotlin/Java untuk Android, dll.) adalah memiliki akses penuh ke API OS. Hal ini memungkinkan Anda untuk mengimplementasikan fitur-fitur canggih yang memanfaatkan kamera, GPS, Bluetooth, NFC, dan berbagai sensor secara maksimal. Selain itu, karena dioptimalkan untuk OS, kinerja renderingnya sangat tinggi, menjadikan aplikasi asli sangat menguntungkan untuk game yang sering menggunakan animasi kompleks dan grafik 3D.

Di sisi lain, aplikasi asli memiliki kelemahan (tantangan) utama sebagai berikut:

  • Biaya Pengembangan dan Kurva Pembelajaran: Anda perlu mempertahankan basis kode terpisah untuk iOS dan Android (meskipun dapat dikurangi dengan kerangka kerja lintas platform seperti React Native atau Flutter, ini tidak sepenuhnya nol).
  • Peninjauan Toko Aplikasi: Anda tidak dapat merilisnya tanpa melewati peninjauan di App Store dari Apple atau Google Play, dan saat memperbarui, Anda mungkin harus menunggu peninjauan selama beberapa hari.
  • Hambatan Akuisisi Pengguna: Proses membuka toko aplikasi, mencari, mengunduh, dan menginstal sangat merepotkan (friksi) bagi pengguna.

2.2. Tantangan yang Diselesaikan oleh PWA

PWA bertujuan untuk mengatasi kelemahan aplikasi asli sambil memanfaatkan keunggulan web.

  • Satu Sumber Multi Penggunaan: Basis kode tunggal yang dikembangkan dengan teknologi standar web yaitu HTML, CSS, dan JavaScript dapat berjalan di semua perangkat (ponsel cerdas, tablet, desktop) yang dilengkapi browser.
  • Pembaruan Instan Tanpa Peninjauan: Karena PWA hanyalah sebuah situs web, ia tidak perlu melewati peninjauan toko aplikasi. Hanya dengan memperbarui file di server, pengguna selalu dapat menggunakan versi terbaru.
  • Pengalaman Mulus Tanpa Instalasi: Pengguna dapat mulai menggunakan aplikasi hanya dengan mengakses URL. Jika mereka menyukainya, mereka dapat “Tambahkan ke Layar Beranda (Install)”, yang memungkinkan peluncuran dari ikon aplikasi seperti aplikasi asli.
  • Dapat Dibagikan Melalui Tautan: Kemampuan untuk membagikan layar atau keadaan tertentu sebagai URL adalah senjata ampuh yang unik untuk web.

Tentu saja, PWA juga memiliki batasan. Khususnya di lingkungan iOS (Safari), implementasi API web seringkali tertinggal karena kebijakan Apple, seperti dukungan pemberitahuan Push yang tidak memadai hingga saat ini, atau pembatasan ketat pada operasi latar belakang. Namun, Safari baru-baru ini memperkuat dukungan PWA-nya, dan kesenjangan tersebut secara bertahap semakin sempit.

3. Tiga Pilar Pembentuk PWA

Untuk mewujudkan PWA, tiga elemen teknologi utama berikut diperlukan.

3.1. HTTPS (Komunikasi Aman)

Fitur canggih PWA (Service Worker, Push Notification, Geolocation, dll.) hanya berfungsi di lingkungan HTTPS karena alasan keamanan (lingkungan pengembangan lokal localhost diperbolehkan sebagai pengecualian). Ini untuk mencegah fitur-fitur tersebut diubah atau disalahgunakan oleh pihak ketiga yang berniat jahat melalui serangan man-in-the-middle.

3.2. Manifes Aplikasi Web

Manifes Aplikasi Web (manifest.json) adalah file JSON yang menyediakan metadata tentang aplikasi web kepada browser. Ini mendefinisikan ikon aplikasi, nama, warna tema, mode tampilan, dan mengontrol tampilan agar menyerupai aplikasi asli saat diinstal pada perangkat.

3.3. Service Worker

Service Worker adalah tongkat ajaib yang mengangkat PWA dari sekadar situs web menjadi sebuah “aplikasi”. Ini adalah lingkungan JavaScript yang dijalankan browser di latar belakang, beroperasi di utas yang terpisah dari halaman web. Ia dapat mencegat (proxy) permintaan jaringan, mengelola cache, atau menerima pemberitahuan Push.

4. Pengaturan Detail Manifes Aplikasi Web

Manifes Aplikasi Web dapat dikatakan sebagai wajah dari PWA. Ia menentukan tampilan dan perilaku saat pengguna menginstal aplikasi.

Berikut adalah contoh konfigurasi manifest.json yang umum.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "name": "Contoh Progressive Web App",
  "short_name": "Contoh PWA",
  "description": "Contoh komprehensif dari Progressive Web App.",
  "start_url": "/?source=pwa",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0055ff",
  "icons": [
    {
      "src": "/images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png",
      "purpose": "any maskable"
    },
    {
      "src": "/images/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "orientation": "portrait",
  "scope": "/"
}

Penjelasan Properti Utama

  • name dan short_name: Nama yang ditampilkan pada prompt saat instalasi dan di bawah ikon aplikasi di layar beranda. Karena ruang yang terbatas di layar beranda, short_name akan diprioritaskan.
  • start_url: URL yang pertama kali dimuat saat pengguna meluncurkan aplikasi dari ikon di layar beranda. Dengan menambahkan parameter pelacakan (mis. ?source=pwa), akses dari PWA dapat diidentifikasi oleh alat analisis akses.
  • display: Menentukan mode tampilan aplikasi.
    • standalone: Sepenuhnya menyembunyikan antarmuka browser (seperti bilah URL dan tombol kembali) dan menampilkannya seperti aplikasi asli. Ini adalah pengaturan yang paling direkomendasikan.
    • fullscreen: Menggunakan seluruh layar, menyembunyikan bahkan bilah status (ideal untuk aplikasi game atau video).
    • minimal-ui: Menampilkan hanya UI navigasi dasar.
    • browser: Menampilkannya sebagai tab browser biasa.
  • theme_color dan background_color: Menentukan warna tema aplikasi dan warna latar belakang layar splash saat startup.
  • icons: Larik gambar yang digunakan sebagai ikon aplikasi. Untuk mendukung resolusi perangkat yang berbeda, disarankan untuk menyediakan beberapa ukuran (setidaknya 192x192 dan 512x512). Menentukan purpose: "maskable" akan mengoptimalkan pemotongan ikon di Android dan perangkat lainnya.

5. Inti dan Siklus Hidup Service Worker

Service Worker harus disebut sebagai “jantung” dari PWA. Berbeda dengan JavaScript yang dijalankan di dalam halaman web tradisional, ia tidak memiliki akses ke DOM. Sebaliknya, ia memediasi permintaan jaringan, memanipulasi cache, dan melakukan sinkronisasi latar belakang.

5.1. Siklus Hidup Service Worker

Service Worker memiliki siklus hidupnya sendiri yang independen dari halaman. Memahami siklus hidup ini secara akurat adalah kunci untuk mencegah masalah cache yang tak terduga (seperti layar tidak berubah meskipun telah diperbarui).

Diagram Mermaid berikut menunjukkan transisi status Service Worker.

  stateDiagram-v2
    direction TB
    "Telah Diurai" --> "Sedang Menginstal" : "Pendaftaran"
    "Sedang Menginstal" --> "Telah Terinstal (Menunggu)" : "Sukses"
    "Sedang Menginstal" --> "Berlebihan" : "Kesalahan"
    "Telah Terinstal (Menunggu)" --> "Sedang Mengaktifkan" : "Semua klien ditutup / skipWaiting()"
    "Sedang Mengaktifkan" --> "Telah Diaktifkan" : "Sukses"
    "Sedang Mengaktifkan" --> "Berlebihan" : "Kesalahan"
    "Telah Diaktifkan" --> "Berlebihan" : "Digantikan oleh SW baru"
  1. Parsed (Telah Diurai): Status saat browser telah mengunduh skrip Service Worker dan menyelesaikan penguraian sintaks.
  2. Installing (Sedang Menginstal): Status di mana peristiwa install dipicu. Fase ini terutama digunakan untuk meng-cache (Pre-caching) aset statis (HTML, CSS, JS, gambar, dll.) yang penting untuk pengoperasian aplikasi. Jika instalasi gagal (seperti gagal menyimpan cache), Service Worker akan dibuang.
  3. Installed / Waiting (Menunggu): Instalasi selesai, tetapi Service Worker lama masih berjalan aktif di tab lain, sehingga menunggu pergantian. Ini berlanjut ke fase berikutnya saat pengguna menutup semua tab dan membukanya kembali, atau dengan memanggil self.skipWaiting().
  4. Activating (Sedang Mengaktifkan): Status di mana peristiwa activate dipicu. Fase ini terutama digunakan untuk membersihkan, seperti menghapus cache tidak berguna yang dibuat oleh Service Worker lama.
  5. Activated (Telah Diaktifkan): Beroperasi penuh dan dapat mengontrol serta memproses peristiwa fetch dan push dari halaman.
  6. Redundant (Berlebihan): Status di mana instalasi gagal, aktivasi gagal, atau digantikan oleh Service Worker versi baru.

5.2. Pendaftaran Service Worker

Untuk menggunakan Service Worker, pertama-tama harus didaftarkan dari utas JavaScript utama.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// main.js atau di dalam <script> pada index.html
if ("serviceWorker" in navigator) {
  window.addEventListener("load", () => {
    navigator.serviceWorker
      .register("/sw.js", { scope: "/" })
      .then((registration) => {
        console.log("Pendaftaran PekerjaLayanan berhasil dengan cakupan: ", registration.scope);
      })
      .catch((error) => {
        console.error("Pendaftaran PekerjaLayanan gagal: ", error);
      });
  });
}

Yang penting di sini adalah ruang lingkup Service Worker. Secara default, ia hanya mencegat permintaan untuk direktori tempat file Service Worker berada dan di bawahnya. Artinya, /sw.js dapat menghubungkan permintaan ke / di seluruh situs, tetapi jika ditempatkan di /js/sw.js, ia hanya dapat menghubungkan permintaan di bawah /js/.

6. Panduan Lengkap Strategi Cache

Daya tarik terbesar Service Worker adalah dapat menghubungkan permintaan jaringan (peristiwa fetch) dan mengimplementasikan strategi cache sendiri. Perlu untuk menggunakan strategi cache yang tepat tergantung pada jenis sumber daya (gambar, respons API, HTML) dan persyaratan aplikasi.

6.1. Cache First (Utamakan Cache)

Ini adalah strategi paling mendasar dan cepat. Pertama-tama ia memeriksa cache, jika ada maka akan dikembalikan, dan jika tidak ada, ia akan mengambilnya dari jaringan, lalu menyimpan hasilnya di cache. Ini ideal untuk sumber daya statis yang jarang berubah, seperti file gambar dan font.

  flowchart TD
    "Halaman" -->|"1. Permintaan"| "Pekerja Layanan"
    "Pekerja Layanan" -->|"2. Periksa Cache"| "Cache"
    "Cache" -->|"3a. Cache Hit"| "Pekerja Layanan"
    "Pekerja Layanan" -->|"4a. Respons"| "Halaman"
    "Cache" -->|"3b. Cache Miss"| "Jaringan"
    "Jaringan" -->|"4b. Respons"| "Pekerja Layanan"
    "Pekerja Layanan" -->|"5b. Simpan ke Cache"| "Cache"
    "Pekerja Layanan" -->|"6b. Respons"| "Halaman"

6.2. Network First (Utamakan Jaringan)

Strategi ini memprioritaskan untuk selalu mendapatkan data terbaru. Pertama-tama ia mengirim permintaan ke jaringan, dan jika berhasil, hasilnya disimpan di cache dan dikembalikan ke halaman. Ia hanya kembali menggunakan cache jika komunikasi jaringan gagal (seperti saat luring). Ini cocok untuk respons API dan data artikel yang sering diperbarui.

  flowchart TD
    "Halaman" -->|"1. Permintaan"| "Pekerja Layanan"
    "Pekerja Layanan" -->|"2. Ambil"| "Jaringan"
    "Jaringan" -->|"3a. Sukses"| "Pekerja Layanan"
    "Pekerja Layanan" -->|"4a. Simpan ke Cache"| "Cache"
    "Pekerja Layanan" -->|"5a. Respons"| "Halaman"
    "Jaringan" -->|"3b. Kesalahan / Luring"| "Pekerja Layanan"
    "Pekerja Layanan" -->|"4b. Periksa Cache"| "Cache"
    "Cache" -->|"5b. Cache Hit"| "Pekerja Layanan"
    "Pekerja Layanan" -->|"6b. Respons Pengganti"| "Halaman"

6.3. Stale-while-revalidate (Mengembalikan Cache Lama Sambil Memperbarui di Latar Belakang)

Strategi modern dan sangat kuat yang menyeimbangkan kecepatan dan kesegaran. Saat ada permintaan, ia segera mengembalikan cache (data lama/basi) untuk menampilkan layar dengan cepat. Secara bersamaan, ia mengirim permintaan jaringan di latar belakang (while-revalidate) untuk mendapatkan data terbaru dan memperbarui cache. Pengguna akan melihat data terbaru pada kunjungan berikutnya.

  flowchart TD
    "Halaman" -->|"1. Permintaan"| "Pekerja Layanan"
    "Pekerja Layanan" -->|"2. Periksa Cache"| "Cache"
    "Cache" -->|"3. Cache Hit (Respons Cepat)"| "Pekerja Layanan"
    "Pekerja Layanan" -->|"4. Kembalikan Respons Basi"| "Halaman"
    "Pekerja Layanan" -.->|"5. Ambil (Latar Belakang)"| "Jaringan"
    "Jaringan" -.->|"6. Respons Jaringan"| "Pekerja Layanan"
    "Pekerja Layanan" -.->|"7. Perbarui Cache"| "Cache"

6.4. Cache Only / Network Only

  • Cache Only (Hanya Cache): Sepenuhnya mengembalikan respons hanya dari cache. Akan menjadi kesalahan jika tidak ada. Hanya digunakan untuk aset tertentu yang dijamin telah diunduh dengan aman sebelumnya.
  • Network Only (Hanya Jaringan): Mengirim permintaan ke jaringan tanpa melihat cache sama sekali. Digunakan untuk komunikasi yang tidak boleh di-cache, seperti API otentikasi atau permintaan POST.

7. Contoh Implementasi Service Worker (Penjelasan Kode)

Sekarang, mari kita lihat contoh implementasi aktual dari sw.js (file Service Worker) berdasarkan siklus hidup dan strategi cache yang disebutkan sebelumnya.

7.1. Acara Instalasi dan Pra-cache

Pada peristiwa install, shell aplikasi (HTML, CSS, JS dasar) di-cache sebelumnya. Hal ini memungkinkan kerangka aplikasi ditampilkan secara instan, bahkan saat kunjungan berikutnya atau saat luring.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// sw.js
const CACHE_NAME = "pwa-cache-v1";
const PRECACHE_URLS = [
  "/",
  "/index.html",
  "/css/style.css",
  "/js/app.js",
  "/images/logo.png",
  "/offline.html"
];

self.addEventListener("install", (event) => {
  console.log("[PekerjaLayanan] Acara instalasi");
  
  // Dengan memanggil self.skipWaiting(), status menunggu dilewati dan akan segera menjadi aktif.
  self.skipWaiting();

  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      console.log("[PekerjaLayanan] Melakukan pra-cache halaman luring");
      return cache.addAll(PRECACHE_URLS);
    })
  );
});

7.2. Acara Aktivasi dan Pembersihan Cache

Saat versi nama cache diubah (misalnya dari pwa-cache-v1 ke v2), cache lama yang tidak berguna harus dihapus untuk menghemat ruang penyimpanan. Ini dilakukan pada peristiwa activate.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

self.addEventListener("activate", (event) => {
  console.log("[PekerjaLayanan] Acara aktivasi");
  
  // self.clients.claim() segera mengambil alih kontrol semua halaman yang sedang dibuka.
  event.waitUntil(self.clients.claim());

  event.waitUntil(
    caches.keys().then((cacheNames) => {
      return Promise.all(
        cacheNames.map((cacheName) => {
          if (cacheName !== CACHE_NAME) {
            console.log("[PekerjaLayanan] Menghapus cache lama:", cacheName);
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

7.3. Penanganan Acara Ambil (Fetch)

Ini adalah contoh implementasi tingkat lanjut yang mencegat peristiwa fetch dan mengalihkan strategi berdasarkan jenis sumber daya permintaan. Ia mencabangkan proses sedemikian rupa sehingga gambar menggunakan Cache First, dan permintaan navigasi HTML menggunakan Network First dengan cadangan luring.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

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

  // Permintaan POST dan permintaan ke domain eksternal diteruskan ke jaringan
  if (request.method !== "GET") return;

  // Permintaan HTML (transisi halaman) menggunakan strategi Network First + cadangan luring
  if (request.mode === "navigate" || request.headers.get("accept").includes("text/html")) {
    event.respondWith(
      fetch(request)
        .then((response) => {
          return caches.open(CACHE_NAME).then((cache) => {
            cache.put(request, response.clone());
            return response;
          });
        })
        .catch(() => {
          // Jika terjadi kesalahan jaringan (luring), dapatkan dari cache, jika tidak ada kembalikan halaman luring khusus
          return caches.match(request).then((cachedResponse) => {
            return cachedResponse || caches.match("/offline.html");
          });
        })
    );
    return;
  }

  // Aset statis seperti gambar menggunakan strategi Cache First
  if (url.pathname.match(/\.(png|jpg|jpeg|gif|svg|css|js)$/)) {
    event.respondWith(
      caches.match(request).then((cachedResponse) => {
        if (cachedResponse) {
          return cachedResponse;
        }
        return fetch(request).then((networkResponse) => {
          return caches.open(CACHE_NAME).then((cache) => {
            cache.put(request, networkResponse.clone());
            return networkResponse;
          });
        });
      })
    );
    return;
  }

  // Permintaan API lainnya dan sejenisnya menerapkan Stale-while-revalidate
  event.respondWith(
    caches.match(request).then((cachedResponse) => {
      const fetchPromise = fetch(request).then((networkResponse) => {
        return caches.open(CACHE_NAME).then((cache) => {
          cache.put(request, networkResponse.clone());
          return networkResponse;
        });
      });
      // Jika cache tersedia, kembalikan terlebih dahulu, dan lanjutkan proses pengambilan di latar belakang. Jika tidak ada cache, tunggu fetchPromise.
      return cachedResponse || fetchPromise;
    })
  );
});

8. Integrasi dengan IndexedDB: Manajemen Data Tingkat Lanjut

API caches (Cache Storage) milik Service Worker sangat cocok untuk menyimpan seluruh respons HTTP (file HTML, gambar, CSS, dll.). Namun, ini mungkin tidak cukup untuk mengelola data terstruktur (seperti respons API dalam format JSON, data pengaturan pengguna, atau data teks yang diposting secara luring) yang ditangani oleh aplikasi.

Di sinilah IndexedDB berperan.

IndexedDB adalah database NoSQL asinkron dan transaksional yang tertanam di dalam browser. Ia dapat menyimpan data dalam kapasitas sangat besar dan memungkinkan pencarian indeks yang kompleks.

8.1. Mengapa Penyimpanan Cache Saja Tidak Cukup?

Misalnya, katakanlah Anda menambahkan tugas baru saat luring dalam aplikasi ToDo. Pada saat ini, sulit untuk menyimpan “permintaan POST penambahan tugas” itu sendiri di dalam Cache Storage. Untuk persyaratan seperti menyimpan tindakan saat luring dan mengirimkannya kembali saat kembali daring, perlu ada kerja sama di mana data tugas disimpan sementara di IndexedDB, lalu diambil dari database untuk dikirim ke API pada waktu sinkronisasi latar belakang (dijelaskan nanti).

8.2. Penggunaan IndexedDB dalam Service Worker

Dimungkinkan juga untuk mengakses IndexedDB dari dalam ruang lingkup Service Worker. Karena beroperasi langsung dengan API IndexedDB cenderung menghasilkan kode yang rumit, biasanya digunakan pustaka pembungkus ringan bernama idb yang disediakan oleh Google.

Dalam PWA dengan fungsi luring tingkat lanjut yang menyimpan daftar JSON artikel yang diambil dari API ke dalam IndexedDB dan bukan API cache untuk manajemen dan permintaan yang terperinci, IndexedDB ini memainkan peran penting.

9. Pemberitahuan Push dan Sinkronisasi Latar Belakang (Background Sync)

Fitur PWA yang paling mendekati aplikasi asli adalah pemberitahuan Push dan operasi latar belakang.

9.1. Web Push API

Web Push adalah mekanisme yang memungkinkan server meluncurkan Service Worker untuk mengirim pemberitahuan kepada pengguna bahkan ketika aplikasi tidak terbuka.

  1. Berlangganan (Subscribe): Meminta izin pengguna untuk pemberitahuan di sisi browser, lalu mendapatkan informasi langganan layanan Push (titik akhir dan kunci enkripsi) untuk disimpan di server internal.
  2. Kirim (Push): Server internal mengirimkan pesan ke layanan Push dari vendor browser (FCM atau layanan Pemberitahuan Push Apple).
  3. Terima (Acara Push): Saat layanan Push mengirim data ke perangkat, browser meluncurkan Service Worker di latar belakang dan memicu peristiwa push. Service Worker memanggil metode self.registration.showNotification() untuk menampilkan UI pemberitahuan asli dari OS.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

self.addEventListener("push", (event) => {
  const data = event.data ? event.data.json() : {};
  const title = data.title || "Ada pesan baru";
  const options = {
    body: data.body || "Silakan buka aplikasi untuk memeriksanya.",
    icon: "/images/icons/icon-192x192.png",
    badge: "/images/icons/badge.png",
  };

  event.waitUntil(self.registration.showNotification(title, options));
});

9.2. Sinkronisasi Latar Belakang (Background Sync)

Katakanlah seorang pengguna menekan tombol kirim pesan saat luring di dalam kereta bawah tanah. Aplikasi web biasa akan menghasilkan kesalahan, tetapi dengan menggunakan Background Sync API, browser akan memicu peristiwa sync ke Service Worker pada waktu yang tepat “saat koneksi jaringan pulih”.

Sisi aplikasi menyimpan data untuk sementara di IndexedDB saat luring, dan mendaftarkan tugas sinkronisasi dengan Service Worker (registration.sync.register('send-messages')). Kemudian, ketika pengguna kembali daring dan peristiwa sync terjadi, data diambil dari IndexedDB dan dikirim ke server. Ini memungkinkan pengguna untuk terus menggunakan aplikasi tanpa mengkhawatirkan status jaringan.

10. Masa Depan dan Tantangan PWA (Evolusi melalui Project Fugu)

PWA terus berevolusi hingga hari ini. Secara khusus, inisiatif bernama Project Fugu (Kemampuan Web) yang dipimpin oleh perusahaan seperti Google, Microsoft, dan Intel, semakin mengaburkan batas antara web dan aplikasi asli.

Tujuan Project Fugu adalah untuk memungkinkan akses yang aman dari web ke fungsi OS yang kuat, yang sebelumnya hanya diizinkan untuk aplikasi asli. Akibatnya, API baru seperti berikut sedang diimplementasikan secara berurutan di dalam browser.

  • Web Bluetooth API: Komunikasi langsung dengan perangkat IoT
  • Web USB API / Web Serial API: Koneksi ke perangkat keras khusus
  • File System Access API: Membaca dan menulis file langsung di sistem file lokal pengguna (penting untuk PWA IDE atau Editor)
  • Contact Picker API: Mengakses data kontak di perangkat
  • Web Share Target API: Mendaftarkan PWA sebagai tujuan dalam “Menu Berbagi” dari OS

Adapun tantangannya, situasi dukungan Apple (iOS/Safari) masih menjadi masalah. Apple mengambil sikap hati-hati terhadap banyak API Project Fugu, dengan mempertimbangkan keseimbangan antara privasi, keamanan, dan model bisnis App Store. Namun, memang benar bahwa Apple secara bertahap memperkuat dukungan PWA-nya sebagai tanggapan terhadap permintaan pengguna yang kuat, seperti dukungan Web Push di iOS 16.4.

Di masa depan pengembangan aplikasi web, PWA bukan lagi sekadar pilihan, melainkan pasti akan menjadi standar teknologi dasar yang wajib untuk memberikan pengalaman pengguna yang terbaik.

11. Penutup

Dalam artikel ini, kami telah memberikan penjelasan yang sangat mendalam mulai dari konsep dasar PWA, siklus hidup Service Worker yang kompleks, berbagai strategi cache, integrasi dengan IndexedDB, hingga tren terbaru dalam teknologi web.

Saat pertama kali bekerja dengan Service Worker, Anda mungkin merasa bingung dengan sifat asinkronnya atau perilaku cachenya. Namun, dengan memahami siklus hidup dengan benar dan memilih serta mengimplementasikan strategi cache yang tepat, Anda dapat membangun aplikasi web yang sangat cepat dan tangguh (resilien).

Pengalaman “bisa berjalan luring” tidak hanya sekadar fitur kenyamanan bagi pengguna, tetapi juga menciptakan kepercayaan dan ketertarikan yang mendalam terhadap aplikasi. Jangan ragu untuk mengadopsi teknologi PWA dalam proyek Anda dan temukan potensi web sepenuhnya.

comments powered by Disqus