Progressive Web App di situs multi-origin

Tantangan dan solusi untuk membangun Progressive Web App di situs multi-origin.

Demián Renzulli

Dipublikasikan: 19 Agustus 2019

Sebelumnya, ada beberapa keuntungan menggunakan arsitektur multi-origin. Untuk Progressive Web App, pendekatan tersebut menimbulkan banyak tantangan. Secara khusus, kebijakan origin yang sama, menerapkan batasan untuk berbagi hal-hal seperti pekerja layanan dan cache, izin, dan untuk mencapai pengalaman mandiri di beberapa origin.

Temukan penggunaan multi-origin yang baik dan buruk, serta jelaskan tantangan dan solusi untuk membangun Progressive Web App di situs multi-origin.

Penggunaan beberapa origin yang baik dan buruk

Ada beberapa alasan yang sah bagi situs untuk menggunakan arsitektur multi-origin, yang sebagian besar terkait dengan penyediaan kumpulan aplikasi web independen, atau untuk menciptakan pengalaman yang sepenuhnya terisolasi satu sama lain. Ada juga penggunaan yang harus dihindari.

Kelebihan

Lihat alasan yang berguna terlebih dahulu:

• Pelokalan/Bahasa: Menggunakan domain level teratas kode negara, untuk memisahkan situs yang akan ditayangkan di berbagai negara (misalnya, https://www.google.com.ar), atau menggunakan subdomain untuk membagi situs yang ditargetkan ke berbagai lokasi (misalnya: https://newyork.craigslist.org) atau untuk menawarkan konten dalam bahasa tertentu (misalnya, https://en.wikipedia.org).

• Aplikasi web independen: Menggunakan subdomain yang berbeda untuk memberikan pengalaman yang tujuannya sangat berbeda dari situs di origin utama. Misalnya, di situs berita, aplikasi web teka-teki silang dapat sengaja disajikan dari https://crosswords.example.com, serta diinstal dan digunakan sebagai PWA independen, tanpa harus berbagi resource atau fungsi dengan situs utama.

Kekurangan

Jika Anda tidak melakukan hal-hal tersebut, kemungkinan penggunaan arsitektur multi-origin akan menjadi kerugian saat membangun Progressive Web App.

Meskipun demikian, banyak situs yang terus disusun dengan cara ini tanpa alasan tertentu, atau karena alasan 'lama'. Salah satu contohnya adalah menggunakan subdomain untuk memisahkan bagian situs secara arbitrer yang seharusnya menjadi bagian dari pengalaman terpadu.

Misalnya, pola berikut sangat tidak dianjurkan:

• Bagian situs: Memisahkan berbagai bagian situs di subdomain. Di situs berita, halaman beranda biasanya berada di: https://www.example.com, sedangkan bagian olahraga berada di https://sports.example.com, politik di https://politics.example.com, dan seterusnya. Dalam kasus situs e-commerce, gunakan sesuatu seperti https://category.example.com untuk kategori produk, https://product.example.com untuk halaman produk, dll.

• Alur Pengguna: Pendekatan lain yang tidak disarankan adalah memisahkan bagian-bagian kecil yang berbeda dari situs, seperti halaman untuk alur login atau pembelian di subdomain. Misalnya, menggunakan https://login.example.com, dan https://checkout.example.com.

Catatan: Saat membuat situs dari awal, sebaiknya hindari membaginya menjadi subdomain. Untuk situs yang sudah ada, bermigrasi ke satu origin adalah pendekatan terbaik.

Untuk kasus yang tidak memungkinkan migrasi ke satu origin, berikut adalah daftar tantangan, dan (jika memungkinkan), solusi yang dapat dipertimbangkan saat membangun Progressive Web App.

Tantangan dan solusi untuk PWA di berbagai origin

Saat membangun situs di beberapa origin, memberikan pengalaman PWA terpadu merupakan tantangan, terutama karena kebijakan origin yang sama, yang memberlakukan sejumlah batasan. Mari kita lihat satu per satu.

Service worker

Origin URL skrip pekerja layanan harus sama dengan origin halaman yang memanggil register(). Artinya, misalnya, halaman di https://www.example.com tidak dapat memanggil register() dengan URL pekerja layanan di https://section.example.com.

Pertimbangan lainnya adalah pekerja layanan hanya dapat mengontrol halaman yang dihosting di origin dan jalur tempatnya berada. Artinya, jika dihosting di https://www.example.com, pekerja layanan hanya dapat mengontrol URL dari origin tersebut (sesuai dengan jalur yang ditentukan dalam parameter cakupan), tetapi tidak akan mengontrol halaman apa pun di subdomain lain, misalnya, halaman di https://section.example.com.

Dalam hal ini, satu-satunya solusi adalah menggunakan beberapa pekerja layanan (satu per origin).

Perhatian: Mendaftarkan dan memiliki beberapa pekerja layanan aktif akan menggunakan resource tambahan (memori, CPU, dll.), jadi gunakan pertimbangan terbaik Anda tentang berapa banyak pekerja layanan aktif yang mungkin diperlukan pengguna untuk menjelajahi situs.

Menyimpan ke cache

Objek Cache, indexedDB, dan localStorage juga dibatasi untuk satu origin. Artinya, cache milik https://www.example.com tidak dapat diakses, misalnya, dari: https://www.section.example.com.

Berikut beberapa hal yang dapat Anda lakukan untuk mengelola cache dengan benar dalam skenario seperti ini:

• Manfaatkan caching browser: Sebaiknya gunakan praktik terbaik caching browser tradisional. Teknik ini memberikan manfaat tambahan berupa penggunaan kembali resource yang di-cache di berbagai origin, yang tidak dapat dilakukan dengan cache pekerja layanan. Untuk praktik terbaik tentang cara menggunakan Cache HTTP dengan pekerja layanan, Anda dapat melihat postingan ini.

• Buat penginstalan pekerja layanan tetap ringan: Jika Anda mengelola beberapa pekerja layanan, hindari membuat pengguna membayar biaya penginstalan yang besar setiap kali mereka membuka origin baru. Dengan kata lain: hanya pra-cache resource yang benar-benar diperlukan.

Setelah pekerja layanan aktif dan berjalan, kebijakan origin yang sama juga membatasi permintaan lintas origin yang dibuat di dalam pekerja layanan. Untungnya, ada solusi yang direkomendasikan untuk masalah ini, yaitu menggunakan CORS (seperti yang dijelaskan di sini). Sebaiknya jangan gunakan mode no-cors saat mengambil resource di dalam pekerja layanan.

Izin

Izin juga dicakupkan ke origin. Artinya, jika pengguna memberikan izin tertentu ke origin https://section.example.com, izin tersebut tidak akan diterapkan ke origin lain, seperti https://www.example.com.

Karena tidak ada cara untuk membagikan izin di seluruh origin, satu-satunya solusi di sini adalah meminta izin di setiap subdomain tempat fitur tertentu diperlukan (misalnya, lokasi). Untuk hal-hal seperti push web, Anda dapat mempertahankan cookie untuk melacak apakah izin telah diterima oleh pengguna di subdomain lain, untuk menghindari permintaan izin lagi.

Penginstalan

Untuk menginstal PWA, setiap origin harus memiliki manifesnya sendiri dengan start_url yang relatif terhadap dirinya sendiri. Artinya, pengguna yang menerima dialog penginstalan di origin tertentu (yaitu: https://section.example.com) tidak akan dapat menginstal PWA dengan start_url di origin yang berbeda (yaitu: https://www.example.com). Dengan kata lain, pengguna yang menerima dialog penginstalan di subdomain hanya akan dapat menginstal PWA untuk subhalaman, bukan untuk URL utama aplikasi.

Ada juga masalah bahwa pengguna yang sama dapat menerima beberapa perintah penginstalan saat menjelajahi situs, jika setiap subdomain memenuhi kriteria penginstalan, dan meminta pengguna untuk menginstal PWA.

Untuk mengurangi masalah ini, Anda dapat memastikan bahwa dialog hanya ditampilkan di origin utama. Saat pengguna mengunjungi subdomain yang memenuhi kriteria penginstalan:

1. Memproses peristiwa beforeinstallprompt.
2. Mencegah perintah muncul, dengan memanggil event.preventDefault().

Dengan begitu, Anda dapat memastikan bahwa dialog tidak ditampilkan di bagian situs yang tidak diinginkan, sekaligus terus menampilkannya, misalnya, di origin utama (misalnya, Halaman beranda).

Mode mandiri

Saat menjelajah di jendela mandiri, browser akan berperilaku berbeda saat pengguna berpindah ke luar cakupan yang ditetapkan oleh manifes PWA. Perilaku ini bergantung pada setiap versi dan vendor browser. Misalnya, versi Chrome terbaru membuka Tab Khusus Chrome, saat pengguna keluar dari cakupan dalam mode mandiri.

Umumnya, tidak ada solusi untuk hal ini, tetapi solusi sementara dapat diterapkan untuk sebagian kecil pengalaman yang dihosting di subdomain (misalnya: alur kerja login):

1. URL baru, https://login.example.com, dapat dibuka di dalam iframe layar penuh.
2. Setelah tugas selesai di dalam iframe (misalnya, proses login), postMessage() dapat digunakan untuk meneruskan informasi yang dihasilkan dari iframe kembali ke halaman induk.
3. Sebagai langkah terakhir, setelah pesan diterima oleh halaman utama, pemroses dapat dibatalkan pendaftarannya, dan iframe akhirnya dihapus dari DOM.

Perhatian: Teknik sebelumnya dapat membantu mengurangi potensi perubahan UI di sebagian kecil situs, tempat pengguna dapat melakukan tindakan di subdomain dan kembali ke origin utama (seperti dalam alur login), tetapi tidak akan menjadi teknik yang efisien untuk diterapkan di seluruh jalur, termasuk banyak halaman yang dihosting di subdomain (seperti seluruh bagian situs).

Catatan: Dalam konteks Aktivitas Web Tepercaya, ada cara yang direkomendasikan untuk menghindari masalah ini, dengan memvalidasi semua origin menggunakan Digital Asset Links.

Kesimpulan

Kebijakan origin yang sama menerapkan banyak batasan untuk situs yang dibangun di atas beberapa origin yang ingin mencapai pengalaman PWA yang koheren. Oleh karena itu, untuk memberikan pengalaman terbaik kepada pengguna, kami sangat menyarankan agar situs tidak dibagi menjadi origin yang berbeda.

Untuk situs yang sudah dibuat dengan cara ini, mungkin akan sulit untuk membuat PWA multi-origin berfungsi dengan benar, tetapi kami telah mengeksplorasi beberapa solusi potensial. Setiap pendekatan dapat memiliki konsekuensi, jadi gunakan penilaian Anda saat memutuskan pendekatan mana yang akan digunakan di situs Anda.

Saat mengevaluasi strategi jangka panjang atau desain ulang situs, pertimbangkan untuk bermigrasi ke satu origin, kecuali jika ada alasan penting untuk mempertahankan arsitektur multi-origin.

Terima kasih banyak atas ulasan dan saran teknisnya: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle, dan Andre Bandarra.