Arsitektur

Mendesain aplikasi Anda untuk memaksimalkan teknologi yang membuat PWA andal, dapat diinstal, dan mampu dimulai dengan memahami aplikasi Anda dan batasannya, serta memilih arsitektur yang sesuai untuk keduanya.

SPA versus MPA

Saat ini, ada dua pola arsitektur utama dalam pengembangan web: aplikasi satu halaman, atau SPA, dan aplikasi multi-halaman, atau MPA.

Aplikasi web satu halaman ditentukan dengan memiliki kontrol JavaScript sisi klien atas sebagian besar atau semua rendering HTML halaman berdasarkan data yang diambil oleh atau diberikan ke aplikasi. Aplikasi ini mengganti navigasi bawaan browser, menggantinya dengan fungsi perutean dan penanganan tampilannya.

Aplikasi multi-halaman biasanya telah melakukan pra-render HTML yang dikirim langsung ke browser, sering kali ditingkatkan dengan JavaScript sisi klien setelah browser selesai memuat HTML, dan mengandalkan mekanisme navigasi bawaan browser untuk menampilkan tampilan berikutnya.

Kedua arsitektur tersebut dapat digunakan untuk membuat PWA.

Masing-masing memiliki kelebihan dan kekurangan, dan memilih yang tepat untuk kasus penggunaan dan konteks Anda adalah kunci untuk memberikan pengalaman yang cepat dan andal bagi pengguna.

Aplikasi web satu halaman

Kelebihan
  • Sebagian besar pembaruan dalam halaman atomik.
  • Dependensi sisi klien dimuat saat startup.
  • Pemuatan berikutnya cepat karena penggunaan cache.
Kekurangan
  • Biaya pemuatan awal yang tinggi.
  • Performa bergantung pada hardware perangkat dan koneksi jaringan.
  • Kompleksitas aplikasi tambahan diperlukan.

Aplikasi web satu halaman cocok secara arsitektural jika:

  • Interaksi pengguna terutama berpusat pada pembaruan atomik data yang saling berhubungan yang ditampilkan di halaman yang sama, misalnya, dasbor data real-time atau aplikasi pengeditan video.
  • Aplikasi Anda memiliki dependensi inisialisasi khusus sisi klien, misalnya, penyedia autentikasi pihak ketiga dengan biaya startup yang sangat tinggi.
  • Data yang diperlukan agar tampilan dimuat bergantung pada konteks khusus sisi klien tertentu, misalnya, menampilkan kontrol untuk hardware yang terhubung.
  • Aplikasi ini kecil dan cukup sederhana sehingga ukuran dan kompleksitasnya tidak berdampak pada kelemahan yang tercantum di atas.

SPA mungkin bukan pilihan arsitektur yang baik jika:

  • Performa pemuatan awal sangat penting. SPA biasanya perlu memuat lebih banyak JavaScript untuk menentukan apa yang harus dimuat dan cara menampilkannya. Waktu penguraian dan eksekusi JavaScript ini, jika digabungkan dengan pengambilan konten, lebih lambat daripada pengiriman HTML yang dirender.
  • Aplikasi Anda sebagian besar berjalan di perangkat yang memiliki daya rendah hingga rata-rata. Karena SPA bergantung pada JavaScript untuk rendering, pengalaman pengguna sangat bergantung pada daya perangkat khusus mereka daripada dalam MPA.

Karena SPA perlu mengganti navigasi bawaan browser dengan peruteannya, SPA memerlukan tingkat kompleksitas minimum seputar secara efisien memperbarui tampilan saat ini, mengelola perubahan navigasi, dan membersihkan tampilan sebelumnya yang seharusnya ditangani oleh browser, membuat mereka lebih sulit dikelola secara keseluruhan dan lebih membebani perangkat pengguna.

Aplikasi multi-halaman

Kelebihan
  • Sebagian besar berupa update sehalaman penuh.
  • Kecepatan render awal sangat penting.
  • Pembuatan skrip sisi klien dapat menjadi peningkatan.
Kekurangan
  • Tampilan sekunder memerlukan panggilan server lain.
  • Konteks tidak diterapkan di antara tampilan.
  • Memerlukan server atau pra-rendering.

Aplikasi multi-halaman adalah pilihan arsitektur yang baik jika:

  • Interaksi pengguna terutama berpusat pada tampilan satu bagian data dengan data berbasis konteks opsional, misalnya, aplikasi berita atau e-commerce.
  • Kecepatan render awal sangat penting, karena mengirim HTML yang sudah dirender ke browser lebih cepat daripada menyusunnya dari permintaan data setelah memuat, mengurai, dan mengeksekusi alternatif berbasis JavaScript.
  • Interaktivitas atau konteks sisi klien dapat disertakan sebagai peningkatan setelah pemuatan awal, misalnya, menambahkan lapisan profil ke halaman yang dirender atau menambahkan komponen yang bergantung pada konteks sisi klien sekunder.

MPA mungkin bukan pilihan arsitektur yang baik jika:

  • Mendownload ulang, mengurai ulang, dan mengeksekusi ulang JavaScript atau CSS Anda sangatlah mahal. Konsumsi ini dimitigasi pada PWA dengan pekerja layanan.
  • Konteks sisi klien, seperti lokasi pengguna, tidak berpindah dengan mulus di antara tampilan, dan mendapatkan kembali konteks tersebut mungkin mahal. Gambar perlu diambil dan diambil, atau diminta ulang di antara tampilan.

Karena setiap tampilan harus dirender secara dinamis oleh server atau dipra-render sebelum akses, hal ini berpotensi membatasi hosting atau menambahkan kompleksitas data.

Mana yang harus dipilih?

Bahkan dengan kelebihan dan kekurangan ini, kedua arsitektur ini valid untuk membuat PWA Anda. Anda bahkan dapat mencampurnya untuk berbagai bagian aplikasi, bergantung pada kebutuhannya, misalnya, memiliki listingan Play Store yang mengikuti arsitektur MPA dan alur checkout mengikuti arsitektur SPA.

Apa pun pilihannya, langkah selanjutnya adalah memahami cara terbaik menggunakan pekerja layanan untuk memberikan pengalaman terbaik.

Kecanggihan pekerja layanan

Pekerja layanan memiliki kemampuan yang jauh lebih besar daripada perutean dasar serta pengiriman respons jaringan dan yang di-cache. Kita dapat membuat algoritma kompleks yang dapat meningkatkan pengalaman dan performa pengguna.

Pekerja layanan mencakup (SWI)

Pola yang muncul untuk menggunakan pekerja layanan sebagai bagian integral dari arsitektur situs adalah termasuk pekerja layanan (SWI). SWI membagi aset individual, biasanya halaman HTML, menjadi beberapa bagian berdasarkan kebutuhan caching, lalu menggabungkannya kembali dalam pekerja layanan untuk meningkatkan konsistensi, performa, dan keandalan, sekaligus mengurangi ukuran cache. Situs dengan header global, area konten, sidebar, dan footer.

Gambar ini adalah contoh halaman web. Ini memiliki lima bagian berbeda yang membagi halaman menjadi:

  • Tata letak keseluruhan.
  • Header global (bilah gelap atas).
  • Area konten (baris kiri tengah dan gambar).
  • Sidebar (bilah gelap sedang tinggi di bagian kanan tengah).
  • Footer (panel bawah gelap).

Tata letak keseluruhan

Tata letak keseluruhan mungkin tidak akan sering berubah dan tidak memiliki dependensi. Ini adalah kandidat yang baik untuk pra-cache.

Header dan footer global berisi hal-hal seperti menu teratas dan footer situs, serta menghadirkan tantangan tertentu: jika halaman di-cache secara keseluruhan, hal ini dapat berubah di antara pemuatan halaman, bergantung pada kapan halaman tersebut di-cache.

Dengan memisahkannya dan menyimpannya dalam cache secara terpisah dari konten, Anda dapat memastikan bahwa pengguna akan selalu mendapatkan versi yang sama, terlepas dari kapan cache tersebut di-cache. Karena jarang diupdate, solusi ini juga merupakan kandidat yang baik untuk precaching. Namun, keduanya memiliki dependensi: CSS dan JavaScript situs.

CSS dan JavaScript

Idealnya, CSS dan JavaScript situs harus di-cache dengan strategi yang tidak berlaku saat memvalidasi ulang untuk mengizinkan update inkremental tanpa perlu mengupdate pekerja layanan, seperti yang terjadi pada aset yang di-cache. Namun, keduanya juga harus dipertahankan dalam versi minimum setiap kali pekerja layanan diupdate dengan header atau footer global yang baru. Oleh karena itu, cache mereka juga harus diupdate dengan versi aset terbaru saat pekerja layanan diinstal.

Area konten

Berikutnya adalah area konten. Bergantung pada frekuensi update, jaringan terlebih dahulu atau sudah tidak berlaku saat validasi ulang adalah strategi yang tepat di sini. Gambar harus di-cache dengan strategi cache dahulu, seperti yang telah dibahas sebelumnya.

Terakhir, dengan asumsi konten bilah sisi berisi konten sekunder seperti tag dan item terkait, itu tidak cukup penting untuk diambil dari jaringan. Strategi yang sudah tidak berlaku saat memvalidasi ulang berfungsi untuk masalah ini.

Setelah mempelajari semua itu, Anda mungkin berpikir bahwa Anda hanya bisa melakukan jenis cache per bagian ini untuk aplikasi satu halaman. Namun, dengan mengadopsi pola yang terinspirasi oleh termasuk sisi tepi atau penyertaan sisi server dalam pekerja layanan, dengan beberapa fitur pekerja layanan lanjutan, Anda dapat melakukannya untuk kedua arsitektur tersebut.

Cobalah sendiri

Anda dapat mencoba menyertakan pekerja layanan dengan codelab berikutnya:

Respons aliran data

Halaman sebelumnya dapat dibuat menggunakan model shell aplikasi di dunia SPA, di mana shell aplikasi di-cache, kemudian disajikan, dan konten dimuat di sisi klien. Dengan diperkenalkannya dan tersedianya Streams API yang luas, shell aplikasi dan konten dapat digabungkan dalam pekerja layanan dan di-streaming ke browser, sehingga Anda dapat melakukan penyimpanan cache pada shell aplikasi dengan kecepatan MPA.

Hal ini dilakukan karena:

  • Streaming dapat dibuat secara asinkron, sehingga berbagai aliran data dapat berasal dari sumber lain.
  • Pemohon {i>stream<i} dapat mulai mengerjakan respons segera setelah potongan data pertama tersedia, alih-alih menunggu seluruh item selesai.
  • Parser yang dioptimalkan untuk streaming, termasuk browser, dapat secara bertahap menampilkan konten streaming sebelum streaming selesai, sehingga mempercepat performa respons yang dirasakan.

Berkat ketiga properti streaming ini, arsitektur yang dibuat berdasarkan streaming biasanya memiliki performa yang dirasakan lebih cepat daripada arsitektur yang tidak.

Menggunakan Streams API dapat menjadi tantangan karena sifatnya yang kompleks dan rendah. Untungnya, ada modul Workbox yang dapat membantu menyiapkan respons streaming untuk pekerja layanan Anda.

Domain, origin, dan cakupan PWA

Pekerja web, termasuk pekerja layanan, penyimpanan, bahkan jendela PWA yang terinstal, semuanya diatur oleh salah satu mekanisme keamanan paling penting di web: kebijakan dari origin yang sama. Dalam origin yang sama, izin diberikan, data dapat dibagikan, dan pekerja layanan dapat berkomunikasi dengan klien yang berbeda. Di luar origin yang sama, izin tidak otomatis diberikan dan data akan diisolasi serta tidak dapat diakses di antara origin yang berbeda.

Kebijakan origin yang sama

Dua URL dianggap memiliki asal yang tepat jika protokol, port, dan host-nya sama.

Misalnya: https://squoosh.app, dan https://squoosh.app/v2 memiliki asal yang sama, tetapi http://squoosh.app, https://squoosh.com, https://app.squoosh.app, dan https://squoosh.app:8080 memiliki asal yang berbeda. Lihat referensi MDN kebijakan origin yang sama untuk mengetahui informasi dan contoh selengkapnya.

Mengubah subdomain bukanlah satu-satunya cara {i>host<i} dapat berubah. Setiap host terdiri dari domain level teratas (TLD), domain level sekunder (SLD), dan nol label atau lebih (terkadang disebut subdomain), dipisahkan dengan titik di antaranya dan dibaca dari kanan ke kiri dalam URL. Perubahan pada salah satu item akan menghasilkan host yang berbeda.

Di modul pengelolaan jendela, kita telah melihat tampilan browser dalam aplikasi saat pengguna membuka asal yang berbeda dari PWA yang diinstal.

Browser dalam aplikasi tersebut akan muncul meskipun situs memiliki TLD dan SLD yang sama, tetapi dengan label yang berbeda, karena kemudian dianggap sebagai asal yang berbeda.

Salah satu aspek kunci asal dalam konteks penjelajahan web adalah cara kerja penyimpanan dan izin. Satu origin memiliki banyak fitur yang sama di antara semua konten dan PWA di dalamnya, termasuk:

  • Kuota dan data penyimpanan (IndexedDB, cookie, penyimpanan web, penyimpanan cache).
  • Pendaftaran pekerja layanan.
  • Izin yang diberikan atau ditolak (seperti web push, geolokasi, sensor).
  • Pendaftaran push web.

Saat Anda berpindah dari satu origin ke origin lainnya, semua akses sebelumnya akan dicabut, sehingga izin harus diberikan lagi, dan PWA Anda tidak dapat mengakses semua data yang disimpan di penyimpanan.

Referensi