如何利用相同的網域名稱建構多個 PWAs，讓使用者知道這些應用程式屬於同一家機構或服務。
在「漸進式網頁應用程式在多來源網站中運作」網誌文章中，Demian 討論了建構在多個來源上的網站，在嘗試建構涵蓋所有來源的單一漸進式網頁應用程式時，所面臨的挑戰。
這類網站架構的例子包括：
- 首頁位於
https://www.example.com。 - 類別頁面會託管在
https://category.example.com中。 https://product.example.com中的產品詳細資料頁面。
如本文所述，同源政策會設下多項限制，禁止跨來源共用服務工作者、快取和權限。因此，我們強烈建議您避免使用這類設定，如果您已以這種方式建構網站，請盡可能遷移至單一來源網站架構。
在本篇文章中，我們將探討相反的情況：不使用跨不同來源的單一 PWA，而是分析有公司想提供多個 PWA，並利用相同的網域名稱，讓使用者知道這些 PWA 屬於同一家機構或服務。
您可能已經注意到，我們使用了不同的但相關的術語，例如網域和來源。繼續之前，請先複習這些概念。
技術術語
- 網域：網域名稱系統 (DNS) 中定義的任何標籤序列。例如：
com和example.com是網域。 - 主機名稱：至少解析為一個 IP 位址的 DNS 項目。舉例來說，
www.example.com是主機名稱，example.com若有 IP 位址，則可做為主機名稱，而com永遠無法解析為 IP 位址，因此不可能是主機名稱。 - 來源：網址配置、主機名稱和 (選用) 通訊埠的組合。例如
https://www.example.com:443就是來源。
如其名稱所示，同源政策會對來源施加限制，因此我們在文章中大多會提到這個詞。不過，我們會不時使用「網域」或「子網域」來描述所用技術，以便建立不同的「來源」。
使用多個相關 PWA 的理由
在某些情況下，您可能會想要建構獨立的應用程式，但仍將這些應用程式視為屬於同一機構或「品牌」。重複使用相同的網域名稱，是建立這類關係的好方法。例如：
- 電子商務網站想要打造獨立體驗，讓賣家管理商品目錄，同時確保賣家瞭解該網站屬於使用者購買產品的主要網站。
- 某體育新聞網站想為大型體育賽事建立特定應用程式，讓使用者透過通知接收喜愛賽事的統計資料，並以漸進式網頁應用程式形式安裝，同時確保使用者認出該應用程式是由新聞公司所建。
- 公司想要建構個別的即時通訊、郵件和日曆應用程式，並希望這些應用程式能以個別應用程式的形式運作，並與公司名稱連結。
使用不同的來源
在這種情況下，建議您讓每個概念上不同的應用程式都位於各自的來源。
如果您想在所有網域中使用相同的網域名稱，可以使用子網域。舉例來說，提供多個網路應用程式或服務的公司可以在 https://mail.example.com 上代管郵件應用程式，在 https://calendar.example.com 上代管日曆應用程式，同時在 https://www.example.com 上提供其業務的主要服務。另一個例子是體育網站想要建立獨立應用程式，專門用於重要體育賽事，例如 https://footballcup.example.com 的足球錦標賽，讓使用者可以安裝並使用獨立於 https://www.example.com 主機代管的體育網站。對於允許客戶在自家品牌下建立獨立應用程式的平台，這個方法也可能很實用。例如，讓商家在 https://merchant1.example.com、https://merchant2.example.com 等地方建立自己的 PWA 應用程式。
使用不同的來源可確保應用程式之間的隔離，也就是說，每個應用程式都能獨立管理不同的瀏覽器功能，包括：
- 可安裝性：每個應用程式都有自己的資訊清單，並提供專屬的安裝體驗。
- 儲存空間：每個應用程式都有自己的快取、本機儲存空間，以及基本上所有形式的裝置本機儲存空間，且不會與其他應用程式共用。
- Service Workers：每個應用程式都有註冊範圍的專屬服務 worker。
- 權限：權限的範圍也由來源決定。如此一來，使用者就能確切瞭解自己授予權限給哪項服務，而通知等功能也會正確歸給各個應用程式。
在多個獨立 PWA 的用途中，建立這種程度的隔離效果最理想，因此我們強烈建議採用這種做法。
如果子網域中的應用程式想要彼此共用本機資料，仍可透過 Cookie 執行這項操作，或是在更進階的情況下，考慮透過伺服器同步處理儲存空間。
使用相同來源
第二種方法是在相同來源上建構不同的 PWA。包括下列情況：
不重疊路徑
多個 PWAs 或概念性的「網頁應用程式」，這些應用程式會在相同來源中代管，且路徑不會重疊。例如：
https://example.com/app1/https://example.com/app2/
重疊/巢狀路徑
位於相同來源的多個 PWAs，其中一個範圍嵌套在另一個範圍中：
https://example.com/(「外部應用程式」)https://example.com/app/(「內部應用程式」)
服務工作者 API 和資訊清單格式可讓您使用路徑層級範圍執行上述任一操作。不過，無論是哪種情況，使用相同的來源都會產生許多問題和限制，而這主要是因為瀏覽器不會將這些來源視為獨立的「應用程式」，因此不建議採用這種做法。
在下一節中，我們將更詳細分析這些挑戰，並說明如果無法使用不同的來源，該如何因應。
多個相同來源 PWA 的挑戰
以下是兩種同源方法的共同實用問題：
- 儲存空間：Cookie、本機儲存空間和所有形式的裝置本機儲存空間都會在應用程式之間共用。因此，如果使用者決定清除某個應用程式的本機資料，系統會清除來源的所有資料；無法針對單一應用程式執行此操作。請注意，Chrome 和其他一些瀏覽器會在卸載某個應用程式時主動提示使用者清除本機資料，這也會影響來源中其他應用程式的資料。另一個問題是，應用程式也必須共用儲存空間配額，也就是說，如果其中一個應用程式占用太多空間，另一個應用程式就會受到負面影響。
- 權限：瀏覽器權限與來源綁定。也就是說，如果使用者授予某個應用程式權限，該權限會同時套用至該來源的所有應用程式。這聽起來似乎是好事 (不必多次要求權限)，但請注意：如果使用者封鎖某個應用程式的權限，其他應用程式就無法要求該權限或使用該功能。請注意，即使瀏覽器權限只需針對每個來源授予一次，但系統層級權限則必須針對每個應用程式授予一次，無論是否有其他應用程式指向相同來源。
- 使用者設定：設定也必須依來源設定。舉例來說，如果兩個應用程式的字型大小不同，而使用者只想調整其中一個應用程式的縮放比例來彌補差異，就必須將設定套用至其他應用程式。
這些挑戰使得我們難以鼓勵採用這種做法。不過，如果您無法使用個別來源 (例如子網域)，請參閱「使用個別來源」一節，從我們提供的兩個相同來源選項中，強烈建議您使用不重疊的路徑，而非重疊/巢狀路徑。
如前所述，本節所討論的挑戰適用於兩種相同來源方法。在下一節中，我們將進一步說明為何不建議使用重疊/巢狀路徑。
重疊/巢狀路徑的其他挑戰
重疊/巢狀路徑方法 (https://example.com/ 為外部應用程式，https://example.com/app/ 為內部應用程式) 的另一個問題是，內部應用程式中的所有網址實際上都會視為外部應用程式和內部應用程式的一部分。
實際上，這會導致以下問題：
- 安裝宣傳：如果使用者造訪內部應用程式 (例如在網路瀏覽器中)，且外部應用程式已安裝在使用者的裝置上，瀏覽器就不會顯示安裝宣傳橫幅，也不會觸發 BeforeInstallPrompt 事件。原因是瀏覽器會檢查目前的網頁是否屬於已安裝的應用程式，並得出結論。解決方法是手動安裝內部應用程式 (透過「Create Shortcut」瀏覽器選單選項)，或是先安裝內部應用程式，再安裝外部應用程式。
- 通知和標記 API：如果已安裝外部應用程式，但內部應用程式未安裝，則來自內部應用程式的通知和徽章會誤歸為外部應用程式 (這是已安裝應用程式最近的包函範圍)。如果使用者裝置上安裝了這兩個應用程式，這項功能就能正常運作。
- 連結擷取：外部應用程式可能會擷取屬於內部應用程式的網址。如果已安裝外部應用程式，但未安裝內部應用程式，就特別容易發生這種情況。同樣地，外部應用程式中連結至內部應用程式的連結不會擷取至內部應用程式，因為這些連結會被視為位於外部應用程式的範圍內。此外，在 ChromeOS 和 Android 上，如果這些應用程式以「可信任的網頁活動」的形式新增至 Play 商店，外部應用程式就會擷取所有連結。即使已安裝內部應用程式，作業系統仍會讓使用者選擇是否要在外部應用程式中開啟。
結論
在本文中，我們將探討開發人員如何在同一個網域中，以不同方式建構多個彼此相關的漸進式網頁應用程式。
總而言之，我們強烈建議您使用不同的來源 (例如使用子網域) 代管獨立的 PWA。在相同來源中託管這些應用程式會帶來許多挑戰，主要是因為瀏覽器不會將這些應用程式視為獨立的應用程式。
- 使用不同的來源：建議
- 相同來源、不重疊路徑：不建議
- 相同來源、重疊/巢狀路徑：強烈不建議
如果無法使用不同的來源，強烈建議您使用不重疊的路徑 (例如 https://example.com/app1/ 和 https://example.com/app2/)，而非重疊或巢狀路徑，例如 https://example.com/ (外部應用程式) 和 https://example.com/app/ (內部應用程式)。
其他資源
在此感謝他們提供的技術審查和建議：Joe Medley、Dominick Ng、Alan Cutter、Daniel Murphy、Penny McLachlan、Thomas Steiner 和 Darwin Huang
相片來源：Unsplash 上的 Tim Mossholder