Membangun beberapa Progressive Web App di domain yang sama

Cara membuat beberapa PWA, dengan memanfaatkan nama domain yang sama, untuk membuat pengguna menyadari bahwa PWA tersebut termasuk dalam 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 dihadapi situs yang dibangun di beberapa origin saat mencoba membangun satu Progressive Web App yang mencakup semuanya.

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

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

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

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

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

Istilah teknis

• Domain: Urutan label apa pun seperti yang ditentukan 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 menjadi 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 ke istilah tersebut di seluruh artikel. Namun, dari waktu ke waktu, kami akan menggunakan "domain" atau "subdomain" untuk mendeskripsikan teknik yang digunakan, guna membuat "origin" yang berbeda.

Kasus untuk beberapa PWA terkait

Dalam beberapa kasus, Anda mungkin ingin membuat 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 pengalaman tersebut adalah bagian dari situs utama tempat pengguna membeli produk.
• Situs berita olahraga ingin membuat aplikasi khusus untuk acara olahraga besar, agar pengguna dapat menerima statistik tentang kompetisi favorit mereka melalui notifikasi, dan menginstalnya sebagai Aplikasi Web Progresif, sekaligus memastikan bahwa pengguna mengenalinya sebagai aplikasi yang dibuat oleh perusahaan berita tersebut.
• Perusahaan ingin membuat aplikasi chat, email, dan kalender terpisah dan ingin aplikasi tersebut berfungsi sebagai aplikasi individual, yang terhubung ke nama perusahaan.

Menggunakan asal terpisah

Pendekatan yang direkomendasikan dalam kasus seperti ini adalah setiap aplikasi yang berbeda secara konseptual ditayangkan di originnya 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 independen dari situs olahraga utama, yang dihosting di https://www.example.com. Pendekatan ini juga dapat 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 memastikan isolasi antar-aplikasi, yang berarti bahwa setiap aplikasi dapat mengelola fitur browser yang berbeda secara independen, termasuk:

• Kemampuan penginstalan: Setiap aplikasi memiliki Manifesnya sendiri dan memberikan pengalaman yang dapat diinstal sendiri.
• Penyimpanan: Setiap aplikasi memiliki cache, penyimpanan lokal, dan pada dasarnya semua bentuk penyimpanan lokal perangkatnya sendiri, tanpa membagikannya dengan aplikasi lain.
• Service Worker: Setiap aplikasi memiliki service worker-nya sendiri untuk cakupan yang terdaftar.
• Izin: Izin juga dicakup berdasarkan origin. Dengan begitu, pengguna akan mengetahui secara pasti layanan mana yang mereka beri izin, dan fitur seperti notifikasi akan diatribusikan dengan benar ke setiap aplikasi.

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

Jika aplikasi di subdomain ingin berbagi data lokal satu sama lain, aplikasi tersebut tetap 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 membangun PWA yang berbeda di origin yang sama. Hal ini mencakup skenario berikut:

Jalur yang tidak tumpang-tindih

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

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

Jalur yang tumpang-tindih/bertingkat

Beberapa PWA dengan asal yang sama, yang cakupannya bersarang di dalam cakupan PWA 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, menggunakan origin yang sama menimbulkan banyak masalah dan batasan, yang berakar 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 apa yang dapat dilakukan, jika menggunakan origin terpisah bukan merupakan opsi.

Tantangan untuk beberapa PWA dengan asal yang sama

Berikut beberapa masalah praktis yang umum untuk kedua pendekatan same-origin:

• 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, semua data dari origin akan dihapus total; tidak ada cara untuk melakukan hal ini pada satu aplikasi. Perhatikan bahwa Chrome dan beberapa browser lain akan secara aktif meminta pengguna untuk menghapus total data lokal saat meng-uninstal salah satu aplikasi, dan hal ini juga akan memengaruhi data untuk aplikasi lain di origin. Masalah lainnya adalah aplikasi juga harus membagikan kuota penyimpanan, yang berarti jika salah satu aplikasi menggunakan terlalu banyak ruang, aplikasi lainnya akan terpengaruh secara negatif.
• Izin: Izin browser terikat ke origin. Artinya, jika pengguna memberikan izin ke satu aplikasi, izin tersebut akan berlaku untuk semua aplikasi di origin tersebut secara bersamaan. Hal ini mungkin terdengar bagus (tidak perlu meminta izin beberapa kali), tetapi ingat: jika pengguna memblokir izin ke satu aplikasi, aplikasi 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 satunya untuk mengimbanginya, mereka tidak akan dapat melakukannya tanpa menerapkan setelan ke aplikasi lain juga.

Tantangan ini membuat pendekatan ini sulit diterapkan. 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 yang tumpang-tindih/bertingkat.

Seperti yang disebutkan, tantangan yang dibahas di bagian ini umum untuk kedua pendekatan same-origin. Di bagian berikutnya, kita akan membahas lebih dalam detail mengapa penggunaan jalur yang tumpang-tindih/bernested adalah strategi yang paling tidak direkomendasikan.

Tantangan tambahan untuk jalur yang 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 dalam), adalah semua URL di aplikasi dalam sebenarnya akan dianggap sebagai bagian dari aplikasi luar dan aplikasi dalam.

Dalam praktiknya, hal ini menimbulkan masalah berikut:

• Promosi Penginstalan: Jika pengguna membuka 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 termasuk dalam aplikasi yang sudah diinstal, dan akan menyimpulkan bahwa halaman tersebut termasuk dalam aplikasi yang sudah diinstal. Solusinya 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 dalam tidak, notifikasi dan badge yang berasal dari aplikasi dalam akan keliru dikaitkan dengan aplikasi luar (yang merupakan cakupan penutup terdekat dari aplikasi yang diinstal). Fitur ini berfungsi dengan baik jika kedua aplikasi diinstal di perangkat pengguna.
• Penangkapan Link: Aplikasi luar dapat mengambil URL yang termasuk dalam aplikasi dalam. Hal ini sangat mungkin terjadi jika aplikasi luar diinstal, tetapi aplikasi dalam tidak. Demikian pula, link dalam aplikasi luar yang menautkan ke aplikasi dalam tidak akan menangkap link ke dalam aplikasi dalam, karena dianggap berada dalam cakupan aplikasi luar. Selain itu, di ChromeOS dan Android, jika aplikasi ini ditambahkan ke Play Store (sebagai Trusted Web Activities), aplikasi luar akan mengambil semua link. Meskipun aplikasi dalam sudah diinstal, OS akan tetap menawarkan pilihan kepada pengguna untuk membukanya di aplikasi luar.

Kesimpulan

Dalam artikel ini, kita telah membahas berbagai cara yang dapat dilakukan developer untuk membuat 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 menimbulkan banyak tantangan, terutama karena browser tidak akan sepenuhnya menganggap keduanya sebagai aplikasi yang berbeda.

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

Jika tidak memungkinkan untuk menggunakan origin yang berbeda, sebaiknya gunakan jalur yang tidak tumpang-tindih (misalnya, https://example.com/app1/ dan https://example.com/app2/) daripada menggunakan jalur yang 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-origin

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