Web Locks API: Mencegah Proses Ganda saat Banyak Tab Browser Terbuka

Ketika sebuah aplikasi web dibuka di beberapa tab sekaligus, setiap tab biasanya menjalankan JavaScript secara terpisah. Jika semuanya mencoba menyinkronkan data, memperbarui cache, atau mengirim pekerjaan yang sama pada waktu bersamaan, hasilnya bisa berupa permintaan duplikat, penggunaan kuota berlebihan, atau data lokal yang saling menimpa. Web Locks API menyediakan mekanisme koordinasi agar tab dan worker pada origin yang sama dapat bergiliran mengakses pekerjaan atau sumber daya bersama.

Apa Itu Web Locks API?

Web Locks API adalah antarmuka browser untuk meminta dan memegang sebuah lock bernama selama tugas asinkron dijalankan. Nama lock ditentukan aplikasi, misalnya sync-database atau refresh-session. Ketika satu konteks memegang lock eksklusif, permintaan lain dengan nama yang sama akan menunggu sampai lock dilepas.

Lock dikelola browser dan berlaku pada origin yang sama—kombinasi skema, host, dan port. Karena itu, tab dari https://contoh.com dapat berkoordinasi dengan tab lain pada origin tersebut, tetapi tidak dengan subdomain atau port berbeda. API ini juga tersedia untuk Web Worker dan membutuhkan secure context, umumnya halaman HTTPS.

Cara Kerjanya: Minta, Kerjakan, Lepaskan

Pintu masuk utama adalah navigator.locks.request(). Aplikasi meminta lock dengan nama tertentu, menjalankan pekerjaan di dalam callback, lalu browser melepaskan lock ketika callback selesai. Jika callback bersifat asinkron, lock tetap dipegang sampai Promise yang dikembalikan selesai atau gagal.

async function syncData() {
  // Ganti dengan proses sinkronisasi aplikasi.
  await fetch("/api/sync", { method: "POST" });
}

async function syncOncePerOrigin() {
  if (!navigator.locks) {
    // Sediakan strategi fallback untuk browser yang tidak mendukung.
    await syncData();
    return;
  }

  await navigator.locks.request("nazuaf-data-sync", async () => {
    await syncData();
  });
}

Jika beberapa tab memanggil syncOncePerOrigin() bersamaan, hanya satu callback dengan lock eksklusif bernama nazuaf-data-sync yang berjalan pada satu waktu. Permintaan berikutnya akan menunggu giliran. Contoh ini hanya ilustrasi; endpoint dan kebijakan fallback perlu disesuaikan dengan aplikasi nyata.

Kasus Penggunaan yang Paling Berguna

• Mencegah sinkronisasi berulang. Beberapa tab dapat mencoba memperbarui data dari server. Lock membantu membatasi proses tersebut menjadi satu pekerjaan aktif pada satu origin.
• Memilih tab koordinator. Aplikasi dapat menggunakan pola leader election sederhana: tab yang berhasil memegang lock menjalankan polling atau tugas latar, sementara tab lain menunggu atau melakukan pekerjaan alternatif.
• Melindungi pembaruan data lokal. Jika beberapa tab membaca dan menulis catatan yang sama melalui IndexedDB, lock dapat membantu mengatur urutan operasi tingkat aplikasi.
• Mengurangi pekerjaan duplikat. Pembuatan cache, pemeriksaan sesi, atau pemrosesan antrean lokal dapat dijalankan oleh satu konteks pada satu waktu.

Lock tidak otomatis membuat operasi database menjadi transaksional. Jika server menerima permintaan ganda dari perangkat berbeda, aplikasi tetap memerlukan validasi server, transaksi database, atau idempotency key sesuai kebutuhan.

Lock Eksklusif dan Lock Bersama

Mode default adalah exclusive: satu pemegang lock untuk satu nama pada satu waktu. Mode shared memungkinkan beberapa pembaca memegang lock yang sama secara bersamaan, selama tidak ada lock eksklusif yang menghalanginya. Pola ini berguna ketika beberapa tab boleh membaca sumber daya, tetapi pembaruan perlu menunggu sampai pembacaan selesai.

// Beberapa tab dapat membaca secara bersamaan.
await navigator.locks.request(
  "report-data",
  { mode: "shared" },
  async () => {
    await readReport();
  }
);

// Operasi tulis meminta akses eksklusif.
await navigator.locks.request("report-data", async () => {
  await updateReport();
});

Pastikan semua bagian aplikasi menggunakan nama lock dan aturan akses yang konsisten. Lock hanya melindungi kode yang secara sadar meminta lock yang sama; kode lain yang mengabaikannya tetap dapat mengubah data.

Menangani Lock yang Tidak Bisa Langsung Didapat

Opsi ifAvailable: true memungkinkan aplikasi melewati pekerjaan jika lock sedang dipegang pihak lain, alih-alih masuk antrean. Callback akan menerima null ketika lock tidak tersedia.

await navigator.locks.request(
  "background-refresh",
  { ifAvailable: true },
  async (lock) => {
    if (!lock) return; // Tab lain sedang mengerjakan refresh.
    await refreshData();
  }
);

Pendekatan ini cocok untuk tugas latar yang boleh ditunda, seperti penyegaran berkala. Untuk operasi yang wajib selesai, jangan memakai opsi tersebut tanpa strategi antrean atau percobaan ulang yang jelas.

Risiko dan Praktik Implementasi yang Aman

1. Jaga durasi lock tetap singkat. Jangan menahan lock selama pekerjaan yang tidak perlu. Selama callback belum selesai, peminta lain dengan nama sama harus menunggu.
2. Hindari deadlock. Jika beberapa lock diperlukan, minta dalam urutan konsisten dan hindari saling menunggu melalui rangkaian callback. Deadlock pada lock dapat membuat pekerjaan aplikasi macet.
3. Rancang kegagalan dengan baik. Gunakan try/finally untuk pembersihan sumber daya, tangani penolakan Promise, dan pastikan UI tetap memberi umpan balik ketika permintaan sedang menunggu.
4. Siapkan fallback. Periksa ketersediaan navigator.locks dan sediakan strategi yang sesuai. Fallback sederhana tidak menjamin koordinasi lintas tab; bila konsistensi penting, pertimbangkan mekanisme tambahan dan validasi server.
5. Uji banyak tab dan worker. Simulasikan tab yang lambat, jaringan gagal, tab ditutup, serta permintaan lock yang menumpuk. Untuk diagnosis, navigator.locks.query() dapat menampilkan snapshot lock yang sedang dipegang dan diminta, jika didukung.

Kesimpulan

Web Locks API membantu aplikasi web mengoordinasikan pekerjaan yang berpotensi berjalan ganda ketika beberapa tab atau worker aktif. Dengan nama lock yang konsisten, callback yang singkat, penanganan kegagalan, dan fallback yang tepat, aplikasi dapat mengurangi sinkronisasi duplikat serta konflik pembaruan lokal. Namun, lock browser bukan pengganti kontrol konsistensi di server: transaksi, otorisasi, dan perlindungan terhadap permintaan berulang tetap harus dirancang pada lapisan yang sesuai.

Referensi teknis: dokumentasi Web Locks API di MDN dan spesifikasi Web Locks API.