Halaman ini diterjemahkan oleh Cloud Translation API.

Progressive Web App di situs multi-origin

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

Demián Renzulli

Latar belakang

Di masa lalu, ada beberapa keuntungan menggunakan arsitektur multi-origin, tetapi untuk Progressive Web App, pendekatan tersebut menimbulkan banyak tantangan. Secara khusus, kebijakan origin yang sama menerapkan pembatasan untuk berbagi 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 membangun Progressive Web App di situs multi-origin.

Penggunaan berbagai asal yang baik dan yang buruk

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

Kebaikan

Mari kita lihat alasan yang berguna terlebih dahulu:

Pelokalan / 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 berbeda (misalnya: https://newyork.craigslist.org) atau menawarkan konten dalam bahasa tertentu (misalnya, https://en.wikipedia.org).
Aplikasi web independen: Menggunakan subdomain yang berbeda untuk memberikan pengalaman yang tujuannya sangat berbeda dengan situs di asal utama. Misalnya, di situs berita, aplikasi web teka-teki silang dapat sengaja ditayangkan dari https://crosswords.example.com, lalu diinstal dan digunakan sebagai PWA independen, tanpa harus membagikan referensi atau fungsi apa pun ke situs utama.

Hal buruk

Jika Anda tidak melakukan salah satu dari hal-hal ini, kemungkinan bahwa menggunakan arsitektur multi-asal akan menjadi kerugian saat membangun Progressive Web App.

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

Pola berikut, misalnya, sangat tidak disarankan:

Bagian situs: Memisahkan bagian situs yang berbeda di subdomain. Di situs berita, halaman beranda biasanya ada di: https://www.example.com, sedangkan rubrik olahraga ditampilkan 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 Pengguna: Pendekatan lain yang tidak disarankan 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 yang tidak memungkinkan migrasi ke satu origin, berikut daftar tantangannya, 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 menjadi tantangan tersendiri, terutama karena kebijakan origin yang sama, yang menimbulkan sejumlah batasan. Mari kita lihat satu per satu.

Service worker

Asal URL skrip pekerja layanan harus sama dengan asal halaman yang memanggil register(). Artinya, sebagai contoh, 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 pada asal dan jalurnya. Artinya, jika pekerja layanan dihosting di https://www.example.com, pekerja layanan hanya dapat mengontrol URL dari asal tersebut (sesuai dengan jalur yang ditentukan dalam parameter cakupan), tetapi tidak akan mengontrol halaman apa pun di subdomain lain seperti, misalnya, halaman dalam https://section.example.com.

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

Menyimpan ke cache

Objek Cache, indexedDB, dan localStorage juga dibatasi pada satu origin. 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: Praktik terbaik penyimpanan cache 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.
Pastikan penginstalan pekerja layanan tetap ringan: Jika Anda mengelola beberapa pekerja layanan, hindari membuat pengguna membayar biaya penginstalan yang besar setiap kali mereka menavigasi ke origin baru. Dengan kata lain: hanya lakukan pra-cache resource yang benar-benar diperlukan.

Izin

Izin juga mencakup origin. Artinya, jika pengguna memberikan izin yang diberikan ke https://section.example.com asal, 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 yang memerlukan fitur tertentu (misalnya, lokasi). Untuk hal-hal seperti web push, Anda dapat mengelola cookie untuk melacak apakah izin telah diterima oleh pengguna di subdomain lain, agar tidak memintanya lagi.

Penginstalan

Untuk menginstal PWA, setiap origin harus memiliki manifesnya sendiri dengan start_url yang relatif terhadap PWA itu 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 permintaan 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 meneruskan kriteria penginstalan:

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

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

Mode Mandiri

Saat membuka jendela mandiri, browser akan berperilaku berbeda saat pengguna bergerak ke luar 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.

Dalam sebagian besar kasus, 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 dari origin yang sama menerapkan banyak batasan untuk situs yang dibuat di beberapa origin yang ingin mencapai pengalaman PWA yang koheren. Oleh karena itu, untuk memberikan pengalaman terbaik kepada pengguna, sebaiknya Anda tidak membagi situs ke dalam origin yang berbeda.

Untuk situs yang sudah ada yang telah dibuat dengan cara ini, membuat PWA multi-origin berfungsi dengan benar dapat menjadi pekerjaan berat, tetapi kami telah mempelajari beberapa potensi solusi. Setiap pendekatan memiliki konsekuensi, 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 saran dan peninjauan teknis mereka: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle, dan Andre Bandarra.