PWA: управление service-worker’ом

Прочитал я хорошую статью «Обновление вашего PWA в продакшене» и задался вопросом - а как часто при обновлении PWA нужно обновлять непосредственно сам service worker? Ведь что такое service worker по сути? «Прокладка» (прокси) между приложением, работающим в браузере, и внешними серверами, с которых это приложение тянет нужные ему ресурсы. По большому счёту, функционал service worker’а сводится к некоторому набору стратегий и пониманию того, к какому ресурсу какую стратегию применять и когда (я сейчас не рассматриваю push notifications и background sync, но изложенное в какой-то степени применимо и к ним).

То есть, код service worker’а более стабилен по сравнению с кодом приложения и во многих случаях для его «обновления» достаточно программно обнулить кэш-хранилище браузера и обновить «понимание того, к какому ресурсу какую стратегию применять« - обновить конфигурацию service worker’а. А для этого нужно приложению нужно иметь возможность каким-то образом управлять состоянием service worker’а и передавать ему данные, что осложняется тем, что приложение и service worker работают в различных потоках.

Под катом пример того, каким образом можно настроить управление service worker’ом из основного приложения при помощи Channel Messaging API.

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

Принцип взаимодействия

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

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

• Приложение отправляет сообщение сервис-службе в соседний поток.

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

• После выполнения операции сервис-служба отправляет приложению обратное сообщение.

• Приложение получает сообщение от сервис-службы и находит в реестре контекст, соответствующий полученному сообщению.

• Приложение передаёт в контекст данные, полученные от сервис-службы, и выполняет (при необходимости) callback-функцию.

Базовый код

Приложение

Отправка сообщения активной сервис-службе:

const sw = await navigator.serviceWorker.ready; if (sw.active) sw.active.postMessage(msg);

Подписка на сообщения от сервис-службы:

navigator.serviceWorker.addEventListener('message', onMessage);

Сервис-служба

Отправка в приложение обратного сообщения осуществляется в обработчике события:

function onMessage(event) {     //...     event.source.postMessage(msg); }

Подписка на сообщения от приложения:

self.addEventListener('message', onMessage);

Демо

Для демонстрации управления сервис-службой я сделал приложение:

• код

• демо

Для корректной работы приложения должно быть отключено собственное кэширование в браузере (в Chrome — панель инструментов, вкладка Network, Disable cache), в противном случае повторные запросы на картинки даже не доходят до сервис-службы.

Приложение по очереди загружает два изображения: первичное и вторичное. Первичное изображение (./img/primary.svg) всегда содержит картинку лошади, а вторичное (./img/secondary.svg) - картинку кошки или собаки, в зависимости от состояния сервис-службы:

Замещение изображения происходит по кнопке «Заместить»:

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

Состояние сервис-службы сохраняется в переменной _useCat, изменения отслеживаются через отладчик:

Структура сообщения

DTO-объект для передачи информации от приложения в сервис-службу и обратно:

class Dto {     id;     payload;     type; }

В демо-приложении возможны два типа сообщений: get_state и set_state.

Контроллер

Контроллер обеспечивает синхронизацию отправки сообщений сервис-службе и сопоставление отправленным сообщениям обратных сообщений от сервис-службы. Приложение может использовать команды контроллера (getState(), setState(replaceWithCat)) для управления сервис-службой:

class Controller {     constructor(spec) {         const _queue = {};         const generateMsgId = () => `${(new Date()).getTime()}`;         this.getState = function () {};         this.setState = function (replaceWithCat = true) {};         function onMessage(event) {}         self.navigator.serviceWorker             .addEventListener('message', onMessage);     } }

Вот основа кода регистрации сообщения в реестре и отправки сообщения сервис-службе:

this.setState = function (replaceWithCat = true) {     const id = generateMsgId();     return new Promise(async (resolve) => {         _queue[id] = resolve;         const msg = new Dto();         msg.id = id;         //...         const sw = await navigator.serviceWorker.ready;         sw.active.postMessage(msg);     }); };

А это код получения обратного сообщения от сервис-службы и разрешения зарегистрированного ранее промиса:

function onMessage(event) {     const id = event.data.id;     const payload = event.data.payload;     if (typeof _queue[id] === 'function') _queue[id](payload); }

Сервис-служба

В сервис-службе весь функционал умещается в одном обработчике:

function onMessage(event) {     const msg = event.data;     const res = {};     res.id = msg.id;     if (msg.type === 'get_state') {...}      else if (msg.type === 'set_state') {...}     event.source.postMessage(res); }

Обработчик принимает сообщение, выполняет запрошенную операцию и возвращает результат вместе с id операции обратным сообщением.

Приложение

Приложение общается через контроллер, поэтому тут совсем всё тривиально:

const isCat = await swControl.getState();

Резюме

• Если функционал сервис-службы отделить от её конфигурации (список ресурсов и стратегии кэширования), то обновления самой сервис-службы нужно будет делать реже.

• Функционал по зачистке кэша, используемого сервис-службой, лучше ставить до вывода приложения в прод, чтобы избежать ситуации «установил ServiceWorker — пора менять домен«.

• В силу асинхронной природы сервис-службы для управления её состоянием из приложения приходится использовать асинхронный подход (при этом данные «туда» и «обратно» передаются по-значению, а не по ссылке).

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

• Использование отладчика в браузере очень сильно способствует пониманию процессов, происходящих внутри программы.