Pekerja layanan dan Cache Storage API

Jeff Posnick

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

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

Pekerja layanan

Pekerja layanan di-build ke dalam browser dan dikontrol oleh sedikit kode JavaScript tambahan yang Anda buat. Anda men-deploy-nya bersama file lain yang membentuk aplikasi web sebenarnya.

Pekerja layanan memiliki beberapa kemampuan khusus. Di antara tugas lainnya, ia dengan sabar menunggu aplikasi web Anda membuat permintaan keluar, lalu beraksi dengan mencegatnya. Tindakan yang dilakukan pekerja layanan dengan permintaan yang dicegat ini tergantung pada Anda.

Untuk beberapa permintaan, tindakan terbaik mungkin hanya mengizinkan permintaan untuk 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 khawatir dengan jaringan. Hal ini memerlukan penggunaan bagian lain dari teka-teki: Cache Storage API.

Cache Storage API

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

Tunggu… ada cache lain yang perlu dipikirkan sekarang?

Anda mungkin bertanya-tanya seperti "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 API Penyimpanan Cache, browser akan menghindari permintaan jaringan tambahan. Sisi lainnya adalah jika Anda menggunakan header Cache-Control yang salah dikonfigurasi, seperti menentukan masa aktif cache yang lama untuk URL tanpa versi, Anda dapat berakhir membuat keadaan menjadi lebih buruk dengan menambahkan konten yang sudah tidak berlaku ke Cache Storage API. Mengurutkan perilaku cache HTTP Anda adalah prasyarat untuk menggunakan Cache Storage API secara efektif.

Untuk mengetahui 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 cepat untuk mempelajari lebih lanjut.

Dasar-dasar 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 menyimpan data ke dalam cache. Tidak ada pemeriksaan masa berlaku atau keaktualan bawaan otomatis, dan setelah Anda menyimpan item dalam cache, item tersebut akan tetap ada hingga kode Anda menghapusnya secara eksplisit. (Ada library untuk menyederhanakan pemeliharaan cache untuk Anda. Hal ini akan dibahas nanti dalam seri ini.)
• Tidak seperti API sinkron lama seperti LocalStorage, semua operasi Cache Storage API bersifat asinkron.

Simpangan cepat: promise dan async/await

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

Jangan deploy kode tersebut… untuk saat ini

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