Halaman ini diterjemahkan oleh Cloud Translation API.

Progressive Web App di situs multi-origin

Tantangan dan solusi untuk mem-build Progressive Web App di situs multi-asal.

Demián Renzulli

Latar belakang

Sebelumnya, ada beberapa keuntungan menggunakan arsitektur multi-asal, tetapi untuk Progressive Web App, pendekatan tersebut menghadirkan banyak tantangan. Secara khusus, kebijakan origin yang sama, memberlakukan batasan untuk berbagi hal-hal seperti pekerja layanan dan cache, izin, serta untuk mendapatkan pengalaman mandiri di beberapa origin. Artikel ini akan menjelaskan penggunaan yang baik dan buruk dari beberapa origin, serta menjelaskan tantangan dan solusi untuk mem-build Progressive Web App di situs multi-origin.

Penggunaan beberapa origin yang baik dan buruk

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

Kelebihan

Mari kita lihat alasan yang berguna terlebih dahulu:

Lokasi / Bahasa: Menggunakan domain level teratas kode negara, untuk memisahkan situs yang akan ditayangkan di negara yang berbeda (misalnya, https://www.google.com.ar), atau menggunakan subdomain untuk membagi situs yang ditargetkan ke lokasi yang berbeda (misalnya: https://newyork.craigslist.org) atau untuk menawarkan konten dalam bahasa tertentu (misalnya, https://en.wikipedia.org).
Webapp independen: Menggunakan subdomain yang berbeda untuk memberikan pengalaman yang tujuannya sangat berbeda dari situs di origin utama. Misalnya, di situs berita, webapp teka-teki silang dapat sengaja ditayangkan dari https://crosswords.example.com, serta diinstal dan digunakan sebagai PWA independen, tanpa harus berbagi resource atau fungsi apa pun dengan situs utama.

Hal buruk

Jika Anda tidak melakukan salah satu hal ini, kemungkinan penggunaan arsitektur multi-asal akan menjadi kerugian saat mem-build Progressive Web App.

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

Misalnya, pola berikut sangat tidak dianjurkan:

Bagian situs: Memisahkan berbagai bagian situs di subdomain. Di situs berita, tidak jarang halaman beranda berada di: https://www.example.com, sedangkan bagian olahraga berada di https://sports.example.com, politik di https://politics.example.com, dan sebagainya. Untuk situs e-commerce, gunakan sesuatu seperti https://category.example.com untuk kategori produk, https://product.example.com untuk halaman produk, dll.
Alur Penggunaan: Pendekatan lain yang tidak dianjurkan adalah memisahkan berbagai bagian situs yang lebih kecil, seperti halaman untuk alur login atau pembelian di subdomain. Misalnya, menggunakan https://login.example.com, dan https://checkout.example.com.

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

Tantangan dan Solusi untuk PWA di berbagai origin

Saat mem-build 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.

Pekerja layanan

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 bawah asal dan jalur tempat halaman tersebut 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 seperti, misalnya, halaman di https://section.example.com.

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

Menyimpan ke cache

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

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

Manfaatkan caching browser: Menggunakan praktik terbaik caching browser tradisional selalu direkomendasikan. Teknik ini memberikan manfaat tambahan berupa penggunaan kembali resource yang di-cache di seluruh 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.
Jaga agar penginstalan pekerja layanan tetap ringan: Jika Anda mengelola beberapa pekerja layanan, jangan biarkan pengguna membayar biaya penginstalan yang besar setiap kali mereka membuka origin baru. Dengan kata lain: hanya pra-cache resource yang benar-benar diperlukan.

Izin

Izin juga dicakup untuk 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, agar tidak perlu memintanya lagi.

Penginstalan

Untuk menginstal PWA, setiap origin harus memiliki manifesnya sendiri dengan start_url yang relatif terhadap dirinya sendiri. Artinya, pengguna yang menerima perintah 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 perintah 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 memitigasi masalah ini, Anda dapat memastikan bahwa perintah hanya ditampilkan di origin utama. Saat pengguna mengunjungi subdomain yang lulus kriteria penginstalan:

Memproses peristiwa beforeinstallprompt.
Cegah perintah muncul, dengan memanggil event.preventDefault().

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

Mode Mandiri

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

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

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

Kesimpulan

Kebijakan origin yang sama memberlakukan banyak batasan untuk situs yang dibuat di atas beberapa origin yang ingin mendapatkan pengalaman PWA yang koheren. Oleh karena itu, untuk memberikan pengalaman terbaik kepada pengguna, sebaiknya jangan membagi situs menjadi beberapa origin.

Untuk situs yang sudah ada dan telah dibuat dengan cara ini, mungkin sulit untuk membuat PWA multi-asal berfungsi dengan benar, tetapi kami telah mempelajari beberapa potensi solusi. 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 teknis mereka: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle, dan Andre Bandarra.