Перейти к содержанию

Сделайте PWA надежным

Добро пожаловать на День 4 из #30DaysOfPWA! Хотите узнать больше об этом проекте? Ознакомьтесь с нашим постом Вступление, чтобы получить более подробную информацию о дорожной карте контента и участниках. А теперь давайте погрузимся в работу!

День 4: Поговорим о сервис-воркерах!

Что вы узнаете сегодня

  • Что такое сервис-воркер?
  • Почему HTTPS необходим для PWA?
  • Понимание регистрации и событий жизненного цикла
  • Как сервис-воркеры используются в PWA?

Давайте подведем итоги

Что мы узнали к настоящему времени:

  • PWA по умолчанию являются веб-приложениями. Они могут предоставлять полезный опыт на всех устройствах и платформах, используя единую кодовую базу.
  • PWA используют прогрессивное улучшение для масштабирования своего опыта в соответствии с более богатыми возможностями платформы. В этом контексте они могут быть неотличимы от приложений, устанавливаемых на конкретную платформу.
  • Для реализации такого поведения PWA используют открытые веб-технологии. Основными строительными блоками являются HTTPS, Web App Manifest и сервис-воркеры. Новые веб-возможности открывают еще более богатый опыт на поддерживающих платформах.
  • Манифесты веб-приложений подобны резюме приложений — они содержат информацию об идентификации, брендинге и навыках, необходимую для установки приложения (на устройство) или публикации (в магазинах приложений).

Что мы рассмотрим сегодня: Мы изучим оставшиеся строительные блоки (HTTPS, сервис-воркеры), уделив особое внимание использованию сервис-воркеров.

PWA — это как стартапы!

Чтобы подвести итог, давайте воспользуемся другой аналогией. Ранее мы говорили о том, что манифесты Web App Manifests похожи на резюме приложений. Теперь подумайте о PWA как о стартапе: каждая технология — это член команды-основателя со своей специализированной задачей, которая помогает постепенно улучшать опыт.

  • Приложение страница является генеральным директором — оно управляет основным опытом и реагирует на потребности пользователей и их взаимодействие.
  • Манифест Web App Manifest является резюме — он описывает идентичность, бренд и возможности приложения для устройств и магазинов приложений для возможности установки.
  • HTTPS является главным офицером безопасности (CSO) — он шифрует сквозные коммуникации между конечными точками приложения и сервера для обеспечения безопасности.
  • Сервис-воркер является главным операционным директором (COO) — он разблокирует CEO от выполнения трудоемких или синхронных задач и предпринимает проактивные действия для обеспечения надежной работы даже в автономном режиме.

Изображение описывает взаимоотношения PWA-стартапа

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

Сделайте PWA безопасными

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

Поддержка HTTPS обязательна для использования сервис-воркеров. К счастью, как мы уже рассказывали в нашем предыдущем посте, реализовать поддержку HTTPS очень просто. Используйте современных провайдеров облачного хостинга (которые включают эту функцию по умолчанию) или воспользуйтесь бесплатными сертификатами (например, Let's Encrypt) для защиты собственных серверов.

Сделайте PWA надежными и повторно используемыми

Сервис-воркеры — это особый тип Web Worker. Web Workers работают в отдельном потоке, что позволяет им выполнять длительные или асинхронные задачи в фоновом режиме, минимизируя влияние на производительность страницы ("разблокируя" CEO).

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

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

Как работают сервис-воркеры?

С точки зрения разработки нам необходимо знать два понятия:

  • Сервис-воркер Регистрация — когда CEO "нанимает" COO.
  • Сервис-воркер Lifecycle — когда COO "обрабатывает" операционные события.

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

Давайте еще раз посмотрим на DevTools Tips PWA в браузере. Посмотрим на Service Workers на вкладке Application. Видно, что сервис-воркер реализован в файле "sw.js" в корневом каталоге, что неявно задает его область действия всему приложению.

Осмотр PWA в DevTools

Если просмотреть исходный текст приложения (на вкладке Elements), то можно найти фрагмент кода для регистрации сервис-воркера:

1
2
3
4
5
6
if ('serviceWorker' in navigator) {
    // Register the service worker
    navigator.serviceWorker.register('/sw.js', {
        scope: '/',
    });
}

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

Сервис-воркер: события жизненного цикла

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

  1. Регистрация: Браузер регистрирует сервис-воркер, запуская его жизненный цикл.

  2. Установка: Браузер запускает install как первое событие для сервиса-воркера. Это можно использовать для предварительного кэширования ресурсов (например, заполнить кэш долгоживущими ресурсами, такими как логотипы или автономные страницы).

    1
2
3
    self.addEventListener('install', function (event) {
    console.log('WORKER: install event in progress.');
});

  3. Активация: Браузер посылает событие activate, указывающее на то, что сервис-воркер был установлен. Теперь этот сервис-воркер может выполнять действия по очистке (например, удалять старые кэши из предыдущей версии) и готовиться к обработке функциональных событий. Если в работе находится старый сервис-воркер, можно использовать clients.claim() для немедленной замены старого сервис-воркера на новый.

    1
2
3
4
5
6
7
8
9
    self.addEventListener('activate', function (event) {
    console.log(
        'WORKER: activation event in progress.',
    );
    clients.claim();
    console.log(
        'WORKER: all clients are now controlled by me! Mwahahaha!',
    );
});

Сервис-воркер: функциональные события

Функциональные события — это события, требующие от сервис-воркеров асинхронной или фоновой обработки для поддержки надежного и восстанавливаемого поведения. Пока рассмотрим только два: "fetch" и "push".

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

    1
2
3
    self.addEventListener('fetch', function (event) {
    console.log('WORKER: Fetching', event.request);
});

  2. Событие push срабатывает, когда браузер получает push-сообщение от сервера для отображения в виде тостового уведомления для пользователей. Это происходит только в том случае, если PWA был ранее подписан на уведомления сервера и пользователь дал PWA разрешение на их получение. Push-события очень важны для повторного привлечения пользователей, когда приложение неактивно.

    1
2
3
4
5
6
    self.addEventListener('push', function (event) {
    console.log(
        'WORKER: Received notification',
        event.data,
    );
});

В следующей статье мы подробно рассмотрим поддержку сервис-воркерами автономной работы, а также то, как сервис-воркеры взаимодействуют с API Fetch и Cache Storage для обеспечения непрерывности работы в независимости от сети. А пока настало время для практического упражнения!

Упражнение: Изучение сервис-воркеров

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

  • Перейдите на вкладку Elements и изучите источник приложения.
    • Где зарегистрирован сервис-воркер?
    • Какова область регистрации?
  • Перейдите на вкладку Applications и изучите файл сервис-воркера
    • Какие события он обрабатывает?
    • Можно ли понять стратегию кэширования (для выборки)?
    • Осуществляется ли повторное привлечение пользователя (с помощью push)?
  • Перейдите к разделу Хранилище кэша.
    • Какие файлы или ресурсы там хранятся?
    • Как они соотносятся с действиями, выполняемыми для события install?
  • Перейдите в раздел Сервисы-воркеры — нажмите "Offline".
    • Что происходит при перезагрузке страницы?
    • Что происходит при переходе на другой сайт (в автономном режиме)?

Источник — 1.4 Make PWA Reliable

Комментарии