Halaman ini diterjemahkan oleh Cloud Translation API.

Progressive Web App di situs multi-origin

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

Demián Renzulli

Latar belakang

Sebelumnya, ada beberapa keuntungan dalam menggunakan arsitektur multi-asal, tetapi untuk Progressive Web App, pendekatan tersebut memberikan banyak tantangan. Secara khusus, kebijakan asal yang sama memberlakukan pembatasan untuk berbagi hal seperti pekerja layanan dan cache, izin, serta untuk mencapai pengalaman mandiri di beberapa origin. Artikel ini akan menjelaskan kelebihan dan kekurangan dari beberapa origin, serta menjelaskan tantangan dan solusi untuk membuat Progressive Web App di situs multi-asal.

Penggunaan beberapa origin dengan baik dan buruk

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

Baik

Mari kita lihat alasan yang bermanfaat terlebih dahulu:

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

Buruk

Jika Anda tidak melakukan salah satu dari hal-hal ini, kemungkinan penggunaan arsitektur multi-origin akan merugikan saat membangun 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 acak yang seharusnya menjadi bagian dari pengalaman terpadu.

Misalnya, pola berikut sangat tidak disarankan:

Bagian situs: Memisahkan bagian situs yang berbeda di subdomain. Di situs berita, tidak jarang Anda melihat halaman beranda di: https://www.example.com, saat bagian olahraga berada di https://sports.example.com, politik di https://politics.example.com, dan sebagainya. Dalam kasus situs e-commerce, gunakan 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 pada situs, seperti halaman untuk alur login atau pembelian di subdomain. Misalnya, menggunakan https://login.example.com dan https://checkout.example.com.

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

Tantangan dan Solusi untuk PWA di berbagai asal

Saat membuat situs di beberapa origin, memberikan pengalaman PWA terpadu merupakan hal yang menantang, terutama karena kebijakan origin yang sama, yang menyebabkan sejumlah batasan. Mari kita lihat satu per satu.

Service worker

Asal URL skrip pekerja layanan harus sama dengan asal halaman yang memanggil register(). Ini berarti bahwa, 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 berdasarkan asal dan jalurnya. Artinya, jika pekerja layanan 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, yang ada di https://section.example.com.

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

Menyimpan ke cache

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

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

Manfaatkan penyimpanan cache browser: Sebaiknya Anda selalu menggunakan praktik terbaik penyimpanan cache browser tradisional. Teknik ini memberikan manfaat tambahan dari 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 memelihara beberapa pekerja layanan, jangan mengharuskan pengguna membayar biaya penginstalan yang besar setiap kali mereka membuka origin baru. Dengan kata lain: hanya lakukan pra-cache sumber daya yang benar-benar diperlukan.

Izin

Izin juga mencakup origin. Ini berarti bahwa jika pengguna memberikan izin yang diberikan ke https://section.example.com origin, izin tersebut tidak akan dibawa 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 web push, Anda dapat menyimpan cookie untuk melacak apakah izin telah diterima oleh pengguna di subdomain lain, sehingga Anda tidak perlu memintanya lagi.

Penginstalan

Untuk menginstal PWA, setiap asal harus memiliki manifesnya sendiri dengan start_url yang relatif terhadap dirinya sendiri. Hal ini berarti pengguna yang menerima permintaan penginstalan di origin tertentu (yaitu: https://section.example.com) tidak akan dapat menginstal PWA dengan start_url pada halaman lain (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 membuka situs, jika setiap subdomain memenuhi kriteria penginstalan, dan meminta pengguna untuk menginstal PWA.

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

Memproses peristiwa beforeinstallprompt.
Cegah dialog muncul, yang memanggil event.preventDefault().

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

Mode Mandiri

Saat membuka di jendela mandiri, perilaku browser akan berbeda saat pengguna keluar dari cakupan yang ditetapkan oleh manifes PWA. Perilaku ini bergantung pada setiap versi browser dan vendor. 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 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 menerapkan banyak batasan untuk situs yang dibuat di atas beberapa origin yang ingin mencapai pengalaman PWA yang koheren. Oleh karena itu, untuk memberikan pengalaman terbaik kepada pengguna, sebaiknya jangan membagi situs menjadi asal yang berbeda.

Untuk situs yang sudah ada dan telah dibuat dengan cara ini, membuat PWA multi-asal berfungsi dengan benar dapat menjadi tantangan, tetapi kami telah mengeksplorasi beberapa kemungkinan solusinya. Masing-masing ada konsekuensinya, jadi gunakan penilaian Anda saat memutuskan pendekatan mana yang akan diambil 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.