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

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

Demián Renzulli

Опубликовано: 19 августа 2019 г.

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

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

Хорошее и плохое использование множественного происхождения

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

Хороший

Давайте сначала рассмотрим полезные причины:

Локализация/Язык: использование домена верхнего уровня с кодом страны для разделения сайтов, обслуживаемых в разных странах (например, https://www.google.com.ar ), или использование поддоменов для разделения сайтов, ориентированных на разные местоположения (например, https://newyork.craigslist.org ), или для предложения контента на определенном языке (например, https://en.wikipedia.org ).
Независимые веб-приложения: использование различных поддоменов для предоставления контента, назначение которого существенно отличается от назначения основного сайта. Например, на новостном сайте веб-приложение с кроссвордами может быть намеренно размещено на https://crosswords.example.com и установлено и использоваться как независимое PWA, без необходимости совместного использования каких-либо ресурсов или функций с основным сайтом.

Плохой

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

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

Например, крайне не рекомендуется использовать следующие шаблоны:

Разделы сайта: разделение различных разделов сайта на поддомены. На новостных сайтах домашняя страница часто находится по адресу: https://www.example.com , спортивный раздел — по адресу https://sports.example.com , политический — по адресу https://politics.example.com и т. д. В случае сайта электронной коммерции для категорий товаров можно использовать адрес вроде https://category.example.com , для страниц товаров https://product.example.com и т. д.
Поток пользователей: Другой не рекомендуемый подход — разделение небольших частей сайта, например, страниц входа или оформления покупки, на поддомены. Например, используйте https://login.example.com и https://checkout.example.com .

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

Проблемы и обходные пути для PWA разного происхождения

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

Работники сферы услуг

Источник URL-адреса скрипта сервис-воркера должен совпадать с источником страницы, вызывающей register() . Это означает, например, что страница по адресу https://www.example.com не может вызвать register() с URL-адресом сервис-воркера по адресу https://section.example.com .

Ещё одно замечание заключается в том, что сервис-воркер может контролировать только страницы, размещённые в том же источнике и пути, к которому он принадлежит. Это означает, что если сервис-воркер размещён по адресу https://www.example.com он может контролировать только URL-адреса из этого источника (в соответствии с путём, указанным в параметре scope ), но не будет контролировать страницы в других поддоменах, например, в https://section.example.com .

В этом случае единственным решением будет использование нескольких сервис-воркеров (по одному на источник).

Кэширование

Объекты Cache, indexedDB и localStorage также ограничены одним источником. Это означает, что доступ к кэшам, принадлежащим https://www.example.com , например, с https://www.section.example.com , невозможен.

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

Используйте кэширование браузера: всегда рекомендуется использовать традиционные методы кэширования браузера . Этот метод даёт дополнительное преимущество — возможность повторного использования кэшированных ресурсов между источниками, чего невозможно добиться с помощью кэша сервис-воркера. Рекомендации по использованию HTTP-кэша с сервис-воркерами можно найти в этой публикации .
Обеспечьте лёгкость установки сервис-воркеров: если вы используете несколько сервис-воркеров, не заставляйте пользователей платить высокую стоимость установки каждый раз при переходе к новому источнику. Другими словами: предварительно кэшируйте только те ресурсы, которые действительно необходимы.

Разрешения

Разрешения также действуют только на источники. Это означает, что если пользователь предоставил разрешение источнику https://section.example.com , оно не будет распространяться на другие источники, например https://www.example.com .

Поскольку невозможно делиться разрешениями между источниками, единственное решение — запрашивать разрешение на каждом поддомене, где требуется определённая функция (например, местоположение). Для таких задач, как push-уведомления, можно использовать cookie-файл, чтобы отслеживать, было ли разрешение принято пользователем в другом поддомене, и не запрашивать его снова.

Установка

Для установки PWA каждый источник должен иметь собственный манифест с start_url , заданным относительно него . Это означает, что пользователь, получающий приглашение на установку с данного источника (например, https://section.example.com ), не сможет установить PWA с start_url с другого источника (например, https://www.example.com ). Другими словами, пользователи, получающие приглашение на установку в поддомене, смогут устанавливать PWA только для подстраниц, а не для основного URL-адреса приложения.

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

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

Прослушивание события beforeinstallprompt .
Предотвратить появление подсказки , вызвав event.preventDefault() .

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

Автономный режим

При навигации в автономном окне браузер будет вести себя по-разному, когда пользователь выходит за пределы области действия, заданной манифестом PWA. Это поведение зависит от версии и поставщика браузера. Например, в последних версиях Chrome открывается пользовательская вкладка Chrome , когда пользователь выходит за пределы области действия в автономном режиме.

В большинстве случаев решения этой проблемы нет, но можно применить обходной путь для небольших частей интерфейса, размещенных в поддоменах (например, рабочие процессы входа в систему):

Новый URL-адрес https://login.example.com может открываться внутри полноэкранного iframe.
После завершения задачи внутри iframe (например, процесс входа в систему) можно использовать postMessage() для передачи любой полученной информации из iframe обратно на родительскую страницу.
На последнем этапе, как только сообщение получено главной страницей, можно отменить регистрацию слушателей и окончательно удалить iframe из DOM.

Заключение

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

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

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

Выражаем огромную благодарность за технические обзоры и предложения: Пенни Маклахлан, Полу Ковеллу, Доминику Нг, Альберто Медине, Питу ЛеПейджу, Джо Медлею, Чейни Цаю, Мартину Ширле и Андре Бандарре.