Создание нескольких прогрессивных веб-приложений в одном домене

Как создать несколько PWA, используя одно и то же доменное имя, чтобы пользователь знал, что они принадлежат одной организации или службе.

Chase Phillips

Demián Renzulli

Matt Giuca

В блоге «Прогрессивные веб-приложения на сайтах с несколькими источниками » Демиан обсудил проблемы, с которыми сталкиваются сайты, созданные на основе нескольких источников, при попытке создать единое прогрессивное веб-приложение, охватывающее их все.

Примером архитектуры сайта такого типа является сайт электронной коммерции, где:

• Домашняя страница находится по адресу https://www.example.com .
• Страницы категорий размещаются по адресу https://category.example.com .
• Страницы с подробными сведениями о продукте по адресу https://product.example.com .

Как обсуждалось в статье, политика одного и того же источника накладывает несколько ограничений, предотвращающих совместное использование сервисных работников, кэшей и разрешений между источниками. По этой причине мы настоятельно рекомендуем избегать такого типа конфигурации, а тем, у кого уже есть сайты, созданные таким образом, по возможности рассмотреть возможность перехода к единой архитектуре исходного сайта.

Избегайте использования разных источников для разделов одного и того же сайта при попытке создать единое прогрессивное веб-приложение.

В этом посте мы рассмотрим противоположный случай: вместо одного PWA разных источников мы проанализируем случай компаний, которые хотят предоставить несколько PWA , используя преимущества одного и того же доменного имени , и сообщим пользователю, что эти PWA принадлежат одной и той же организации или службе.

Как вы могли заметить, мы используем разные, но взаимосвязанные термины, такие как домены и источники. Прежде чем двигаться дальше, давайте рассмотрим эти концепции.

Технические условия

• Домен: любая последовательность меток, определенная в системе доменных имен (DNS). Например: com и example.com — это домены.
• Имя хоста: запись DNS, которая разрешается как минимум в один IP-адрес. Например: www.example.com будет именем хоста, example.com может быть именем хоста, если у него есть IP-адрес, а com никогда не будет преобразован в IP-адрес и поэтому никогда не сможет быть именем хоста.
• Происхождение: комбинация схемы, имени хоста и (необязательно) порта. Например, https://www.example.com:443 — это источник.

Как следует из названия, политика одного и того же происхождения накладывает ограничения на происхождение, поэтому на протяжении всей статьи мы будем чаще всего ссылаться на этот термин. Тем не менее, мы будем время от времени использовать «домены» или «поддомены» для описания используемой техники и создания различных «источников».

Аргументы в пользу нескольких связанных PWA

В некоторых случаях вам может потребоваться создать независимые приложения, но при этом идентифицировать их как принадлежащие одной и той же организации или «бренду». Повторное использование одного и того же доменного имени — хороший способ установить такие отношения. Например:

• Сайт электронной коммерции хочет создать автономный интерфейс, позволяющий продавцам управлять своими запасами, при этом гарантируя, что они понимают, что они принадлежат основному веб-сайту, на котором пользователи покупают товары.
• Сайт спортивных новостей хочет создать специальное приложение для крупного спортивного события, чтобы пользователи могли получать статистику о своих любимых соревнованиях с помощью уведомлений, и установить его как прогрессивное веб-приложение, при этом убедившись, что пользователи распознают его как приложение, созданное новостная компания.
• Компания хочет создать отдельные приложения для чата, почты и календаря и хочет, чтобы они работали как отдельные приложения, привязанные к названию компании.

Компания, владеющая сайтом example.com, хочет предоставить три независимых приложения или PWA, используя одно и то же доменное имя для установления связи между ними.

Использование отдельных источников

Рекомендуемый подход в подобных случаях заключается в том, что каждое концептуально отдельное приложение живет в своем собственном источнике.

Если вы хотите использовать одно и то же доменное имя во всех из них, вы можете сделать это, используя поддомены. Например, компания, предоставляющая несколько интернет-приложений или служб, может разместить почтовое приложение по адресу https://mail.example.com и приложение календаря по адресу https://calendar.example.com , предлагая при этом основную услугу своего бизнеса. на https://www.example.com . Другим примером является спортивный сайт, который хочет создать независимое приложение, полностью посвященное важному спортивному событию, например чемпионату по футболу на https://footballcup.example.com , которое пользователи смогут устанавливать и использовать независимо от основного спортивного сайта, размещенного на хостинге. на https://www.example.com . Этот подход также может быть полезен для платформ, которые позволяют клиентам создавать собственные независимые приложения под брендом компании. Например, приложение, которое позволяет продавцам создавать свои собственные PWA по адресу https://merchant1.example.com , https://merchant2.example.com и т. д.

Использование разных источников обеспечивает изоляцию между приложениями, а это означает, что каждое из них может независимо управлять различными функциями браузера, в том числе:

• Возможность установки: каждое приложение имеет свой собственный манифест и предоставляет свои возможности установки.
• Хранение: каждое приложение имеет свои собственные кэши, локальное хранилище и практически все формы локального хранилища устройства, без совместного использования их с другими.
• Service Workers: каждое приложение имеет собственного Service Worker для зарегистрированных областей.
• Разрешения. Разрешения также ограничиваются источниками. Благодаря этому пользователи будут точно знать, для какой службы они дают разрешения, а такие функции, как уведомления, будут правильно привязаны к каждому приложению.

Создание такой степени изоляции наиболее желательно в случае использования нескольких независимых PWA, поэтому мы настоятельно рекомендуем такой подход .

Если приложения в поддоменах захотят обмениваться локальными данными друг с другом, они все равно смогут делать это через файлы cookie, а в более сложных сценариях они могут рассмотреть возможность синхронизации хранилища через сервер.

Хорошей практикой является создание разных PWA разных источников с использованием поддоменов.

Используя то же происхождение

Второй подход заключается в создании разных PWA на основе одного и того же источника. Сюда входят следующие сценарии:

Непересекающиеся пути

Несколько PWA или концептуальных «веб-приложений», размещенных в одном источнике и с непересекающимися путями. Например:

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

Перекрывающиеся/вложенные пути

Несколько PWA в одном источнике, область действия одного из которых вложена в другой:

• https://example.com/ («внешнее приложение»)
• https://example.com/app/ («внутреннее приложение»)

API сервисного работника и формат манифеста позволяют выполнить любое из вышеперечисленных действий, используя область действия на уровне пути. Однако в обоих случаях использование одного и того же источника создает множество проблем и ограничений, корень которых проистекает из того факта, что браузер не полностью считает их отдельными «приложениями», поэтому такой подход не рекомендуется .

Использование путей (перекрывающихся или нет) для предоставления двух независимых PWA («app1», «app2») с одним и тем же источником не рекомендуется.

В следующем разделе мы более подробно анализируем эти проблемы и что можно сделать, если использование отдельных источников невозможно.

Проблемы с несколькими PWA одного происхождения

Вот некоторые практические проблемы, общие для обоих подходов одного и того же происхождения:

• Хранение: файлы cookie, локальное хранилище и все формы локального хранилища устройства используются приложениями совместно. По этой причине, если пользователь решит стереть локальные данные для одного приложения, он удалит все данные из источника; нет способа сделать это для одного приложения. Обратите внимание, что Chrome и некоторые другие браузеры активно предлагают пользователям стереть локальные данные при удалении одного из приложений, и это также повлияет на данные других приложений в источнике. Другая проблема заключается в том, что приложениям также придется делиться своей квотой хранилища, а это означает, что если одно из них займет слишком много места, это отрицательно повлияет на другое.
• Разрешения: разрешения браузера привязаны к источнику. Это означает, что если пользователь предоставляет разрешение одному приложению, оно будет применяться ко всем приложениям в этом источнике одновременно. Это может звучать хорошо (не нужно запрашивать разрешение несколько раз), но помните: если пользователь заблокирует разрешение для одного приложения, это не позволит другим запрашивать это разрешение или использовать эту функцию. Обратите внимание: даже если разрешения браузера необходимо предоставить только один раз для каждого источника, разрешения на уровне системы, с другой стороны, должны быть предоставлены один раз для каждого приложения, независимо от того, указывают ли несколько приложений на один и тот же источник.
• Пользовательские настройки: настройки также задаются для каждого источника. Например, если два приложения имеют разные размеры шрифта, и пользователь хочет настроить масштаб только в одном из них, чтобы компенсировать это, он не сможет сделать это, не применив настройку и к другим приложениям.

Эти проблемы затрудняют поощрение такого подхода. Тем не менее, если вы не можете использовать отдельный источник (например, субдомен), как обсуждалось в разделе «Использование отдельных источников» , из двух представленных нами вариантов с одним и тем же источником настоятельно рекомендуется использовать непересекающиеся пути вместо перекрывающихся/вложенных путей. .

Как уже упоминалось, проблемы, обсуждаемые в этом разделе, являются общими для обоих подходов одного происхождения. В следующем разделе мы углубимся в детали того, почему использование перекрывающихся/вложенных путей является наименее рекомендуемой стратегией.

Дополнительные проблемы с перекрывающимися/вложенными путями

Дополнительная проблема с подходом с перекрывающимися/вложенными путями (где https://example.com/ — внешнее приложение, а https://example.com/app/ — внутреннее приложение) заключается в том, что все URL-адреса во внутреннем приложении фактически будут считаться частью как внешнего приложения, так и внутреннего приложения.

На практике это приводит к следующим проблемам:

• Продвижение установки: если пользователь посещает внутреннее приложение (например, в веб-браузере), когда внешнее приложение уже установлено на устройстве пользователя, браузер не будет отображать рекламные баннеры установки, а событие BeforeInstallPrompt не будет отображаться. быть спровоцировано. Причина в том, что браузер проверит, принадлежит ли текущая страница уже установленному приложению, и придет к выводу, что так оно и есть. Обходной путь — установить внутреннее приложение вручную (с помощью пункта меню браузера «Создать ярлык») или сначала установить внутреннее приложение, а затем внешнее.
• API уведомлений и значков . Если внешнее приложение установлено, а внутреннее — нет, уведомления и значки, поступающие из внутреннего приложения, будут ошибочно отнесены к внешнему приложению (которое является ближайшей областью действия установленного приложения). Эта функция работает правильно, если на устройстве пользователя установлены оба приложения.
• Захват ссылок : внешнее приложение может захватывать URL-адреса, принадлежащие внутреннему приложению. Это особенно вероятно, если внешнее приложение установлено, а внутреннее — нет. Аналогично, ссылки внутри внешнего приложения, которые ссылаются на внутреннее приложение, не будут связывать захват с внутренним приложением, поскольку они считаются входящими в область действия внешнего приложения. Кроме того, в ChromeOS и Android, если эти приложения добавлены в Play Store (как «Надежные веб-действия »), внешнее приложение будет захватывать все ссылки. Даже если внутреннее приложение установлено, ОС все равно предложит пользователю открыть их во внешнем приложении.

Заключение

В этой статье мы рассмотрели различные способы, с помощью которых разработчики могут создавать несколько связанных друг с другом прогрессивных веб-приложений в одном домене .

Таким образом, мы настоятельно рекомендуем использовать другой источник (например, с помощью поддоменов) для размещения независимых PWA. Размещение их в одном источнике представляет множество проблем, главным образом потому, что браузер не полностью воспринимает их как отдельные приложения.

• Отдельное происхождение: рекомендуется.
• Один и тот же источник, непересекающиеся пути: не рекомендуется.
• Одно и то же происхождение, перекрывающиеся/вложенные пути: настоятельно не рекомендуется.

Если невозможно использовать разные источники, используйте непересекающиеся пути (например https://example.com/app1/ и https://example.com/app2/ настоятельно рекомендуется использовать перекрывающиеся или вложенные пути, например https://example.com/ (для внешнего приложения) и https://example.com/app/ (для внутреннего приложения).

Дополнительные ресурсы

• Прогрессивные веб-приложения на сайтах с несколькими источниками

Большое спасибо за технические обзоры и предложения: Джо Медли, Доминику Нг, Алану Каттеру, Дэниелу Мерфи, Пенни Маклахлану, Томасу Штайнеру и Дарвину Хуангу.

Фото Тима Моссхолдера на Unsplash