Wawancara Frontend: Bagaimana Cara Memilih Antara Web Worker, SharedWorker, dan Service Worker?

Prompt dan skenario yang berlaku

Sebuah aplikasi analitik same-origin memiliki tiga persyaratan independen:

1. Mengurai CSV 200 MiB yang dipilih pengguna secara lokal sementara input dan rendering tetap responsif.
2. Berbagi satu WebSocket dan state langganan dalam memori di seluruh tab selama setidaknya satu tab tetap terbuka.
3. Membuka app shell dan laporan sukses terakhir secara offline, mengantrekan satu penyimpanan, dan mencoba ulang setelah konektivitas kembali.

Pilihlah antara Dedicated Worker, SharedWorker, dan Service Worker untuk setiap persyaratan. Jelaskan kepemilikan, masa pakai, komunikasi, persistensi, pembatalan dan penanganan kegagalan, fallback peramban, batasan keamanan, dan validasi.

Berkas 200 MiB, WebSocket tunggal, dan penyimpanan offline adalah asumsi wawancara, bukan target produk universal. Pertanyaan ini cocok untuk peran frontend senior, platform Web, dan arsitektur frontend. Keterampilan intinya adalah eksekusi peramban dan pemilihan platform Web, sehingga kategorinya adalah frontend.

Apa yang dievaluasi oleh pewawancara

Pertama, dapatkah kandidat memilih berdasarkan siapa yang memiliki pekerjaan tersebut, berapa lama pekerjaan tersebut harus hidup, dan halaman mana yang terpengaruh alih-alih menyebut setiap thread latar belakang sebagai Web Worker? Jawaban yang kuat menetapkan komputasi milik halaman ke Dedicated Worker, state multi-halaman same-origin sementara ke SharedWorker, serta proxy jaringan berlingkup, caching, dan pekerjaan latar belakang berbasis peristiwa ke Service Worker.

Kedua, dapatkah kandidat memisahkan threading dari persistensi? Memindahkan kode dari thread utama tidak secara otomatis mengurangi CPU, memori, atau I/O. Memori SharedWorker bukanlah durable state. Peramban dapat menghentikan Service Worker di antara peristiwa, jadi pekerjaan yang tertunda harus berada di penyimpanan yang tahan lama seperti IndexedDB.

Ketiga, dapatkah kandidat mengukur biaya pengiriman pesan? Structured cloning biasanya menyalin data. Sebuah ArrayBuffer dapat ditransfer sehingga kepemilikannya berpindah tanpa salinan byte-demi-byte lainnya, tetapi buffer pengirim menjadi terlepas (detached). Penanganan CSV besar juga memerlukan chunking, progres, backpressure, dan pembatalan.

Keempat, dapatkah kandidat memberikan fallback yang benar? SharedWorker telah mencapai Baseline 2026 dalam rilis peramban saat ini, tetapi perangkat lama dan beberapa implementasi mungkin tidak mendukungnya. Background Sync masih belum menjadi Baseline. Kebenaran sistem tidak boleh bergantung pada satu API opsional.

Kelima, dapatkah kandidat menguji kegagalan siklus proses? Satu klik alur utama (happy-path) saja tidak cukup. Refresh, penutupan tab terakhir, pembaruan Service Worker, restart offline, peristiwa sinkronisasi duplikat, kontaminasi cache, dan fallback peramban lama semuanya penting.

Pertanyaan untuk diklarifikasi terlebih dahulu

• Apakah penguraian CSV terjadi sesekali atau terus-menerus? Pekerjaan satu kali dapat membuat satu Dedicated Worker sesuai permintaan. Pekerjaan konkuren yang terus-menerus memerlukan worker pool dan antrean yang dibatasi, bukan satu thread baru per berkas.
• Haruskah seluruh input berada di memori? Lebih prioritaskan streaming atau input ber-chunk jika parser mendukungnya. Jika seluruh ArrayBuffer harus berpindah sekaligus, buat anggaran terpisah untuk byte mentah, string yang didekode, nilai yang diurai, dan indeks.
• Apakah semua tab benar-benar same-origin? SharedWorker memerlukan skema, host, dan port yang sama. Subdomain, iframe pihak ketiga, atau port pengembangan yang berbeda akan mengubah desain komunikasi.
• Apakah satu WebSocket merupakan pengoptimalan atau batasan kebenaran (correctness constraint)? Jika ini hanya menghemat koneksi, koneksi per-tab adalah fallback yang valid. Jika server hanya mengizinkan satu sesi, fallback memerlukan BroadcastChannel, pemilihan pemimpin (leader election), lease, dan pemulihan split-brain.
• Bolehkah penyimpanan offline mencoba ulang secara otomatis? Operasi yang sensitif atau berpotensi konflik mungkin memerlukan konfirmasi pengguna setelah halaman kembali. Percobaan ulang otomatis memerlukan kunci idempoten (idempotency key), durable state, dan backoff terbatas.
• Peramban lama dan mode privasi mana yang masuk dalam cakupan? Jawaban tersebut menetapkan batasan deteksi fitur dan fallback untuk SharedWorker, Background Sync, kuota penyimpanan, dan perilaku Service Worker.

Kerangka jawaban 30 detik

"Saya akan membagi persyaratan berdasarkan kepemilikan dan masa pakai. CSV 200 MiB adalah pekerjaan berat CPU milik halaman saat ini, jadi saya akan menggunakan Dedicated Worker, mengurai dalam bentuk chunk, melaporkan progres, mentransfer ArrayBuffer saat kepemilikan dapat dipindahkan, dan membatalkan secara kooperatif atau menghentikan worker. Saya akan menempatkan satu WebSocket lintas-tab same-origin dalam SharedWorker dan membiarkan setiap halaman berlangganan melalui MessagePort, dengan deteksi fitur dan fallback ke BroadcastChannel ditambah pemilihan pemimpin atau, jika dapat diterima, satu koneksi per tab. Saya akan menggunakan Service Worker untuk shell offline, cache laporan, dan percobaan ulang nanti karena Service Worker dapat mencegat permintaan dalam cakupannya dan menangani peristiwa latar belakang. Antrean disimpan di IndexedDB dengan idempotency key. Tanpa Background Sync, halaman akan mengosongkannya saat startup, masuk ke foreground, atau koneksi ulang. Saya akan menguji penutupan tab terakhir, restart offline, sinkronisasi duplikat, dan pembaruan Service Worker."

Pembahasan mendalam langkah demi langkah

Langkah 1: Pilih berdasarkan kepemilikan, cakupan, dan masa pakai

Tak satu pun dari ketiganya dapat memanipulasi DOM secara langsung. Dedicated Worker dan SharedWorker menjalankan pekerjaan JavaScript yang dibutuhkan oleh halaman. Service Worker adalah proxy jaringan berbasis peristiwa yang terdaftar pada origin dan path tertentu. Service Worker dapat menangani fetch, caching, Push, dan sinkronisasi latar belakang di peramban yang mendukung, tetapi ini bukan tempat yang baik untuk penguraian CSV yang harus berjalan terus-menerus selama beberapa menit.

Langkah 2: Isolasi penguraian CSV 200 MiB dalam Dedicated Worker

Buat Dedicated Worker sesuai kebutuhan (on demand) karena tugas tersebut hanya melayani halaman saat ini. Thread utama memiliki pemilihan berkas, UI progres, dan rendering hasil. Worker memiliki proses decoding, tokenisasi, inferensi tipe, dan agregasi. Worker tidak memiliki akses DOM, sehingga mengembalikan hasil melalui pesan.

Sketsa antarmuka ini mengabaikan tipe parser dan error. chunkBytes memberi tahu worker untuk memproses secara internal dalam batch 4 MiB; ini tidak berarti thread utama membuat salinan lain:

const parser = new Worker(
  new URL("./csv-parser.worker.js", import.meta.url),
  { type: "module" },
);

const jobId = crypto.randomUUID();
const buffer = await file.arrayBuffer();

parser.postMessage(
  { type: "parse", jobId, buffer, chunkBytes: 4 * 1024 * 1024 },
  [buffer],
);

parser.onmessage = ({ data }) => {
  if (data.jobId !== jobId) return;
  if (data.type === "progress") renderProgress(data.rows);
  if (data.type === "done") renderReport(data.summary);
};

cancelButton.onclick = () => {
  parser.postMessage({ type: "cancel", jobId });
};

Pembatalan dapat bersifat kooperatif atau paksa. Loop penguraian memeriksa flag pembatalan di batas chunk, melepaskan objek sementara, dan melaporkan state akhir. Jika worker mengalami hang atau parser tidak dapat memberikan jeda (yield), terminate() akan menghentikannya, tetapi setiap pekerjaan di dalam worker tersebut akan hilang. Oleh karena itu, pemroses multi-berkas yang berumur panjang memerlukan isolasi pekerjaan daripada satu shared worker yang tidak terdiferensiasi.

Langkah 3: Desain untuk penyalinan dan puncak memori

postMessage biasa menggunakan structured cloning. Di bawah asumsi sederhana di mana ArrayBuffer 200 MiB ada di pengirim dan penerima, byte mentah saja menempati sekitar 400 MiB. Itu belum termasuk backing store File, string yang didekode, objek baris, indeks, dan ruang bebas untuk garbage collection. Ini adalah derivasi wawancara, bukan jaminan memori peramban.

Menempatkan ArrayBuffer dalam daftar transfer akan memindahkan sumber daya memorinya ke worker dan melepaskan buffer pengirim, menghindari penyalinan byte tersebut. Jangan mentransfernya jika halaman masih membutuhkan aslinya dan kepemilikan belum dirancang. Jalur input besar yang lebih aman membaca Blob.stream() atau slice, mengirimkan chunk kecil, dan menerima statistik inkremental. Thread utama membatasi chunk yang sedang berjalan (in flight) dan mengirimkan chunk berikutnya hanya setelah ada konfirmasi (acknowledgment), yang menciptakan backpressure.

Shared memory bukanlah jalan pintas bawaan. SharedArrayBuffer memerlukan isolasi cross-origin dan memperkenalkan atomic, data race, dan keamanan penerapan yang lebih ketat. Jangan menambahkan kompleksitas tersebut sebelum pengukuran menunjukkan bahwa pesan biasa dan objek yang dapat ditransfer menjadi bottleneck.

Langkah 4: Simpan koneksi multi-tab same-origin dalam SharedWorker

SharedWorker cocok dengan prinsip “pertahankan satu instance bersama selama setidaknya satu halaman same-origin tetap terhubung.” Setiap tab membuka worker bernama yang sama di URL yang sama dan mendaftarkan langganan melalui MessagePort miliknya sendiri. Worker memiliki WebSocket, sekumpulan port, dan peta langganan dalam memori, lalu merutekan pesan server ke port yang berkepentingan.

const socketHub = new SharedWorker(
  new URL("./socket-hub.shared-worker.js", import.meta.url),
  { type: "module", name: "analytics-socket-hub" },
);

socketHub.port.start();
socketHub.port.postMessage({ type: "subscribe", reportId });
socketHub.port.onmessage = ({ data }) => applyLiveUpdate(data);

window.addEventListener("pagehide", () => {
  socketHub.port.postMessage({ type: "disconnect", reportId });
  socketHub.port.close();
});

Hanya konteks yang benar-benar same-origin yang dapat mengakses SharedWorker. Worker ini dapat tetap hidup selama halaman yang terbuka memegang referensi; setelah referensi terakhir ditutup, worker ini bukan lagi layanan latar belakang permanen. Kehilangan koneksi, keluarnya peramban, atau crash pada worker dapat menghapus peta langganan. Simpan kursor server yang harus bertahan secara persisten, atau biarkan setiap halaman mendeklarasikan ulang langganannya.

Langkah 5: Berikan fallback nyata untuk SharedWorker

Lakukan deteksi fitur pada SharedWorker. Tanpanya, tab dapat bertukar heartbeat dan peristiwa melalui BroadcastChannel, sementara Web Locks atau lease penyimpanan yang memiliki masa kedaluwarsa memilih satu pemimpin untuk memiliki WebSocket. Tab lain memilih pengganti setelah pemimpin ditutup. Server melakukan deduplikasi berdasarkan sesi dan ID peristiwa, sementara klien menolak pesan dari pemimpin lama menggunakan epoch monotonik untuk membatasi kerusakan akibat split-brain.

Fallback tersebut secara substansial jauh lebih kompleks daripada SharedWorker. Jika satu koneksi hanyalah pengoptimalan biaya, fallback paling sederhana yang benar adalah satu WebSocket per tab dengan idempotensi sisi server dan batas koneksi. Bangun pemilihan, pembaruan lease, deteksi kegagalan, dan injeksi kesalahan hanya jika batasan server yang ketat memang mewajibkan satu koneksi.

Langkah 6: Gunakan Service Worker untuk perilaku offline dan percobaan ulang

Service Worker terdaftar terhadap cakupan origin dan path tertentu dan dapat mencegat permintaan dari halaman yang dikontrolnya. App shell cocok dengan precaching berversi atau cache-first. Laporan terbaru sering kali cocok dengan network-first: perbarui Cache Storage saat respons jaringan berhasil dan kembalikan respons ter-cache terakhir yang berhasil saat terjadi kegagalan. Simpan antrean penyimpanan pengguna di IndexedDB, bukan di Cache Storage atau variabel global Service Worker.

Ini masih berupa sketsa antarmuka. Kode produksi harus memasukkan URL yang dapat di-cache ke dalam allowlist, memvalidasi respons, membuat versi cache, dan menulis penyimpanan ke IndexedDB sebelum menampilkan status “dalam antrean” (queued):

navigator.serviceWorker.register("/sw.js", { scope: "/" });

// sw.js
self.addEventListener("install", (event) => {
  event.waitUntil(cacheAppShell());
});

self.addEventListener("fetch", (event) => {
  const url = new URL(event.request.url);
  if (url.pathname.startsWith("/reports/")) {
    event.respondWith(networkFirstReport(event.request));
  }
});

self.addEventListener("sync", (event) => {
  if (event.tag === "retry-report-saves") {
    event.waitUntil(flushIndexedDbQueue());
  }
});

Background Sync hanya tersedia di beberapa peramban. Jika pendaftaran gagal atau API tidak ada, panggil pengosong antrean yang sama saat halaman dimulai, kembali ke foreground, atau menerima peristiwa online. Peristiwa konektivitas adalah pemicu percobaan ulang, bukan bukti keberhasilan; hanya respons server yang mengonfirmasi penyelesaian. Setiap penyimpanan menyimpan idempotency key, jumlah percobaan, dan waktu percobaan ulang berikutnya. Konflik akan masuk ke state peninjauan alih-alih menimpa data selamanya.

Langkah 7: Tangani masa pakai dan pembaruan Service Worker

Service Worker mengontrol halaman hanya setelah pengunduhan, penginstalan, masa tunggu, dan aktivasi. Setelah pendaftaran pertama, dokumen saat ini biasanya memerlukan navigasi lain sebelum menjadi terkontrol. Versi baru dapat terinstal dan menunggu halaman yang menggunakan versi lama ditutup. skipWaiting() dan clients.claim() dapat mengambil kontrol lebih cepat, tetapi halaman lama yang dipasangkan dengan worker baru dapat rusak jika protokolnya berbeda. Buat versi skema pesan dan cache yang sesuai.

Peramban dapat menghentikan worker di antara peristiwa dan memulainya kembali untuk peristiwa berikutnya. event.waitUntil() memperpanjang masa pakai yang terkait dengan Promise peristiwa saat ini; ini tidak membuat proses menjadi residen permanen. Pertahankan antrean, jumlah percobaan, dan idempotency key. Pemrosesan sinkronisasi harus dapat dilanjutkan dari rekaman mana pun dan menjalankan permintaan yang sama dua kali dengan aman.

Service Worker memerlukan konteks aman (secure context). HTTPS adalah persyaratan produksi, sedangkan localhost adalah pengecualian untuk pengembangan. Cakupan default dibatasi oleh path skrip. Verifikasi juga CSP worker-src, konten cache yang sensitif terhadap pengguna, isolasi logout, serta perilaku CORS dan kredensial untuk permintaan cross-origin.

Langkah 8: Validasi dengan matriks kegagalan

Uji Dedicated Worker dengan berkas 1 MiB dan 200 MiB, input yang salah format, dan pembatalan. Catat long task thread utama, penundaan input, throughput penguraian, puncak memori, dan waktu pelepasan setelah pembatalan. Bandingkan varian structured clone, transferable, dan chunked, lalu pilih berdasarkan bottleneck yang terukur.

Uji SharedWorker dengan dua langganan simultan, penutupan halaman pemimpin, penutupan halaman terakhir, fluktuasi jaringan, error worker, dan peramban tanpa SharedWorker. Pemeriksaan penerimaan mencakup jumlah koneksi server aktual, tidak ada jeda atau duplikasi pesan yang tak terduga, kontinuitas kursor setelah koneksi ulang, dan fallback yang menjaga kebenaran sistem.

Uji Service Worker pada kunjungan pertama, kunjungan ulang terkontrol, refresh offline, masa kedaluwarsa cache, pembaruan yang menunggu, penghentian paksa peramban, duplikasi sync, kuota penyimpanan habis, dan tidak adanya Background Sync. Gunakan idempotency key di endpoint penyimpanan untuk membuktikan bahwa percobaan minimal-satu-kali (at-least-once) tidak membuat penulisan duplikat. Verifikasi bahwa data pribadi yang di-cache tidak dapat diakses lintas pengguna.

Contoh jawaban berkualitas tinggi

“Saya akan memulai dari siapa yang memiliki tugas tersebut, berapa lama tugas tersebut harus hidup, dan apakah tugas tersebut melakukan proxy jaringan. CSV 200 MiB hanya melayani halaman saat ini dan berat di sisi CPU, jadi saya akan menggunakan Dedicated Worker. Thread utama menangani pemilihan berkas dan UI; worker mengurai chunk, melaporkan progres, dan memeriksa pembatalan di antara chunk. Pengiriman pesan biasa menggunakan structured clone. Jika buffer 200 MiB lengkap ada di kedua sisi, asumsi wawancara menempatkan byte mentah saja mendekati 400 MiB, jadi saya akan melakukan benchmark pada ArrayBuffer yang dapat ditransfer yang memindahkan kepemilikan atau mengalirkan (stream) chunk dengan jumlah in-flight yang dibatasi.

Saya akan menyimpan satu WebSocket lintas-tab dalam SharedWorker. Setiap halaman harus benar-benar same-origin dan mendeklarasikan ulang langganan melalui MessagePort miliknya. Worker hanya menyimpan status koneksi dan perutean yang dapat direkonstruksi. Ini bukan persistensi; state dapat hilang setelah halaman terakhir ditutup, peramban keluar, atau worker mengalami crash. Saya akan melakukan deteksi fitur. Jika satu koneksi hanyalah optimasi, fallback-nya adalah satu koneksi per tab. Jika itu adalah batasan mutlak, saya akan menggunakan BroadcastChannel ditambah pemilihan berbasis lease, dengan epoch dan ID peristiwa untuk menangani split-brain dan duplikasi.

Saya akan menggunakan Service Worker untuk shell offline, laporan terbaru, dan penyimpanan di kemudian waktu. Service Worker mencegat permintaan dalam cakupan: precaching berversi untuk shell dan network-first dengan fallback cache untuk laporan. Penyimpanan ditulis ke IndexedDB dengan idempotency key sebelum background sync didaftarkan. Tanpa Background Sync, startup, masuk ke foreground, atau koneksi ulang memanggil pengosong antrean yang sama. Karena Service Worker dapat berhenti di antara peristiwa, antrean tidak boleh hanya berada di variabel global; setiap eksekusi memulihkan durable state dan mengaitkan pekerjaan saat ini dengan waitUntil().

Terakhir, saya akan memvalidasi long task thread utama dan memori, jumlah koneksi WebSocket sebenarnya dan perilaku koneksi ulang, restart offline dan sinkronisasi duplikat, ditambah masa tunggu pembaruan Service Worker, fallback peramban lama, isolasi cache per pengguna, serta batasan HTTPS dan CSP.”

Kesalahan umum

• Menggunakan Service Worker sebagai thread komputasi yang berjalan lama → peramban dapat menghentikannya di antara peristiwa atau selama pekerjaan yang panjang → gunakan Dedicated Worker untuk komputasi halaman dan cadangkan Service Worker untuk pekerjaan jaringan berbasis peristiwa.
• Mengirim objek 200 MiB dengan postMessage tanpa mengukur memori → structured clone dan hasil yang diurai dapat hidup berdampingan pada puncak penggunaan memori yang besar → bandingkan jalur transferable, chunked, dan streaming lalu ukur puncaknya.
• Mengasumsikan worker mana pun menjamin aplikasi yang responsif → CPU, garbage collection, dan serialisasi masih memakan waktu → ukur long task thread utama, throughput, dan ukuran batch pesan.
• Memperlakukan memori SharedWorker sebagai state yang andal → memori dapat hilang setelah referensi terakhir ditutup atau peramban keluar → hanya simpan runtime state yang dapat direkonstruksi dan simpan kursor serta antrean penting secara persisten.
• Mengabaikan persyaratan exact same-origin → skema, host, atau port yang berbeda tidak dapat membagikannya → petakan batasan origin sebelum memilih koordinasi di sisi klien.
• Menyalin sistem pemilihan yang kompleks setiap kali SharedWorker tidak tersedia → bisnis mungkin memerlukan kebenaran data, bukan tepat satu koneksi → putuskan apakah jumlah koneksi merupakan batasan mutlak atau jika tidak, gunakan fallback per tab.
• Menyimpan antrean offline dalam variabel global Service Worker → restart pada worker akan menghilangkan pekerjaan tersebut → tulis ke IndexedDB terlebih dahulu dan panggil pengosong antrean yang aman untuk pemutaran ulang (replay-safe).
• Hanya bergantung pada Background Sync → fitur ini masih belum menjadi fitur Baseline yang didukung oleh setiap peramban utama → coba ulang juga saat startup, masuk ke foreground, dan koneksi ulang.
• Memaksa setiap pembaruan untuk segera mengambil kontrol → halaman lama dan worker baru mungkin memiliki protokol yang tidak kompatibel → buat versi pesan, cache, dan migrasi sebelum memilih untuk melewati masa tunggu (skip waiting).
• Menyimpan setiap respons yang berhasil ke dalam cache → data pribadi dapat bertahan di seluruh akun atau digunakan kembali secara tidak benar → gunakan allowlist URL, isolasi per pengguna, pembersihan saat logout, dan validasi respons.

Pertanyaan lanjutan dan jawabannya

Lanjutan 1: Apa yang berubah ketika ukuran CSV bertambah menjadi 2 GiB dan memori ponsel tidak mencukupi?

Berhenti memanggil file.arrayBuffer() untuk seluruh input. Baca chunk Blob.stream() atau slice(), pertahankan baris parsial di seluruh batas decoding, dan biarkan worker mengembalikan agregat atau batch kolumnar. Batasi chunk yang sedang berjalan (in flight) dan wajibkan konfirmasi untuk backpressure. Sediakan titik pembatalan. Jika produk harus mempertahankan setiap baris, alihkan (spill) ke IndexedDB atau berkas tersegmentasi dan lakukan paging pada hasil alih-alih mempertahankan grafik objek lengkap di heap JavaScript. Tambahkan batas khusus perangkat dan jalur penolakan eksplisit.

Lanjutan 2: Bagaimana jika halaman pada subdomain yang berbeda harus berbagi tepat satu WebSocket?

SharedWorker tidak dapat melintasi batasan origin yang berbeda. Salah satu pilihannya adalah origin terkontrol yang memiliki koneksi langsung dan mengekspos jembatan pesan iframe yang diaudit, dengan validasi targetOrigin, pengirim, dan skema yang ketat. Pilihan lainnya adalah memindahkan koordinasi koneksi tunggal ke server sementara setiap halaman mempertahankan koneksi klien independen. Opsi pertama menggabungkan risiko keamanan dan ketersediaan; opsi kedua membutuhkan lebih banyak koneksi server. Pilihlah dari batasan mutlak yang sebenarnya daripada mencoba melewati kebijakan same-origin.

Lanjutan 3: SharedWorker adalah Baseline 2026, jadi mengapa tetap memerlukan fallback?

Gunakan matriks peramban produk. Baseline 2026 menggambarkan kemampuan yang baru saja umum di seluruh rilis peramban saat ini; ini tidak mencakup setiap perangkat lama, versi enterprise yang dibekukan, mode privasi, atau lingkungan tertanam (embedded). Deteksi fitur membutuhkan biaya yang murah. Mulailah dengan koneksi per-tab sebagai fallback dan bangun mekanisme pemilihan hanya jika batasan koneksi yang ketat membenarkannya.

Lanjutan 4: Bagaimana Anda mencegah penulisan duplikat ketika Background Sync mengulang penyimpanan?

Klien membuat satu idempotency key yang stabil untuk operasi bisnis tersebut. Antrean menyimpan setidaknya payload, kunci, jumlah percobaan, dan waktu percobaan ulang berikutnya. Server memberlakukan keunikan atau menyimpan hasil berdasarkan pengguna dan kunci, lalu mengembalikan hasil asli untuk permintaan duplikat. Klien menghapus item antrean hanya setelah mendapat konfirmasi. Batas waktu (timeout) berarti hasil tidak diketahui dan memicu percobaan ulang dengan kunci yang sama, jangan pernah menggunakan kunci baru. Konflik versi bisnis dipindahkan ke peninjauan alih-alih ditimpa secara diam-diam.

Lanjutan 5: Service Worker baru telah terinstal, tetapi pengguna membiarkan halaman lama terbuka tanpa batas waktu. Apa yang Anda lakukan?

Beri tahu halaman yang dikontrol bahwa pembaruan telah siap dan biarkan pengguna me-refresh pada waktu yang aman. Perbaikan keamanan dapat menggunakan skipWaiting() dan clients.claim() hanya jika halaman lama dan baru tetap kompatibel dengan protokol pesan worker serta migrasi cache dan IndexedDB bersifat reentrant. Uji coba rilis harus menguji halaman lama dengan worker baru. Jika kompatibilitas tidak dapat dijamin, pertahankan fase menunggu alih-alih hanya mengoptimalkan aktivasi langsung.

Lanjutan 6: Mengapa tidak menggunakan Service Worker untuk berbagi WebSocket di seluruh tab juga?

Masa pakai Service Worker berbasis peristiwa, dan peramban dapat menghentikannya saat tidak ada aktivitas (idle). WebSocket memerlukan koneksi terus-menerus dan sesi dalam memori, yang bertentangan dengan model tersebut. SharedWorker adalah pemilik yang lebih baik selama referensi halaman tetap ada. Jika peramban target tidak memiliki SharedWorker dan satu koneksi adalah wajib, gunakan pemilihan lintas-tab atau ubah arsitektur server alih-alih berasumsi Service Worker akan tetap aktif secara residen.