Pekerja layanan dan Cache Storage API

Jeff Posnick

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

Untungnya, dua alat baru tersedia untuk membantu Anda membalikkan keadaan: pekerja layanan dan Cache Storage API. Karena keduanya sering digunakan bersamaan, sebaiknya pelajari keduanya secara bersamaan.

Service worker

Pekerja layanan disertakan dalam browser dan dikontrol oleh sedikit kode JavaScript tambahan yang menjadi tanggung jawab Anda untuk membuatnya. Anda men-deploy-nya bersama file lain yang membentuk aplikasi web Anda sebenarnya.

Pekerja layanan memiliki beberapa kekuatan khusus. Di antara tugas lainnya, aplikasi web Anda harus dengan sabar menunggu aplikasi web Anda untuk membuat permintaan keluar, lalu melakukan tindakan dengan menangkapnya. Tindakan yang dilakukan pekerja layanan terhadap permintaan yang disadap ini bergantung pada Anda.

Untuk beberapa permintaan, tindakan terbaik yang dapat dilakukan adalah mengizinkan permintaan melanjutkan ke jaringan, seperti yang akan terjadi jika tidak ada pekerja layanan sama sekali.

Namun, untuk permintaan lainnya, Anda dapat memanfaatkan sesuatu yang lebih fleksibel daripada cache HTTP browser, dan menampilkan respons yang cepat dan andal tanpa perlu mengkhawatirkan jaringan. Artinya, Anda harus menggunakan bagian lain dari teka-teki ini: Cache Storage API.

Cache Storage API

Dukungan Browser

  • 43
  • 16
  • 41
  • 11.1

Sumber

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

Tunggu... ada cache lain untuk dipikirkan sekarang?

Anda mungkin mengajukan pertanyaan seperti "Apakah saya masih harus mengonfigurasi header HTTP saya?" dan "Apa yang bisa saya lakukan dengan cache baru ini yang tidak mungkin dilakukan dengan cache HTTP?" Jangan khawatir—itu adalah reaksi alami.

Sebaiknya Anda mengonfigurasi header Cache-Control di server web, meskipun Anda tahu bahwa Anda menggunakan Cache Storage API. Anda biasanya dapat memilih untuk tidak menyetel 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 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 baliknya adalah jika Anda menggunakan header Cache-Control yang salah dikonfigurasi, seperti menentukan masa aktif cache yang tahan 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 sekarang dapat dilakukan dengan API baru ini, jawabannya adalah: banyak. Beberapa penggunaan umum yang sulit atau tidak mungkin dilakukan hanya dengan cache HTTP antara lain:

  • Gunakan pendekatan "muat ulang di latar belakang" untuk konten yang di-cache, yang dikenal sebagai buang saat validasi ulang.
  • Menerapkan batas jumlah maksimum aset yang akan di-cache, dan menerapkan kebijakan habis masa berlaku kustom untuk menghapus item setelah batas tersebut tercapai.
  • Bandingkan respons jaringan baru dan yang di-cache sebelumnya untuk melihat apakah ada yang berubah, dan memungkinkan pengguna memperbarui konten (misalnya, dengan tombol) ketika data benar-benar telah diperbarui.

Lihat Cache API: Panduan cepat untuk mempelajari lebih lanjut.

Mur dan baut API

Ada beberapa hal yang perlu diingat mengenai desain API:

  • Objek Request digunakan sebagai kunci unik saat membaca dan menulis ke cache ini. Untuk memudahkan Anda, 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 data dalam cache. Tidak ada pemeriksaan akhir masa berlaku atau keaktualan bawaan, dan setelah Anda menyimpan item dalam cache, item tersebut akan tetap tersimpan hingga kode Anda menghapusnya secara eksplisit. (Ada library untuk menyederhanakan pemeliharaan cache atas nama Anda. Hal tersebut akan dibahas nanti dalam rangkaian ini.)
  • Berbeda dengan API sinkron yang lama, seperti LocalStorage, semua operasi Cache Storage API bersifat asinkron.

Pengalihan cepat: promise dan async/await

Pekerja layanan dan Cache Storage API menggunakan konsep pemrograman asinkron. Secara khusus, model sangat bergantung pada promise untuk merepresentasikan hasil operasi asinkron di masa mendatang. Anda harus memahami promise, dan sintaksis async/await yang terkait, sebelum mempelajarinya.

Jangan men-deploy kode tersebut... sekarang

Meskipun keduanya memberikan fondasi penting, dan dapat digunakan sebagaimana adanya, pekerja layanan dan Cache Storage API merupakan elemen penyusun tingkat rendah dengan sejumlah kasus ekstrem dan "gotcha". Ada beberapa alat dengan tingkat lebih tinggi yang dapat membantu memperlancar bagian yang sulit dari API tersebut, dan menyediakan semua yang Anda butuhkan untuk mem-build pekerja layanan siap produksi. Panduan berikutnya membahas salah satu alat tersebut: Workbox.