Pekerja Layanan dalam Klien Slack: Pada Percepatan Unduhan dan Mode Offline

Materi, terjemahan yang kami terbitkan hari ini, didedikasikan untuk cerita tentang mengoptimalkan versi baru dari klien desktop Slack , salah satu fitur utama di antaranya adalah percepatan pemuatan.

Latar belakang

Pada awal pengerjaan pada versi baru dari klien desktop Slack, sebuah prototipe telah dibuat, yang disebut "sepatu boot cepat". Tujuan prototipe ini, seperti yang Anda duga, adalah untuk mempercepat unduhan sebanyak mungkin. Menggunakan file HTML dari cache CDN, data penyimpanan Redux disimpan di muka, dan pekerja layanan, kami dapat memuat versi ringan dari klien dalam waktu kurang dari satu detik (pada waktu itu, waktu pengunduhan yang biasa untuk pengguna dengan 1-2 ruang kerja adalah sekitar 5 detik ) Pekerja layanan adalah pusat percepatan ini. Selain itu, ia membuka jalan bagi peluang yang sering kami minta para pengguna Slack untuk diimplementasikan. Kita berbicara tentang mode offline klien. Prototipe memungkinkan kami untuk benar-benar melihat dengan satu mata apa yang dapat dibuat ulang oleh klien. Berdasarkan teknologi di atas, kami mulai memproses klien Slack, secara kasar membayangkan hasilnya dan berfokus pada mempercepat pemuatan dan menerapkan mode operasi program offline. Mari kita bicara tentang bagaimana inti dari klien yang diperbarui bekerja.

Apa itu pekerja layanan?

Service Worker ( Service Worker ), pada kenyataannya, adalah objek proxy yang kuat untuk permintaan jaringan, yang memungkinkan pengembang, menggunakan sejumlah kecil kode JavaScript, untuk mengontrol bagaimana browser memproses permintaan HTTP individual. Pekerja layanan mendukung API caching yang canggih dan fleksibel, yang dirancang sedemikian rupa sehingga objek Permintaan digunakan sebagai kunci, dan objek Respons digunakan sebagai nilai. Pekerja layanan, seperti pekerja Web, dieksekusi dalam proses mereka sendiri, di luar utas eksekusi kode JavaScript utama dari jendela browser apa pun.

Pekerja Layanan adalah pengikut Cache Aplikasi , yang sekarang sudah tidak digunakan lagi. Itu adalah satu set API yang diwakili oleh antarmuka AppCache , yang digunakan untuk membuat situs yang mengimplementasikan fitur offline. Saat bekerja dengan AppCache , file manifes statis digunakan yang menjelaskan file yang ingin di-cache oleh pengembang untuk digunakan offline. Secara umum, fitur AppCache terbatas pada ini. Mekanisme ini sederhana, tetapi tidak fleksibel, yang tidak memberikan kontrol khusus pengembang atas cache. Di W3C, ini diperhitungkan saat mengembangkan spesifikasi Pekerja Layanan . Akibatnya, pekerja layanan memungkinkan pengembang untuk mengelola banyak detail mengenai setiap sesi interaksi jaringan yang dilakukan oleh aplikasi web atau situs web.

Ketika kami pertama kali mulai bekerja dengan teknologi ini, Chrome adalah satu-satunya browser yang mendukungnya, tetapi kami tahu bahwa tidak ada banyak waktu untuk menunggu dukungan luas bagi pekerja layanan. Sekarang teknologi ini ada di mana - mana , didukung oleh semua browser utama.

Bagaimana kami menggunakan pekerja layanan

Ketika pengguna meluncurkan klien Slack baru untuk pertama kalinya, kami mengunduh satu set lengkap sumber daya (HTML, JavaScript, CSS, font dan suara) dan menempatkannya dalam cache pekerja layanan. Selain itu, kami membuat salinan toko Redux yang terletak di memori dan menulis salinan ini ke basis data IndexedDB. Saat program diluncurkan di waktu berikutnya, kami memeriksa keberadaan cache yang sesuai. Jika ya, kami menggunakannya saat mengunduh aplikasi. Jika pengguna terhubung ke Internet, kami mengunduh data terbaru setelah meluncurkan aplikasi. Jika tidak, klien tetap beroperasi.

Untuk membedakan antara dua opsi di atas untuk memuat klien - kami memberi mereka nama: unduhan panas (hangat) dan dingin (dingin). Boot dingin klien paling sering terjadi ketika pengguna meluncurkan program untuk pertama kalinya. Dalam situasi ini, tidak ada sumber daya yang di-cache atau data Redux yang disimpan. Dengan boot panas, kami memiliki semua yang Anda butuhkan untuk menjalankan klien Slack di komputer pengguna. Harap perhatikan bahwa sebagian besar sumber daya biner (gambar, PDF, video, dan sebagainya) diproses menggunakan cache browser (sumber daya ini dikendalikan oleh tajuk cache reguler). Pekerja layanan tidak boleh memprosesnya dengan cara khusus sehingga kami dapat bekerja dengannya secara offline.


Pilihan antara pemuatan panas dan dingin

Siklus Hidup Pekerja Layanan

Pekerja layanan dapat menangani tiga acara siklus hidup. Ini adalah instal , ambil dan aktifkan . Di bawah ini kita akan berbicara tentang bagaimana kita menanggapi masing-masing peristiwa ini, tetapi pertama-tama kita perlu berbicara tentang mengunduh dan mendaftarkan pekerja layanan itu sendiri. Siklus hidupnya tergantung pada bagaimana browser menangani pembaruan file pekerja layanan. Inilah yang dapat Anda baca tentang hal itu di MDN : “Instalasi dilakukan jika file yang diunduh dikenali sebagai baru. Ini bisa berupa file yang berbeda dari yang ada (perbedaan dalam file ditentukan dengan membandingkannya dengan byte), atau file pekerja layanan yang pertama kali ditemukan oleh browser pada halaman yang sedang diproses. "

Setiap kali kami memperbarui file JavaScript, CSS, atau HTML yang sesuai, itu berjalan melalui plugin Webpack khusus, yang membuat manifes dengan deskripsi file yang sesuai dengan hash unik ( berikut adalah contoh singkatan dari file manifes). Manifes ini tertanam dalam kode pekerja layanan, yang menyebabkan pekerja layanan diperbarui pada boot berikutnya. Selain itu, ini dilakukan bahkan ketika implementasi pekerja layanan tidak berubah.

▍Event acara

Setiap kali seorang pekerja layanan diperbarui, kami mendapatkan acara install . Menanggapi itu, kita pergi melalui file, deskripsi yang terkandung dalam manifes dibangun ke pekerja layanan, memuat masing-masing dan menempatkannya di blok cache yang sesuai. Penyimpanan file diatur menggunakan API Cache baru, yang merupakan bagian dari spesifikasi Pekerja Layanan. API ini menyimpan objek Response menggunakan objek Request sebagai kunci. Sebagai hasilnya, ternyata penyimpanannya sangat sederhana. Ini berjalan baik dengan bagaimana peristiwa pekerja layanan menerima permintaan dan mengembalikan respons.

Kunci untuk blok cache ditugaskan berdasarkan waktu penyebaran solusi. Cap waktu disematkan dalam kode HTML, sebagai hasilnya, dapat dikirim, sebagai bagian dari nama file, dalam permintaan untuk mengunduh setiap sumber daya. Caching sumber daya yang terpisah dari setiap penyebaran penting untuk menghindari berbagi sumber daya yang tidak kompatibel. Berkat ini, kami dapat memastikan bahwa file HTML yang awalnya diunduh hanya akan mengunduh sumber daya yang kompatibel, dan ini benar baik ketika mereka diunduh melalui jaringan dan ketika mereka diunduh dari cache.

▍Event mengambil

Setelah pekerja layanan terdaftar, itu akan mulai memproses semua permintaan jaringan milik sumber yang sama. Pengembang tidak dapat membuatnya sehingga beberapa permintaan diproses oleh pekerja layanan, sementara yang lain tidak. Tetapi pengembang memiliki kontrol penuh atas apa yang sebenarnya perlu dilakukan dengan permintaan yang diterima oleh pekerja layanan.

Saat memproses permintaan, pertama-tama kami memeriksanya. Jika yang diminta ada di manifes dan ada di cache, kami mengembalikan respons ke permintaan dengan mengambil data dari cache. Jika cache tidak memiliki apa yang Anda butuhkan, kami mengembalikan permintaan jaringan nyata yang mengakses sumber daya jaringan nyata seolah-olah pekerja layanan sama sekali tidak terlibat dalam proses ini. Berikut ini adalah versi sederhana dari pengendali acara fetch kami:

 self.addEventListener('fetch', (e) => {  if (assetManifest.includes(e.request.url) {    e.respondWith(      caches        .open(cacheKey)        .then(cache => cache.match(e.request))        .then(response => {          if (response) return response;          return fetch(e.request);        });    );  } else {    e.respondWith(fetch(e.request));  } }); 

Pada kenyataannya, kode seperti itu mengandung lebih banyak logika Slack-specific, tetapi inti dari handler kami sesederhana dalam contoh ini.


Saat menganalisis interaksi jaringan, respons yang dikembalikan dari pekerja layanan dapat dikenali oleh tanda ServiceWorker di kolom yang menunjukkan jumlah data

▍Event aktifkan

Acara activate dinaikkan setelah instalasi yang berhasil dari pekerja layanan baru atau diperbarui. Kami menggunakannya untuk menganalisis sumber daya yang di-cache dan membatalkan blok cache yang lebih tua dari 7 hari. Ini adalah praktik yang baik untuk memelihara sistem secara berurutan, dan di samping itu, ini memungkinkan Anda untuk memastikan bahwa sumber daya yang terlalu lama tidak digunakan saat memuat klien.

Kode klien tertinggal di belakang rilis terbaru

Anda mungkin telah memperhatikan bahwa implementasi kami menyiratkan bahwa siapa pun yang memulai klien Slack setelah awal klien tidak akan menerima bukan yang terbaru, tetapi sumber daya yang di-cache dimuat selama pendaftaran sebelumnya dari pekerja layanan. Dalam implementasi klien asli, kami mencoba memperbarui pekerja layanan setelah setiap unduhan. Namun, pengguna Slack biasa dapat, misalnya, mengunduh program hanya sekali sehari, di pagi hari. Hal ini dapat mengarah pada fakta bahwa ia akan terus bekerja dengan klien yang kodenya sepanjang hari tertinggal dari rilis terbaru (kami merilis rilis baru beberapa kali sehari).

Tidak seperti situs web biasa, yang setelah mengunjungi, dengan cepat pergi, klien Slack pada komputer pengguna terbuka selama berjam-jam dan dalam keadaan terbuka. Akibatnya, kode kami memiliki masa pakai yang agak panjang, yang mengharuskan kami untuk menggunakan pendekatan khusus untuk mempertahankan relevansinya.

Pada saat yang sama, kami berusaha untuk memastikan bahwa pengguna bekerja dengan versi terbaru dari kode, sehingga mereka menerima fitur terbaru, perbaikan bug, dan peningkatan kinerja. Tidak lama setelah kami merilis klien baru, kami menerapkan mekanisme di dalamnya yang memungkinkan kami untuk mempersempit kesenjangan antara apa yang bekerja dengan pengguna dan apa yang telah kami lepaskan. Jika, setelah pembaruan terakhir, versi baru dari sistem dikerahkan, kami memuat sumber daya segar yang akan digunakan saat berikutnya klien melakukan booting. Jika tidak ada yang baru dapat ditemukan, maka tidak ada yang dimuat. Setelah perubahan ini dibuat untuk klien, waktu hidup rata-rata sumber daya yang digunakan klien dibelah dua.


Versi baru kode diunduh secara teratur, tetapi saat mengunduh program, hanya versi terbaru yang digunakan

Sinkronisasi Bendera Fitur Baru

Dengan bantuan bendera fitur baru (Bendera Fitur) kami menandai basis kode yang berfungsi yang belum selesai. Ini memungkinkan kami untuk memasukkan fitur-fitur baru dalam kode sebelum rilis publik mereka. Pendekatan ini mengurangi risiko kesalahan dalam produksi karena fakta bahwa fitur-fitur baru dapat diuji secara bebas bersama dengan sisa aplikasi, melakukan ini jauh sebelum pekerjaan pada mereka selesai.

Fitur-fitur baru di Slack biasanya dirilis ketika mereka membuat perubahan pada API yang sesuai. Sebelum kami mulai menggunakan pekerja layanan, kami memiliki jaminan bahwa fitur dan perubahan baru dalam API akan selalu disinkronkan. Tetapi setelah kami mulai menggunakan cache, yang mungkin tidak mengandung versi terbaru dari kode, ternyata klien mungkin berada dalam situasi di mana kode tidak disinkronkan dengan kemampuan backend. Untuk mengatasi masalah ini, kami menyimpan tidak hanya sumber daya, tetapi juga beberapa respons API.

Fakta bahwa pekerja layanan memproses sepenuhnya semua permintaan jaringan telah menyederhanakan solusi. Dengan setiap pembaruan pekerja layanan, kami, antara lain, mengeksekusi permintaan API, caching tanggapan dalam blok cache yang sama dengan sumber daya yang sesuai. Ini menghubungkan kemampuan dan fungsi eksperimental dengan sumber daya yang tepat - berpotensi usang, tetapi dijamin akan konsisten satu sama lain.

Ini, pada kenyataannya, hanya puncak gunung es peluang yang tersedia untuk pengembang berkat pekerja layanan. Masalah yang tidak dapat dipecahkan menggunakan mekanisme AppCache , atau yang membutuhkan mekanisme klien dan server untuk dipecahkan, dapat dengan mudah dan alami diselesaikan menggunakan pekerja layanan dan API Cache.

Ringkasan

Pekerja layanan mempercepat pemuatan klien Slack dengan mengatur penyimpanan sumber daya lokal yang siap digunakan saat berikutnya klien melakukan booting. Jaringan - sumber utama keterlambatan dan ambiguitas yang mungkin ditemui pengguna kami, sekarang hampir tidak berpengaruh pada situasi. Kita, dengan kata lain, menghapusnya dari persamaan. Dan jika Anda dapat menghapus jaringan dari persamaan, maka ternyata Anda dapat mengimplementasikan fungsionalitas offline dalam proyek tersebut. Dukungan kami untuk mode offline sangat mudah saat ini. Pengguna dapat mengunduh klien dan dapat membaca pesan dari percakapan yang diunduh. Sistem pada saat yang sama mempersiapkan tanda sinkronisasi pada pesan yang sudah dibaca. Tetapi sekarang kita memiliki dasar untuk implementasi mekanisme yang lebih maju di masa depan.

Setelah berbulan-bulan pengembangan, eksperimen dan optimalisasi, kami belajar banyak tentang bagaimana pekerja layanan bekerja dalam praktik. Selain itu, ternyata teknologi ini sangat cocok untuk proyek skala besar. Dalam waktu kurang dari sebulan sejak rilis publik klien dengan pekerja layanan, kami berhasil melayani puluhan juta permintaan setiap hari dari jutaan pekerja layanan yang dipasang. Hal ini menyebabkan pengurangan sekitar 50% dalam waktu pemuatan pelanggan baru dibandingkan dengan yang lama, dan fakta bahwa pemuatan panas sekitar 25% lebih cepat daripada dingin.


Dari kiri ke kanan: memuat klien lama, memuat dingin klien baru, memuat klien baru (semakin rendah indikator, semakin baik)

Pembaca yang budiman! Apakah Anda menggunakan pekerja layanan dalam proyek Anda?