Русский
Русский
English
Статистика
Реклама

Web applications

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

12.08.2020 10:04:09 | Автор: admin

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'ов и способы их использования.


Ссылки


Подробнее..

PWA не для всех

20.09.2020 22:11:04 | Автор: admin

В комментах к моей предыдущей статье о service worker'ах была высказана мысль, что PWA на десктопах - вещь малополезная. Примерно полгода назад я разбирался с тем, как прикрутить PWA Vue Storefront к магазинам на платформе Magento и мне понравилось, как шустро крутилось в моём компьютере это приложение по сравнению с оригинальным web-интерфейсом. Мой персональный опыт показывал, что PWA на десктопах имеет неплохую перспективу, но дальнейшее углубление в тему показало, что коллега @sumanai со своим отрицанием PWA на десктопах был прав.

Offline

Какая основная "фишка" прогрессивных web-приложений?

Способность работать в режиме offline.

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

Ввод-вывод

По способу ввода ("сенсорный экран" против "клавиатура + мышь") и отображения информации (размер дисплея в дюймах) устройства можно разделить на две больших группы:

  • смартфоны и планшеты

  • ноутбуки и десктопы

Web-интерфейсы

Современные браузеры предлагают разнообразный API для web-приложений, большая часть которого работает для обеих групп устройств. Тем не менее вот эти три интерфейса актуальны именно для смартфонов/планшетов:

IndexedDB

Для "осознанного" кэширования запросов (например, на уровне service worker'ов) современные браузеры предоставляют Cache API, но основным хранилищем данных при работе в режиме offline является IndexedDB. Серверная база данных общего пользования (MySQL, Postgres, Oracle, MongoDB, ...) в этот момент заменяется базой данных персонального пользования (IndexedDB).

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

SEO

В моей статье "Влияние service worker'ов на web-приложения" я пришёл вот к такой схеме работы PWA:

При общении браузера с сервером возникают два потока информации:

  • статика: это код (HTML/CSS/JS) и медиа-файлы (в основном изображения), которые могут кэшироваться service worker'ом;

  • API: это пользовательские данные, которые так или иначе должны мигрировать между серверным хранилищем (DB) и персональным хранилищем (IndexedDB);

PWA - это прежде всего альтернатива native apps для мобильных устройств. Native apps также можно рассматривать с позиции, что статика (код + медиа) сворачивается в один пакет и распространяется через App Store или Google Play, а данные передаются между приложением и сервером через API (с учётом offline/online состояния подключения). И при этом никто не ожидает, что поисковики должны индексировать API-запросы native apps. От web-приложений же наоборот ждут, что любой адрес (страница) на сервере должен иметь возможность быть собранным на стороне сервера, в том числе и для индексации поисковиками.

Резюме

PWA - это, в первую очередь, альтернатива native apps для мобильных устройств.

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

Особенности взаимодействия пользователя со смартфоном/планшетом (ввод-вывод, гео-позиционирование) достаточно сильно отличаются от особенностей взаимодействия пользователя с десктопом/ноутбуком. Создание универсального решения ("амфибии") добавляет сложности по отношению к двум решениям - отдельно для смартфонов/планшетов и отдельно для ноутбуков/десктопов. Причём не столько с точки зрения кодирования, сколько с точки зрения UX.

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru