Terkadang pekerja layanan yang bermasalah di-deploy,
lalu terjadi masalah.
Misalnya, pekerja layanan mungkin diuraikan pada saat pendaftaran dan berhasil menyelesaikan penginstalan.
Namun, kode yang berisi bug dalam peristiwa fetch dapat menyebabkannya tidak merespons permintaan,
sehingga halaman menjadi kosong. Kemungkinan lainnya adalah markup halaman di-cache secara agresif, dan pekerja layanan hanya menampilkan respons markup yang sudah tidak berlaku dari instance Cache untuk kunjungan berikutnya.
Ada banyak cara pekerja layanan dapat menjadi bumerang, dan itu masalah yang menakutkan di situs web produksi. Meski begitu, tidak semuanya hilang. Ada beberapa cara untuk memperbaiki situasi dan kembali ke jalur.
Men-deploy pekerja layanan tanpa pengoperasian
Yang biasanya diperlukan untuk menangani pekerja layanan yang berisi bug adalah dengan men-deploy pekerja layanan tanpa pengoperasian dasar yang diinstal dan diaktifkan langsung tanpa pengendali peristiwa fetch:
// sw.js
self.addEventListener('install', () => {
// Skip over the "waiting" lifecycle state, to ensure that our
// new service worker is activated immediately, even if there's
// another tab open controlled by our older service worker code.
self.skipWaiting();
});
self.addEventListener('activate', () => {
// Optional: Get a list of all the current open windows/tabs under
// our service worker's control, and force them to reload.
// This can "unbreak" any open windows/tabs as soon as the new
// service worker activates, rather than users having to manually reload.
self.clients.matchAll({
type: 'window'
}).then(windowClients => {
windowClients.forEach((windowClient) => {
windowClient.navigate(windowClient.url);
});
});
});
Pekerja layanan ini akan diinstal dan segera diaktifkan dengan memanggil
self.skipWaiting() di peristiwa install.
Secara opsional, kode tambahan dapat di-deploy dalam peristiwa activate untuk secara paksa memuat ulang tab terbuka lainnya dengan WindowClient yang dikontrol oleh pekerja layanan.
Sangat penting bahwa pekerja layanan tanpa pengoperasian tidak berisi pengendali peristiwa fetch.
Jika pekerja layanan tidak menangani permintaan,
permintaan tersebut akan melewati browser seolah-olah tidak ada pekerja layanan.
Setelah pekerja layanan tanpa pengoperasian di-deploy, pekerja layanan yang berisi bug tersebut dapat diperbaiki dan di-deploy sebagai update nanti.
Pendekatan ini berfungsi baik karena browser memiliki pengamanan yang kuat terhadap penempatan pekerja layanan di cache HTTP, dan karena browser melakukan pemeriksaan byte-demi-byte terhadap konten pekerja layanan untuk melakukan update. Setelan default ini memungkinkan deployment pengganti tanpa pengoperasian bagi pekerja layanan yang berisi bug untuk memperbaiki masalah dengan cepat.
Tindakan tambahan yang perlu diambil
Men-deploy pekerja layanan tanpa pengoperasian harus memadai untuk menetralkan pekerja layanan yang berisi bug, tetapi tindakan tambahan dapat diambil jika perlu.
Bagaimana jika Anda tidak mengetahui URL pekerja layanan yang lama?
Terkadang URL pekerja layanan yang diinstal sebelumnya tidak diketahui. Penyebabnya mungkin karena file memiliki beberapa versi (misalnya berisi hash dalam nama filenya). Dalam hal ini, mungkin sulit untuk men-deploy pekerja layanan tanpa pengoperasian yang cocok dengan URL setiap pekerja layanan lama yang mungkin terdaftar. Hal ini bertentangan dengan praktik terbaik, karena developer mungkin tidak akan mengingat setiap hash untuk setiap versi pekerja layanan yang di-deploy.
Untungnya, header permintaan HTTP yang berguna dikirim bersama dengan permintaan untuk skrip pekerja layanan: Service-Worker.
Di server web, periksa header ini dan cegat permintaan untuk menyajikan pekerja layanan tanpa pengoperasian.
Pencapaian ini bergantung pada server web dan stack backend yang digunakan. Oleh karena itu, baca dokumentasi bahasa yang relevan tentang cara melakukannya.
Untuk deployment pekerja layanan di masa mendatang, tetap gunakan nama aset tanpa versi (misalnya, sw.js).
Hal ini akan membuat segalanya menjadi lebih sederhana pada masa mendatang.
Setel header Clear-Site-Data
Beberapa browser akan membatalkan pendaftaran semua pekerja layanan untuk origin jika header respons Clear-Site-Data dengan nilai 'storage' ditetapkan.
Namun, ada beberapa hal yang perlu diperhatikan terkait pendekatan ini:
- Perlu diingat bahwa tindakan ini akan menghapus semua penyimpanan untuk origin yang terkait. Itu termasuk
localStorage, IndexedDB,sessionStorage, dan penyimpanan lainnya (tetapi bukan cache HTTP untuk asal). - Header ini tidak didukung di semua browser.
Karena tidak total dukungan untuk header ini, masalah tersebut tidak dapat diandalkan semata-mata untuk mengatasi masalah.
Oleh karena itu, sebaiknya lihat Clear-Site-Data sebagai ukuran yang perlu diambil selain men-deploy pekerja layanan tanpa pengoperasian.
Kerusakan tidak permanen
Namun, hal ini dapat menjadi hal yang menakutkan ketika pengalaman pengguna terganggu oleh pekerja layanan yang bugar—terutama untuk situs besar dan terkenal—tetapi kerusakannya bersifat sementara dan dapat dipulihkan.
Jika perlu men-deploy pekerja layanan tanpa pengoperasian untuk memperbaiki situasi, luangkan waktu setelah selesai untuk mencari tahu persis masalahnya. Di masa mendatang, pastikan pekerja layanan hanya menangani permintaan yang diharapkan. Sering melakukan pengujian dalam staging, dan hanya men-deploy update jika yakin.