Pekerja layanan dan Cache Storage API

Jeff Posnick

Anda terjebak dalam perjuangan untuk keandalan jaringan. Cache HTTP browser adalah garis pertahanan pertama Anda, tetapi seperti yang telah Anda pelajari, cache ini hanya benar-benar efektif saat memuat URL berversi yang telah Anda kunjungi sebelumnya. Cache HTTP saja tidak cukup.

Untungnya, ada dua alat baru yang dapat membantu Anda: service worker dan Cache Storage API. Karena keduanya sering digunakan bersama, sebaiknya pelajari keduanya secara bersamaan.

Service worker

Service worker di-build ke dalam browser dan dikontrol oleh sedikit kode JavaScript tambahan yang harus Anda buat. Anda men-deploy file ini bersama file lain yang membentuk aplikasi web Anda yang sebenarnya.

Pekerja layanan memiliki beberapa kemampuan khusus. Di antara tugas lainnya, service worker dengan sabar menunggu aplikasi web Anda membuat permintaan keluar, lalu beraksi dengan mencegatnya. Tindakan yang dilakukan pekerja layanan terhadap permintaan yang ditangkap ini terserah Anda.

Untuk beberapa permintaan, tindakan terbaik mungkin adalah mengizinkan permintaan untuk melanjutkan ke jaringan, seperti yang akan terjadi jika tidak ada service worker sama sekali.

Namun, untuk permintaan lain, Anda dapat memanfaatkan sesuatu yang lebih fleksibel daripada cache HTTP browser, dan menampilkan respons cepat yang andal tanpa harus mengkhawatirkan jaringan. Hal ini memerlukan penggunaan bagian lain dari puzzle: Cache Storage API.

Cache Storage API

Browser Support

  • Chrome: 43.
  • Edge: 16.
  • Firefox: 41.
  • Safari: 11.1.

Source

Cache Storage API membuka berbagai kemungkinan baru, dengan memberi developer kontrol penuh atas konten cache. Alih-alih mengandalkan kombinasi header HTTP dan heuristik bawaan browser, Cache Storage API mengekspos pendekatan berbasis kode untuk penyimpanan cache. Cache Storage API sangat berguna saat dipanggil dari JavaScript pekerja layanan Anda.

Tunggu… ada cache lain yang perlu dipikirkan sekarang?

Anda mungkin bertanya-tanya, "Apakah saya masih perlu mengonfigurasi header HTTP?" dan "Apa yang dapat saya lakukan dengan cache baru ini yang tidak dapat dilakukan dengan cache HTTP?" Jangan khawatir—itu adalah reaksi alami.

Sebaiknya Anda tetap mengonfigurasi header Cache-Control di server web, meskipun Anda tahu bahwa Anda menggunakan Cache Storage API. Anda biasanya dapat menetapkan Cache-Control: no-cache untuk URL tanpa versi, dan/atau Cache-Control: max-age=31536000 untuk URL yang berisi informasi pembuatan versi, seperti hash.

Saat mengisi cache Cache Storage API, browser secara default akan memeriksa entri yang ada di cache HTTP, dan menggunakannya jika ditemukan. Jika Anda menambahkan URL berversi ke cache Cache Storage API, browser akan menghindari permintaan jaringan tambahan. Sisi negatifnya adalah jika Anda menggunakan header Cache-Control yang salah dikonfigurasi, seperti menentukan masa aktif cache yang lama untuk URL tanpa versi, Anda dapat memperburuk keadaan dengan menambahkan konten usang tersebut ke Cache Storage API. Mengurutkan perilaku cache HTTP Anda adalah prasyarat untuk menggunakan Cache Storage API secara efektif.

Mengenai apa yang kini dapat dilakukan dengan API baru ini, jawabannya adalah: banyak. Beberapa penggunaan umum yang akan sulit atau tidak mungkin dilakukan hanya dengan cache HTTP meliputi:

  • Gunakan pendekatan "refresh di latar belakang" untuk konten yang di-cache, yang dikenal sebagai stale-while-revalidate.
  • Terapkan batas jumlah maksimum aset yang akan di-cache, dan terapkan kebijakan masa berlaku kustom untuk menghapus item setelah batas tersebut tercapai.
  • Bandingkan respons jaringan yang di-cache sebelumnya dan yang baru untuk melihat apakah ada yang berubah, dan memungkinkan pengguna memperbarui konten (misalnya, dengan tombol) saat data benar-benar telah diperbarui.

Lihat Cache API: Panduan singkat untuk mempelajari lebih lanjut.

Seluk-beluk API

Ada beberapa hal yang perlu diingat tentang desain API:

  • Objek Request digunakan sebagai kunci unik saat membaca dan menulis ke cache ini. Untuk memudahkan, Anda dapat meneruskan string URL seperti 'https://example.com/index.html' sebagai kunci, bukan objek Request yang sebenarnya, dan API akan otomatis menanganinya untuk Anda.
  • Objek Response digunakan sebagai nilai dalam cache ini.
  • Header Cache-Control pada Response tertentu secara efektif diabaikan saat meng-cache data. Tidak ada pemeriksaan masa berlaku atau keaktualan otomatis bawaan, dan setelah Anda menyimpan item di cache, item tersebut akan tetap ada hingga kode Anda menghapusnya secara eksplisit. (Ada library untuk menyederhanakan pemeliharaan cache untuk Anda. Keduanya akan dibahas nanti dalam seri ini.)
  • Tidak seperti API sinkron yang lebih lama seperti LocalStorage, semua operasi Cache Storage API bersifat asinkron.

Penjelasan singkat: Promise dan async/await

Service worker dan Cache Storage API menggunakan konsep pemrograman asinkron. Secara khusus, keduanya sangat bergantung pada promise untuk merepresentasikan hasil operasi asinkron di masa mendatang. Anda harus memahami promise, dan sintaksis async/await terkait, sebelum mempelajari lebih lanjut.

Jangan deploy kode tersebut… dulu

Meskipun memberikan fondasi yang penting, dan dapat digunakan apa adanya, service worker dan Cache Storage API secara efektif merupakan elemen penyusun tingkat rendah, dengan sejumlah kasus ekstrem dan "kejutan". Ada beberapa alat tingkat tinggi yang dapat membantu mempermudah bagian sulit dari API tersebut, dan menyediakan semua yang Anda butuhkan untuk membangun pekerja layanan yang siap produksi. Panduan berikutnya membahas salah satu alat tersebut: Workbox.