Membangun beberapa Progressive Web App di domain yang sama

Cara mem-build beberapa PWA, memanfaatkan nama domain yang sama, untuk memberi tahu pengguna bahwa PWA tersebut berasal dari organisasi atau layanan yang sama.

Chase Phillips

Demián Renzulli

Matt Giuca

Dalam postingan blog Progressive Web App di situs multi-origin, Demian membahas tantangan yang dibuat situs dengan beberapa wajah asal saat mencoba membuat satu Progressive Web App yang mencakup semuanya.

Contoh jenis arsitektur situs ini adalah situs e-commerce yang:

• Halaman beranda berada di https://www.example.com.
• Halaman kategori dihosting di https://category.example.com.
• Halaman detail produk di https://product.example.com.

Seperti yang telah dibahas dalam artikel, kebijakan origin yang sama memberlakukan beberapa batasan, yang mencegah berbagi pekerja layanan, cache, dan izin di seluruh origin. Oleh karena itu, sebaiknya hindari jenis konfigurasi ini dan bagi yang sudah memiliki situs yang dibuat dengan cara ini, pertimbangkan untuk bermigrasi ke arsitektur situs origin tunggal jika memungkinkan.

Dalam postingan ini, kita akan melihat kasus sebaliknya: bukan satu PWA di berbagai origin, kita akan menganalisis kasus perusahaan yang ingin menyediakan beberapa PWA, memanfaatkan nama domain yang sama, dan membuat pengguna mengetahui bahwa PWA tersebut berasal dari organisasi atau layanan yang sama.

Seperti yang mungkin telah Anda ketahui, kami menggunakan istilah yang berbeda, tetapi saling terkait, seperti domain dan origin. Sebelum melanjutkan, mari kita tinjau konsep ini.

Istilah teknis

• Domain: Setiap urutan label seperti yang ditetapkan dalam Domain Name System (DNS). Misalnya: com dan example.com adalah domain.
• Nama host: Entri DNS yang di-resolve ke setidaknya satu alamat IP. Misalnya: www.example.com akan menjadi nama host, example.com dapat menjadi nama host jika memiliki alamat IP, dan com tidak akan pernah di-resolve ke alamat IP sehingga tidak akan pernah menjadi nama host.
• Origin: Kombinasi skema, nama host, dan (opsional) port. Misalnya, https://www.example.com:443 adalah asal.

Seperti namanya, kebijakan origin yang sama memberlakukan batasan pada origin, jadi kita akan sering merujuk pada istilah ini di seluruh artikel. Namun, kami akan menggunakan "domain" atau "subdomain" dari waktu ke waktu, untuk menjelaskan teknik yang digunakan, guna membuat berbagai "asal".

Kasus untuk beberapa PWA terkait

Dalam beberapa kasus, Anda mungkin ingin mem-build aplikasi independen, tetapi tetap mengidentifikasinya sebagai milik organisasi atau "merek" yang sama. Menggunakan kembali nama domain yang sama adalah cara yang baik untuk membangun hubungan tersebut. Contoh:

• Situs e-commerce ingin membuat pengalaman mandiri untuk memungkinkan penjual mengelola inventaris mereka, sekaligus memastikan mereka memahami bahwa inventaris tersebut milik situs utama tempat pengguna membeli produk.
• Situs berita olahraga ingin membuat aplikasi tertentu untuk acara olahraga besar, agar pengguna dapat menerima statistik tentang kompetisi favorit mereka melalui notifikasi, dan menginstalnya sebagai Progressive Web App, sekaligus memastikan bahwa pengguna mengenalinya sebagai aplikasi yang dibuat oleh perusahaan berita.
• Sebuah perusahaan ingin membuat aplikasi chat, email, dan kalender terpisah dan ingin aplikasi tersebut berfungsi sebagai aplikasi individual, yang terkait dengan nama perusahaan.

Menggunakan origin terpisah

Pendekatan yang direkomendasikan dalam kasus seperti ini adalah untuk setiap aplikasi yang secara konsep berbeda berada di origin-nya sendiri.

Jika ingin menggunakan nama domain yang sama di dalamnya, Anda dapat melakukannya dengan menggunakan subdomain. Misalnya, perusahaan yang menyediakan beberapa aplikasi atau layanan internet dapat menghosting aplikasi email di https://mail.example.com dan aplikasi kalender di https://calendar.example.com, sekaligus menawarkan layanan utama bisnis mereka di https://www.example.com. Contoh lainnya adalah situs olahraga yang ingin membuat aplikasi independen yang sepenuhnya didedikasikan untuk acara olahraga penting, seperti kejuaraan sepak bola di https://footballcup.example.com, yang dapat diinstal dan digunakan pengguna secara terpisah dari situs olahraga utama, yang dihosting di https://www.example.com. Pendekatan ini mungkin juga berguna untuk platform yang memungkinkan pelanggan membuat aplikasi independen mereka sendiri dengan merek perusahaan. Misalnya, aplikasi yang memungkinkan penjual membuat PWA mereka sendiri di https://merchant1.example.com, https://merchant2.example.com, dll.

Menggunakan origin yang berbeda akan memastikan isolasi antar-aplikasi, yang berarti bahwa setiap aplikasi dapat mengelola berbagai fitur browser secara independen, termasuk:

• Kemampuan penginstalan: Setiap aplikasi memiliki Manifesnya sendiri dan memberikan pengalamannya sendiri yang dapat diinstal.
• Penyimpanan: Setiap aplikasi memiliki cache, penyimpanan lokal, dan pada dasarnya semua bentuk penyimpanan lokal perangkat, tanpa membagikannya dengan aplikasi lain.
• Pekerja Layanan: Setiap aplikasi memiliki pekerja layanannya sendiri untuk cakupan yang terdaftar.
• Izin: Izin juga dicakup oleh origin. Berkat hal ini, pengguna akan tahu persis layanan mana yang izinnya mereka berikan, dan fitur seperti notifikasi akan diatribusikan dengan benar ke setiap aplikasi.

Membuat tingkat isolasi seperti itu sangat diinginkan dalam kasus penggunaan beberapa PWA independen, sehingga kami sangat merekomendasikan pendekatan ini.

Jika aplikasi di subdomain ingin berbagi data lokal satu sama lain, aplikasi tersebut masih dapat melakukannya melalui cookie, atau untuk skenario yang lebih canggih, aplikasi tersebut dapat mempertimbangkan untuk menyinkronkan penyimpanan melalui server.

Menggunakan origin yang sama

Pendekatan kedua adalah mem-build berbagai PWA di origin yang sama. Hal ini mencakup skenario berikut:

Jalur yang tidak tumpang-tindih

Beberapa PWA atau "aplikasi web" konseptual yang dihosting di origin yang sama, dengan jalur yang tidak tumpang-tindih. Contoh:

• https://example.com/app1/
• https://example.com/app2/

Jalur tumpang-tindih/bertingkat

Beberapa PWA di origin yang sama, salah satu cakupannya bertingkat di dalam yang lain:

• https://example.com/ ("aplikasi luar")
• https://example.com/app/ ("aplikasi dalam")

API pekerja layanan dan format manifes memungkinkan Anda melakukan salah satu hal di atas, menggunakan cakupan tingkat jalur. Namun, dalam kedua kasus tersebut, penggunaan origin yang sama akan menimbulkan banyak masalah dan batasan. Akarnya berasal dari fakta bahwa browser tidak akan sepenuhnya menganggapnya sebagai "aplikasi" yang berbeda, sehingga pendekatan ini tidak disarankan.

Di bagian berikutnya, kita akan menganalisis tantangan ini secara lebih mendetail, dan hal yang dapat dilakukan jika tidak dapat menggunakan origin terpisah.

Tantangan untuk beberapa PWA dengan origin yang sama

Berikut beberapa masalah praktis yang umum untuk kedua pendekatan dengan origin yang sama:

• Penyimpanan: Cookie, penyimpanan lokal, dan semua bentuk penyimpanan lokal perangkat dibagikan antar-aplikasi. Oleh karena itu, jika pengguna memutuskan untuk menghapus total data lokal untuk satu aplikasi, tindakan ini akan menghapus total semua data dari origin; tidak ada cara untuk melakukannya untuk satu aplikasi. Perhatikan bahwa Chrome dan beberapa browser lainnya akan secara aktif meminta pengguna untuk menghapus total data lokal saat meng-uninstal salah satu aplikasi, dan tindakan ini juga akan memengaruhi data untuk aplikasi lain di origin. Masalah lainnya adalah aplikasi juga harus berbagi kuota penyimpanan, yang berarti jika salah satu darinya menggunakan terlalu banyak ruang, aplikasi lainnya akan terpengaruh secara negatif.
• Izin: Izin browser terikat dengan origin. Artinya, jika pengguna memberikan izin ke satu aplikasi, izin tersebut akan berlaku untuk semua aplikasi pada origin tersebut secara bersamaan. Hal ini mungkin terdengar seperti hal yang baik (tidak perlu meminta izin beberapa kali), tetapi ingat: jika pengguna memblokir izin ke satu aplikasi, pengguna lain tidak akan dapat meminta izin tersebut atau menggunakan fitur tersebut. Perhatikan bahwa meskipun izin browser hanya perlu diberikan satu kali per origin, izin tingkat sistem di sisi lain harus diberikan satu kali per aplikasi, terlepas dari apakah beberapa aplikasi mengarah ke origin yang sama.
• Setelan pengguna: Setelan juga ditetapkan per origin. Misalnya, jika dua aplikasi memiliki ukuran font yang berbeda, dan pengguna ingin menyesuaikan zoom hanya di salah satu aplikasi untuk mengimbanginya, mereka tidak akan dapat melakukannya tanpa menerapkan setelan ke aplikasi lain juga.

Tantangan ini membuat pendekatan ini sulit didorong. Namun, jika Anda tidak dapat menggunakan origin terpisah (misalnya subdomain), seperti yang dibahas di bagian Menggunakan origin terpisah, dari dua opsi origin yang sama yang kami sajikan, sebaiknya gunakan jalur yang tidak tumpang-tindih, daripada jalur tumpang-tindih/bertingkat.

Seperti yang disebutkan, tantangan yang dibahas di bagian ini berlaku umum untuk kedua pendekatan dengan origin yang sama. Di bagian berikutnya, kita akan membahas lebih dalam alasan penggunaan jalur tumpang-tindih/bertingkat adalah strategi yang paling tidak direkomendasikan.

Tantangan tambahan untuk jalur tumpang-tindih/bertingkat

Masalah tambahan dengan pendekatan jalur yang tumpang-tindih/bertingkat (dengan https://example.com/ adalah aplikasi luar dan https://example.com/app/ adalah aplikasi bagian dalam), adalah bahwa semua URL di aplikasi bagian dalam akan benar-benar dianggap sebagai bagian dari aplikasi luar dan aplikasi bagian dalam.

Dalam praktiknya, hal ini menimbulkan masalah berikut:

• Promosi Penginstalan: Jika pengguna mengunjungi aplikasi dalam (misalnya, di browser web), saat aplikasi luar sudah diinstal di perangkat pengguna, browser tidak akan menampilkan banner promosi penginstalan, dan peristiwa BeforeInstallPrompt tidak akan dipicu. Alasannya adalah browser akan memeriksa dan melihat apakah halaman saat ini adalah milik aplikasi yang sudah diinstal, dan akan menyimpulkan bahwa halaman tersebut adalah milik aplikasi yang sudah diinstal. Solusi untuk hal ini adalah menginstal aplikasi dalam secara manual (melalui opsi menu browser "Buat Pintasan"), atau menginstal aplikasi dalam terlebih dahulu, sebelum aplikasi luar.
• Notifikasi dan Badging API: Jika aplikasi luar diinstal tetapi aplikasi bagian dalam tidak diinstal, notifikasi dan badge yang berasal dari aplikasi bagian dalam akan keliru diatribusikan ke aplikasi luar (yang merupakan cakupan terdekat dari aplikasi terinstal). Fitur ini berfungsi dengan baik jika kedua aplikasi diinstal di perangkat pengguna.
• Pengambilan Link: Aplikasi luar dapat mengambil URL yang termasuk dalam aplikasi dalam. Hal ini terutama mungkin jika aplikasi luar diinstal, tetapi aplikasi dalam tidak. Demikian pula, link dalam aplikasi luar yang ditautkan ke aplikasi dalam tidak akan menautkan rekaman ke aplikasi dalam, karena dianggap berada dalam cakupan aplikasi luar. Selain itu, di ChromeOS dan Android, jika aplikasi ini ditambahkan ke Play Store (sebagai Aktivitas Web Tepercaya), aplikasi luar akan mengambil semua link. Meskipun aplikasi dalam diinstal, OS masih akan menawarkan pilihan kepada pengguna untuk membukanya di aplikasi luar.

Kesimpulan

Dalam artikel ini, kita melihat berbagai cara yang dapat dilakukan developer untuk mem-build beberapa Progressive Web App yang saling terkait dalam domain yang sama.

Singkatnya, sebaiknya gunakan origin yang berbeda (misalnya dengan menggunakan subdomain) untuk menghosting PWA independen. Menghostingnya di origin yang sama akan menimbulkan banyak tantangan, terutama karena browser tidak akan sepenuhnya menganggapnya sebagai aplikasi yang berbeda.

• Asal terpisah: Direkomendasikan
• Asal yang sama, jalur yang tidak tumpang-tindih: Tidak direkomendasikan
• Asal sama, jalur yang tumpang-tindih/bertingkat: Sangat tidak direkomendasikan

Jika tidak dapat menggunakan origin yang berbeda, sebaiknya gunakan jalur yang tidak tumpang-tindih (misalnya, https://example.com/app1/ dan https://example.com/app2/) daripada menggunakan jalur tumpang-tindih atau bertingkat, seperti https://example.com/ (untuk aplikasi luar) dan https://example.com/app/ (untuk aplikasi dalam).

Referensi lainnya

• Progressive Web App di situs multi-asal

Terima kasih banyak atas ulasan dan saran teknis mereka: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner, dan Darwin Huang

Foto oleh Tim Mossholder di Unsplash