Влияние service worker'ов на web-приложения

    Web-приложения всё больше "затачиваются" под мобильные устройства, а service worker'ы являются фундаментом прогрессивных web-приложений (PWA). При первом ознакомлении с данной технологией может сложиться впечатление, что основной задачей service worker'ов является кэширование контента. И это так. Задача service worker'ов — обеспечение функционирования web-приложения в условиях нестабильного или вообще отсутствующего подключения к Сети, что достигается при помощи кэширования данных.


    Под катом пара мыслей о том, к каким последствиям для web-приложений привело появление возможности кэшировать данные посредством service worker'ов.


    Архитектура PWA


    Вот классическая трёхуровневая архитектура web-приложения:



    Добавление на клиенте service worker'а и инструментов для сохранения данных (Cache API и IndexedDB) превращают трёхуровневую архитектуру в пятиуровневую:



    По сути, при отсутствии соединения с Сетью прогрессивное web-приложение должно работать на клиенте в классическом трёхуровневом режиме:



    а когда появляется соединение с Сетью — переходить на пятиуровневую:


    1. Presentation (Main Thread): пользовательский интерфейс;
    2. Client Logic (Service Worker): бизнес-логика обработки данных конкретного пользователя с учётом работы в offline & online режимах;
    3. Client Data (Cache API & IndexedDB): хранилища данных конкретного пользователя;
    4. Server Logic (Server): бизнес-логика обработки данных всех пользователей приложения;
    5. Server Data (DB): хранилище данных всех пользователей приложения;

    Offline first


    В web-разработке популярной является стратегия mobile first. Для PWA есть похожая стратегия — offline first. Её суть в том, что приложение изначально разрабатывается для условий автономной работы (классическая трёхуровневая архитектура на клиенте), а затем расширяется до пятиуровневой.


    Таким образом, самой первой задачей service worker'а является кэширование данных в объёме, достаточном для автономного функционирования приложения. Следующей — организация очереди запросов для обмена данными конкретного пользователя с сервером. Затем — мониторинг состояния соединения с сервером (online/offline) и обработка очереди запросов.


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


    Типы трафика


    Трафик между браузером клиента и сервером можно разделить на две части:



    • статика: контент, общий для всех клиентов (HTML/CSS/JS/images/...);
    • данные (API): контент (как правило, JSON), предназначенный как для всех пользователей (каталог продуктов), так и для конкретного пользователя (корзина покупок);

    Для первого типа трафика (статика) браузер предоставляет Cache API — простое хранилище "запрос" — "ответ"


    Для хранения данных (API) — IndexedDB (NoSQL хранилище структурированных данных в формате JSON).


    Типы хранилищ


    Cache


    В панели инструментов Chrome'а хранилище находится в Application / Cache / Cache Storage / <имя кэша>, содержимое выглядит примерно так:



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


    IndexedDB


    В панели инструментов Chrome'а хранилища объектов находятся в Application / Storage / IndexedDB / <имя базы> / <имя хранилища объектов>, содержимое выглядит примерно так:



    База предоставляет транзакционный доступ к хранилищам для выполнения CRUD-операций, индексацию данных по ключевым полям, версионирование структуры базы. Запросы к IndexedDB выполняются в асинхронном режиме. Объём хранимых данных зависит от многих факторов, но вполне может достигать гигабайтов.


    В общем, функционала вполне достаточно для реализации в рамках браузера приложения в классической трёхуровневой архитектуре.


    Загрузка файлов service worker'а


    При имплементации клиентской бизнес-логики в service worker'е он получается достаточно сложным функциональным блоком. В одном файле его код без средств сборки (типа webpack'а) не разместить. Для загрузки скриптов в область видимости service worker'а существует метод WorkerGlobalScope.importScripts(). Но его особенность в том, что он синхронный. Для service worker'а нет возможности динамической загрузки его компонентов:


    import('/modules/my-module.js')
      .then((module) => {
        // Do something with the module.
      });

    Все скрипты, которые могут понадобиться service worker'у, должны загружаться при его регистрации. Что и понятно — service worker должен обеспечивать работоспособность web-приложения в offline-режиме, а для этого он сначала должен обеспечить свою собственную работоспособность.


    Резюме


    Добавление service worker'а (и IndexedDB) даёт возможность создавать браузерные приложения (PWA в режиме offline) по классической трёхуровневой схеме (интерфейс — логика — данные). Online-режим в PWA добавляет к трёхуровневой схеме ещё и "межсерверные" взаимодействия: Client Logic/Data — Server Logic/Data. Бизнес-логика web-приложения распадается на две части: для отдельного пользователя и для совокупности всех пользователей, во многом совпадающие, но имеющие различия (например, ACL имеет смысл встраивать только в серверную сторону).


    Синхронная загрузка скриптов в service worker'е ограничивает возможности разработчиков в выборе инструментария для реализации бизнес-логики в самом service worker'е (например, слабо поддерживается ES6 import), поэтому есть смысл оставлять за service worker'ами только лишь функции кэширования статики, а всю клиентскую бизнес-логику выводить в Main Thread (включая обработку данных и очередей запросов).


    Поэтому схема архитектуры прогрессивного web-приложения, на мой взгляд, лучше выглядит в таком виде:



    Service worker обрабатывает и кэширует только статику. Клиентская логика отрабатывает в основном потоке браузерного приложения, взаимодействует с хранилищем данных и сама контролирует переход из online в offline и обратно (т.е. обмен данными с серверной частью приложения).


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


    Ссылки


    Похожие публикации

    Средняя зарплата в IT

    113 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 5 253 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 10

      +3
      Service Worker — прекрасная технология с хорошей реализацией. Однако, губит ее то, что это очередная технология от IT-корпорации чтобы сделать их быстрый сайт еще быстрее.
      Кто реально поддерживает SW: медиа, крупные магазины, ряд сервисов близких к IT, энтузиасты. В то время как все остальные либо плевать хотели на SW (как и на все остальные оптимизации), либо используют его неправильно, так что потом от кэша не избавишься.
      ИМХО, современный веб переусложнен, и средней руки разработчик / компания не успевают разобраться что к чему. В итоге это выливается в то, что перерисовывание всего UI с нативного на «корпоративное» явлется важнейшей задачей, а то, что сайт весит 3 МБ уже дело десятое.
      Было бы здорово, если бы компании-флагманы помогали упрощать веб. Например, AMP давольно интересная концепция, которая на самом деле делает сайт быстрым, но, к сожалению, на деле это лишь проприетарная туфта, от корпорации добра, которую опять же поддерживают все те, кто реально парится по поводу производительности.
        +1

        Справедливости ради, AMP был передан под открытое управление (насколько я понимаю, под эгидой OpenJS Foundation) и сейчас разрабатывается вполне привычным образом — техническими комитетами и рабочими группами.
        Ну и используется он далеко не только "корпорацией добра".

          0
          Справедливости ради, AMP был передан под открытое управление

          Я этого не знал, спасибо вам большое, что прояснили.
          Что ж, интересно посмотреть куда эта технология в итоге зайдет.
          0
          Например, AMP давольно интересная концепция, которая на самом деле делает сайт быстрым

          Любой сайт станет быстрым, если оттуда всё выкинуть и собрать новый из 1,5 оптимизированных стандартных блоков.
            0
            Это именно то, что я имею ввиду — нужно выбрасывать всякие понты и рюшечки и делать практично.
            Конечный разработчик на такое сам не пойдет или не сможет пойти (сложновато доказать дизайнерам и начальству, что перерисовывать скролл-бары или переделывать нативные элементы типа button на кастомные не самая лучшая идея).
              0
              Главное, что для ускорения сайта не нужно отдавать весь контент гуглу или яндексу.
          +2
          Отличная статья. Прочитал с удовольствием. Я бы наверное еще расширил ее примерами из жизни, а то действительно, применяют SW там где не нужно.
            –1
            Я зашёл на страницу просмотра сервис воркеров, увидел там 3,5 сайта, которые посещал полгода назад, отключил сервис воркеры в браузере. Ибо зачем оно такое нужно.
              0
              Ибо зачем оно такое нужно.

              Для смартфонов и мобильного интернета.

                0
                Зачем тогда тащат это на ПК и почему у меня в VK видео начинает требовать флеш при отключении воркеров… Не, не нужно.

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

          Самое читаемое