Membangun beberapa Progressive Web App di domain yang sama

Cara membuat beberapa PWA, dengan memanfaatkan nama domain yang sama, untuk membuat pengguna sadar bahwa mereka adalah milik organisasi atau layanan yang sama.

Chase Phillips

Demián Renzulli

Matt Giuca

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

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

• Halaman berandanya 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 origin yang sama menerapkan beberapa batasan, yang mencegah berbagi pekerja layanan, cache, dan izin di seluruh origin. Oleh karena itu, sebaiknya hindari jenis konfigurasi ini dan bagi pengguna yang telah memiliki situs yang dibuat dengan cara ini, sebaiknya pertimbangkan untuk bermigrasi ke arsitektur situs origin tunggal jika memungkinkan.

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

Seperti yang mungkin telah Anda perhatikan, kita menggunakan istilah yang berbeda, tetapi saling terkait, seperti domain dan origin. Sebelum melangkah maju, 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 menjadi 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 diselesaikan menjadi alamat IP, sehingga tidak pernah menjadi nama host.
• Asal: Kombinasi skema, nama host, dan port (opsional). Misalnya, https://www.example.com:443 adalah origin.

Sesuai dengan namanya, kebijakan origin yang sama menerapkan pembatasan pada origin, jadi kami akan merujuk ke istilah tersebut di seluruh artikel. Meskipun demikian, kami akan menggunakan "domain" atau "subdomain" dari waktu ke waktu, untuk menjelaskan teknik yang digunakan, untuk 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 tepat untuk membentuk hubungan tersebut. Contoh:

• Situs e-commerce ingin membuat pengalaman mandiri yang memungkinkan penjual mengelola inventaris mereka, sekaligus memastikan mereka memahami bahwa inventaris tersebut milik situs utama tempat pengguna membeli produk.
• Sebuah 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 Progressive Web App, sekaligus memastikan bahwa pengguna mengenalinya sebagai aplikasi yang dibuat oleh perusahaan berita.
• Perusahaan ingin membuat aplikasi chat, email, dan kalender yang terpisah dan ingin aplikasi tersebut berfungsi sebagai aplikasi individual, yang terikat dengan nama perusahaan.

Menggunakan origin terpisah

Pendekatan yang direkomendasikan dalam kasus-kasus seperti ini adalah untuk setiap aplikasi yang berbeda secara konseptual berada di asalnya sendiri.

Jika ingin menggunakan nama domain yang sama di semua domain, 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 dikhususkan untuk acara olahraga penting, seperti kejuaraan sepak bola di https://footballcup.example.com, yang dapat diinstal dan digunakan oleh pengguna secara terpisah dari situs olahraga utama, yang diselenggarakan di https://www.example.com. Pendekatan ini mungkin juga berguna untuk platform yang memungkinkan pelanggan membuat aplikasi independen sendiri di bawah 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 setiap aplikasi dapat mengelola fitur browser yang berbeda secara independen, termasuk:

• Dapat diinstal: 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 perangkat, tanpa membagikannya dengan aplikasi lain.
• Pekerja Layanan: Setiap aplikasi memiliki pekerja layanannya sendiri untuk cakupan yang terdaftar.
• Izin: Izin juga dicakup berdasarkan origin. Dengan demikian, pengguna akan mengetahui dengan pasti layanan mana yang izinnya mereka berikan, dan fitur seperti notifikasi akan diatribusikan dengan benar ke setiap aplikasi.

Membuat tingkat isolasi semacam itu adalah hal yang 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 lanjut, aplikasi dapat mempertimbangkan untuk menyinkronkan penyimpanan melalui server.

Menggunakan origin yang sama

Pendekatan kedua adalah membangun PWA yang berbeda di asal 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/tumpang-tindih

Beberapa PWA di asal yang sama, salah satunya yang cakupannya disarangkan 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 memunculkan banyak masalah dan batasan, yang akarnya berasal dari fakta bahwa browser tidak akan sepenuhnya menganggapnya sebagai "aplikasi" yang berbeda, sehingga pendekatan ini tidak disarankan.

Di bagian berikutnya, kami akan menganalisis tantangan ini secara lebih mendetail, dan tindakan yang dapat dilakukan, jika penggunaan origin yang terpisah tidak memungkinkan.

Tantangan untuk beberapa PWA dengan origin yang sama

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

• Penyimpanan: Cookie, penyimpanan lokal, dan semua bentuk penyimpanan lokal perangkat digunakan bersama antar-aplikasi. Oleh karena itu, jika pengguna memutuskan untuk menghapus total data lokal untuk satu aplikasi, tindakan ini akan menghapus total semua data dari asalnya; tidak ada cara untuk melakukannya untuk satu aplikasi. Perlu diketahui 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 tersebut. Masalah lainnya adalah aplikasi juga harus membagikan kuota penyimpanan yang berarti jika salah satu dari aplikasi tersebut menghabiskan terlalu banyak ruang, aplikasi yang lain akan terkena dampak negatif.
• Izin: Izin terikat dengan 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 seperti hal yang bagus (tidak harus meminta izin beberapa kali), tetapi ingat: jika pengguna memblokir izin untuk satu aplikasi, hal ini akan mencegah aplikasi lain meminta izin tersebut atau menggunakan fitur tersebut.
• Setelan pengguna: Setelan juga ditetapkan per origin. Misalnya, jika dua aplikasi memiliki ukuran font yang berbeda, dan pengguna hanya ingin menyesuaikan zoom in salah satunya untuk mengimbanginya, aplikasi tersebut tidak akan dapat melakukannya tanpa menerapkan setelan tersebut ke aplikasi lainnya juga.

Tantangan-tantangan ini menyulitkan untuk mendorong pendekatan ini. Namun, jika Anda tidak dapat menggunakan origin yang terpisah (misalnya subdomain), seperti yang telah dibahas di bagian Menggunakan origin terpisah, dari dua opsi origin yang sama yang telah kita presentasikan, penggunaan jalur yang tidak tumpang-tindih sangat direkomendasikan, daripada jalur yang tumpang-tindih/bertingkat.

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

Tantangan tambahan untuk jalur yang tumpang-tindih/bertingkat

Masalah tambahan dengan pendekatan jalur yang tumpang-tindih/tumpang-tindih (dengan https://example.com/ adalah aplikasi luar dan https://example.com/app/ adalah aplikasi dalam), adalah bahwa 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 mengunjungi aplikasi dalam (misalnya, di browser web), saat aplikasi luar sudah terinstal di perangkat pengguna, browser tidak akan menampilkan banner promosi penginstalan, dan peristiwa BeforeInstallPrompt tidak akan terpicu. Alasannya karena browser akan memeriksa dan melihat apakah halaman saat ini milik aplikasi yang telah diinstal, dan menyimpulkan bahwa memang demikian. Solusi untuk hal ini adalah menginstal aplikasi bagian dalam secara manual (melalui opsi menu browser "Buat Pintasan"), atau menginstal aplikasi bagian 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 salah diatribusikan ke aplikasi luar (yang merupakan cakupan terdekat dari aplikasi yang terinstal). Fitur ini berfungsi dengan baik jika kedua aplikasi diinstal di perangkat pengguna.
• Pengambilan Link: Aplikasi luar dapat menangkap URL yang merupakan bagian dari aplikasi dalam. Hal ini kemungkinan besar jika aplikasi luar telah diinstal, tetapi aplikasi dalam tidak diinstal. Demikian pula, link dalam aplikasi luar yang tertaut ke aplikasi dalam tidak akan menautkan tangkapan 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 akan tetap menawarkan pilihan kepada pengguna untuk membukanya di aplikasi luar.

Kesimpulan

Dalam artikel ini, kita melihat berbagai cara yang dapat digunakan developer untuk membangun beberapa Progressive Web App yang saling terkait dalam domain yang sama.

Singkatnya, kami sangat merekomendasikan penggunaan asal yang berbeda (misalnya dengan menggunakan subdomain) untuk menghosting PWA independen. Menghostingnya di origin yang sama menghadirkan banyak tantangan, terutama karena browser tidak akan sepenuhnya menganggapnya sebagai aplikasi yang berbeda.

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

Jika tidak mungkin untuk menggunakan origin yang berbeda, gunakan jalur yang tidak tumpang-tindih (misalnya https://example.com/app1/ dan https://example.com/app2/, sebaiknya jangan 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 teknisnya: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner, dan Darwin Huang

Foto oleh Tim Mossholder di Unsplash