Service worker Youtube sw js что это

Решение для автономного веб-приложения — ServiceWorker

Что такое ServiceWorker?

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

• Развертывание среды Https
• Адаптивный дизайн, после развертывания, может работать на мобильных устройствах и устройствах ПК, и к нему обычно можно получить доступ в разных браузерах.
• Браузеры могут быть быстро доступны в автономном и слабом сетевом окружении.
• Вы можете добавить портал App Icon на свой рабочий стол.
• Нажатие на вход Icon дает эффект анимации, похожий на Native App.
• Гибкие горячие обновления

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

JavaScript Web Workers Explained

• Фоновые сообщения
• Сетевой прокси, прямой запрос, поддельный ответ
• Автономный кеш
• Сообщение push

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

Жизненный цикл ServiceWorker

Я только что упомянул, что у ServiceWorker есть автономная возможность WebWorker. Так как она имеет такую ​​сильную возможность, ей нужно хорошо управлять. Поэтому мы должны понимать жизненный цикл ServiceWorker, то есть его процесс от создания до разрушения. Наиболее распространенной из всех статей, в которых описывается жизненный цикл ServiceWorker, является рисунок ниже.

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

Эта диаграмма делит цикл объявления ServiceWorker на две части: состояние в основном потоке и состояние в дочернем потоке ServiceWorker. Код в дочернем потоке находится в отдельном модуле. Когда нам нужно использовать ServiceWorker, загрузите его следующим образом:

Introduction to Service Workers

if (navigator.serviceWorker != null) < // Зарегистрируем нового работника сервиса, используя метод, специфичный для браузера navigator.serviceWorker.register(‘sw.js’) .then(function(registration) < window.registration = registration; console.log(‘Registered events at scope: ‘, registration.scope); >); >

В настоящее время ServiceWorker находится в фазе синтаксического анализа. Когда анализ завершен, ServiceWorker находится на этапе установки, и регистрация основного потока installing Атрибут представляет устанавливаемый экземпляр ServiceWorker, событие установки запускается в дочернем потоке, а ресурс кэша указывается в событии установки.

var cacheStorageKey = ‘minimal-pwa-3’; var cacheList = [ ‘/’, «index.html», «main.css», «e.png», «pwa-fonts.png» ] // Когда браузер заканчивает анализ файла sw, служебное событие внутренне инициируется событием установки self.addEventListener(‘install’, function(e) < console.log(‘Cache event!’) // Открываем пространство кеша и добавляем связанные ресурсы, которые необходимо кэшировать в кеш e.waitUntil( caches.open(cacheStorageKey).then(function(cache) < console.log(‘Adding to Cache:’, cacheList) return cache.addAll(cacheList) >) ) >)

Здесь Cache API используется для кэширования ресурсов, и в то же время e.waitUntil принимает Promise для ожидания успешного завершения кэша ресурсов. После успешного выполнения статуса Promise ServiceWorker переходит в установленное состояние, что означает, что установка завершена. В это время возвращенное в основной поток свойство registration.waiting представляет ServiceWorker, входящий в установленное состояние.

/* In main.js */ navigator.serviceWorker.register(‘./sw.js’).then(function(registration) < if (registration.waiting) < // Service Worker is Waiting >>)

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

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

В это время жизненный цикл ServiceWorker входит в фазу активации, и дочерний поток ServiceWorker получает activate Событие:

// Если в текущем браузере нет активированного работника службы или активированный работник уволен, // новый работник сервиса входит в активное событие self.addEventListener(‘activate’, function(e) < console.log(‘Activate event’); console.log(‘Promise all’, Promise, Promise.all); // Активные события обычно выполняют некоторую работу по освобождению истекших ресурсов var cacheDeletePromises = caches.keys().then(cacheNames => < console.log(‘cacheNames’, cacheNames, cacheNames.map); return Promise.all(cacheNames.map(name => < if (name! == cacheStorageKey) else < return Promise.resolve(); >>)); >); console.log(‘cacheDeletePromises: ‘, cacheDeletePromises); e.waitUntil( Promise.all([cacheDeletePromises] ) ) >)

В это время обычно выполняется некоторая очистка кэша. Когда обещание, полученное e.waitUntil, переходит в успешное состояние, жизненный цикл ServiceWorker переходит в активированное состояние. В это время активное свойство регистрации в главном потоке представляет экземпляр ServiceWorker в активированном состоянии.

/* In main.js */ navigator.serviceWorker.register(‘./sw.js’).then(function(registration) < if (registration.active) < // Service Worker is Active >>)

На этом этапе ServiceWorker официально входит в активное состояние и может перехватывать сетевые запросы. Если основной поток имеет метод выборки для запроса ресурсов, то событие выборки может быть вызвано в коде ServiceWorker:

fetch(‘./data.json’)

В это время событие fetch будет запущено в дочернем потоке:

self.addEventListener(‘fetch’, function(e) < console.log(‘Fetch event ‘ + cacheStorageKey + ‘ :’, e.request.url); e.respondWith (// Сначала определите, существует ли такой же ресурс в кеше caches.match(e.request).then(function(response) < if (response! = null) console.log(‘Fallback to fetch:’, e.request.url) return fetch(e.request.url); >) ) >)

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

Обновление ресурса кэша

Поэтому, если мы обновим код подпотока ServiceWorker в новой версии, когда браузер заходит на страницу веб-сайта, браузер получает новый файл и сравнивает побайтный файл /sw.js и обнаруживает, что происходит обновление, и запускает алгоритм обновления open_in_new, Новый файл установлен и инициировано событие установки. Однако старый Service Worker, который уже активирован в это время, все еще работает, и новый Service Worker перейдет в состояние ожидания после завершения установки. Пока все открытые страницы не будут закрыты, старый работник сервиса автоматически останавливается, и новый работник сервиса не вступит в силу на следующей вновь открывшейся странице. Если вы хотите обновить немедленно, вам нужно что-то сделать в новом коде. Сначала вызовите метод self.skipWaiting () в событии установки, а затем вызовите метод self.clients.claim () в активном событии, чтобы уведомить каждого клиента.

// Когда браузер заканчивает анализ файла sw, служебное событие внутренне инициируется событием установки self.addEventListener(‘install’, function(e) < debugger; console.log(‘Cache event!’) // Открываем пространство кеша и добавляем связанные ресурсы, которые необходимо кэшировать в кеш e.waitUntil( caches.open(cacheStorageKey).then(function(cache) < console.log(‘Adding to Cache:’, cacheList) return cache.addAll(cacheList) >).then(function() < console.log(‘install event open cache ‘ + cacheStorageKey); console.log(‘Skip waiting!’) return self.skipWaiting(); >) ) >) // Если в текущем браузере нет активированного работника службы или активированный работник уволен, // новый работник сервиса входит в активное событие self.addEventListener(‘activate’, function(e) < debugger; console.log(‘Activate event’); console.log(‘Promise all’, Promise, Promise.all); // Активные события обычно выполняют некоторую работу по освобождению истекших ресурсов var cacheDeletePromises = caches.keys().then(cacheNames => < console.log(‘cacheNames’, cacheNames, cacheNames.map); return Promise.all(cacheNames.map(name => < if (name! == cacheStorageKey) else < return Promise.resolve(); >>)); >); console.log(‘cacheDeletePromises: ‘, cacheDeletePromises); e.waitUntil( Promise.all([cacheDeletePromises] ).then(() => < console.log(‘activate event ‘ + cacheStorageKey); console.log(‘Clients claims.’) return self.clients.claim(); >) ) >)

Обратите внимание, что браузер получил новую версию кода ServiceWorker. Если браузер сам кеширует файл sw.js, он не получит последний код, поэтому лучше настроить файл sw как элемент управления cache: no-cache или Добавьте MD5.

В реальном процессе, как мы только что поместили index.html в кеш, а в нашем событии fetch, если кеш попал, он напрямую берется из кеша, что приведет к тому, что браузер получит даже если обновится наша страница индекса. Это всегда страница индекса, кэшированная предыдущим ServiceWorker, поэтому некоторые платформы ServiceWorker поддерживают нас в настройке стратегии обновления ресурса.

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

self.addEventListener(‘fetch’, function(e) < console.log(‘Fetch event ‘ + cacheStorageKey + ‘ :’, e.request.url); e.respondWith (// Эта стратегия сначала получает ресурсы из сети, а в случае сбоя получения считывает ресурсы из кэша fetch(e.request.url) .then(function (httpRes) < // Запрос не выполнен, и результат с ошибкой возвращается напрямую if (!httpRes || httpRes.status !== 200) < // return httpRes; return caches.match(e.request) >// Если запрос успешен, кешируем запрос. var responseClone = httpRes.clone(); caches.open(cacheStorageKey).then(function (cache) < return cache.delete(e.request) .then(function() < cache.put(e.request, responseClone); >); >); return httpRes; >) .catch (function (err) ) ) >)

Вопросы, требующие внимания

ServiceWorker — это новая возможность. В настоящее время платформа IOS не дружелюбна к нему, но на стороне Android нет больших проблем. Платформа WeChat также хорошо это поддерживает.

• Зависит от Cache API
• Положитесь на Fetch API Promise API
• Https среда

• установка или активное событие не удалось
• Не-Https среда
• Проблема с установочным файлом sw.js
• настройка объема

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

Источник: russianblogs.com

Favicon

Блог по web технологиям. Веб студия г. Воронеж. Создание и поддержка сайтов на заказ.

• Главная
• /
• JavaScript
• /
• Фронтенд
• /
• Миграция сайта в Progressive Web App (PWA)

Миграция сайта в Progressive Web App (PWA)

Опубликовано 30.11.2017 08.07.2022 Виктор Обломов

1 . Обзор

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

Чему вы научитесь

• Как быстро превратить существующий сайт в Progressive Web App
• Как стать mobile-friendly и сделать Web App Manifest
• Как предложить вовлеченным пользователям установку приложения
• Как посылать push-уведомления вашим пользователям
• Как поддерживать статический и динамический контент в оффлайне

Что вам понадобится

• Chrome 52 или выше
• (Опционально) Подключенное Android устройство с запущенным Chrome 52 или выше
• Базовое понимание git и Chrome DevTools
• Примеры кода и текстовый редактор

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

Точка старта

Вы будете модифицировать сайт под названием Dragotchi, в котором вы можете растить и играть с вашим виртуальным драконом. У сайта три страницы (Home, Dragotchi и FAQ). Две статические, а Dragotchi делает простые Ajax запросы к открытому серверу.

Этот сайт desktop-only, у него нет адаптивного дизайна и он, вобщем, устарел. Тем лучше! Нам понадобится всего несколько шагов, чтобы улучшить его.

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

2 . Начинаем

Давайте начнем с того, что проверим сайт Dragotchi и настроим ваше рабочее окружение.

Что вам понадобится

Клонируйте репозиторий GitHub из командной строки:

$ git clone https : //github.com/googlecodelabs/migrate-to-progressive-web-apps.git

Создастся директория migrate-to-progressive-web-apps содержащая код для каждого шага. Для этого кодлаба используйте папку work и вносите все изменения там.

Для проверки кода, вам понадобится сервер Simple HTTP Server application (или например, локальный Python сервер или какой либо другой HTTP сервер) для работы с папкой work на порту 8887 — если только вы его не изменили.

Теперь вы можете открыть URL и поиграть с . Не волнуйтесь, кодлаб подождет.

Просмотр сайта на мобильном

Если у вас есть подключенное Android устройство, вы можете (на вашем компьютере) открыть URL: chrome://inspect (вам надо скопировать и вставить это в адресную строку). Затем, пропишите порт, как показано ниже, чтобы перенаправить порт на тот же порт на мобильном. Нажмите enter для сохранения.

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

Теперь вы должны получить доступ к простой версии сайта Dragotchi по адресу http://localhost:8887/ на вашем мобильном телефоне. Версия на вашем мобильном телефоне не оптимизирована для такого экрана — мы займемся этим в следующем разделе.

3 . Современные теги в head

Готовый код находится в migrate-to-progressive-web-apps/step3-manifest .

Первое, что мы сделаем для этого старомодного сайта — сделаем его mobile-friendly и включим то, что называется Web App Manifest. Файл манифеста описывает мета информацию о сайте, например то, как он будет выглядеть при добавлении на домашний экран пользователя.

У сайта Dragotchi три HTML страницы. Так как он не использует никакой системы для управления шаблонами, вам надо добавить следующие строки в раздел каждой страницы — index.html, faq.html и dragon.html

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

Окно просмотра (viewport)

Первой строкой идет тег meta , описывающий вьюпорт. Подробнее о нем вы можете прочитать на favourite search engine, а сейчас, если вы перезагрузите сайт (на вашем андройд телефоне, или используя панель разработчика), вы увидите, что страница сайта корректно умещается на экране.

Манифест веб приложения

Вторая строка добавляет Web App Manifest, который нужен для управления тем, в каком виде ваш сайт добавляется на домашний экран. Он заменяет старые мета-теги, вроде mobile-web-app-title . В коде страницы мы сослались на этот файл — давайте теперь его сделаем!

Откройте текстовый редактор. Мы напишем в формате JSON. Начнем с чего-то подобного:

«name» : «The Most Awesome Dragon Site» ,
«short_name» : «» ,
«display» : «minimal-ui» ,
«theme_color» : «#673ab6» ,
«background_color» : «#111111» ,
«src» : «icon-192.png» ,
«sizes» : «192×192» ,
«type» : «image/png»

Поле short_name определяет то, что появится на домашнем экране пользователя: постарайтесь задать строку настолько минимальной, насколько это возможно, название больше 15 символов может быть обрезано. В нашем случае мы использовали эмодзи и , так как они абсолютно валидны!

• Chrome и другие браузеры очень придирчиво относятся к JSON: не добавляйте лишние запятые и всегда используйте двойные кавычки
• По хорошему вы должны определять несколько иконок под разные размеры экрана — большие иконки, например, могут показываться неправильно на маленьких экранах
• Есть и другие свойства, которые вы можете использовать, найти их можно тут

Сохраните файл как manifest.json . Перезагрузите страницу на вашем Android устройстве, зайдите в меню в верхнем правом углу и выберите «Add to Home Screen». На вашем домашнем экране должно появиться новое приложение с драконами!

Если у вас нет под рукой андройд устройства, выберите Application в Chrome Developer Tools. Нажмите Manifest , чтобы увидеть детали манифеста. Если вы видите No manifest detected , убедитесь, что вы создали и сохранили файл manifest.json в папке work .

Вау! Это прекрасно!

Я знаю. Давайте двинемся дальше и добавим Service Worker!

4 . Service Worker

Готовый код находится в migrate-to-progressive-web-apps/step4-sw .

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

Даже пустой Service Worker может помочь вашему сайту. Как получить такую прекрасную штуку? Читайте дальше.

Добавляем Service Worker в код

Сначала нам надо создать новый JavaScript файл. Давайте скопируем самый минимум в новый файл

/** An empty service worker! */
self . addEventListener ( ‘fetch’ , function ( event ) <
/** An empty fetch handler! */

Сохраните это как sw.js ! Вот и все, все сделано! Вы создали service worker!

Регистрация Service Worker

Что, есть еще один шаг? Ну… ладно. На код, приведенный выше, и сам файл (sw.js) еще никто не ссылается. Вам обязательно надо его зарегистрировать, то есть прописать в коде вашего сайта.

Сайт Dragotchi уже содержит скрипт, который запускается на каждой странице. Откройте site.js (еще один пустой файл) и добавьте код регистрации

navigator . serviceWorker navigator . serviceWorker . register ( ‘./sw.js’ ) . then ( function ( registration )
console . log ( ‘Excellent, registered with scope: ‘ , registration . scope ) ;

Вот и все! Этот код будет исполняться на каждой загружаемой странице. Если Service Worker уже зарегистрирован, ваш браузер проигнорирует запрос и проверит изменения чуть позднее.

Перезагрузите страницу и проверьте в chrome://serviceworker-internals/ то, что скрипт для сайта действительно загрузился.

Это выглядит примерно так:

Прекрасно, но что мне с этим делать?

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

Во-вторых, вы можете расширить Service Worker так, чтобы ваш сайт поддерживал push-уведомления и работал в офлайне. Читайте дальше!

5 . Пример push-уведомлений

Готовый код находится в migrate-to-progressive-web-apps/step5-push , также вам необходимо добавить publicKey из Push Companion внутри site.js .

Давайте сделаем поддержку push-уведомлений! Мы не станем разбираться с сервером отправки сообщений, а просто зарегистрируем его на вашем сайте, и вы сможете управлять им из командной строки.

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

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

Подписка на push

Внутри кода вашего сайта вам необходима подписка на push-уведомления. На самом деле это довольно просто. Давайте добавим код подписки в site.js

navigator . serviceWorker navigator . serviceWorker . ready . then ( function ( serviceWorkerRegistration )
serviceWorkerRegistration . pushManager . getSubscription ( )
. then ( function ( subscription ) <
// subscription will be null or a PushSubscription

Если subscription равен null , то нам нужно зарегистрироваться — замените комментарий следующим кодом:

if ( subscription ) <
console . info ( ‘Got existing’ , subscription ) ;
window . subscription = subscription ;
return ; // got one, yay
const applicationServerKey = urlB64ToUint8Array ( publicKey ) ;
serviceWorkerRegistration . pushManager . subscribe ( <
userVisibleOnly : true ,
applicationServerKey ,
. then ( function ( subscription ) <
console . info ( ‘Newly subscribed to push!’ , subscription ) ;
window . subscription = subscription ;

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

const publicKey = ‘

‘ ;

Теперь вам нужно сохранить файл и перезагрузить страницу — на десктопе или мобильном устройстве, не имеет значения. Если вы посмотрите в консоль разработчика, то увидите сообщение в логах о подписке, содержащее поле «endpoint». Мы используем его в дальнейшем, так что не закрывайте окно.

Если вы видите ошибку, убедитесь, что ваш publicKey выглядит как длинная строка с кодировкой base64, а не «».

Важно: Демонстрация подписки на push-уведомления сразу после открытия страницы — это прекрасно. Но если пользователи будут получать подобные запросы в неожиданные моменты, то вы будете получать много отказов. Данные Google показывают, что вероятность подписок значительно выше после каких либо действий пользователя.

Показываем уведомление

Подписка это хорошо, но что должен делать ваш сайт при получении сообщения? Скорее всего сайт Dragotchi не будет загружен у пользователя все время, поэтому вам надо добавить код, который обрабатывает сообщения в вашем Service Worker. Если вы помните, мы ранее говорили о том, что он может запускаться в любое время.

Откройте sw.js и добавьте секцию:

self . addEventListener ( ‘push’ , function ( event ) <
event . waitUntil (
self . registration . showNotification ( ‘Got Push?’ , <
body : ‘Push Message received’

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

Сводим все вместе

Дальше, давайте откроем командную строку (используйте ⌘-⌥-J или Ctrl-Alt-J, чтобы открыть его, если вы еще этого не сделали) и используем curl для составления правильного HTTP запроса. Он позволит вашему устройству проснуться и запустить код, который мы только что добавили для показа уведомления.

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

var privateKey = window . prompt ( ‘Enter Private Key from Push Companion’ ) ;
const curl = ` curl «$» ` +
` — H «Authorization: $» ` +
` — H «Crypto-Key: p256ecdsa=$

» ` +
` — H «Content-Length: 0» ` ;
console . warn ( ‘Copy and paste the following into a command-line-‘ ) ;
console . dir ( curl ) ;

Это немедленно предложит вам секретный ключ от Push Companion. Введите его. Как только вы нажмете «ОК», консоль отобразит очень длинную строку. Идите вперед и дважды щелкните по ней, скопируйте и вставьте в ту же самую командную строку, чтобы запустить его.

Важно. Код, который вы только что вставили, использует сохраненный объект подписки, который вы обычно отправляете на свой сервер, чтобы подготовить и выполнить запрос. Он также использует вспомогательный метод под названием prepareAuthorization , находящийся в crypto.js , который примерно соответствует первой части статьи Matt Gaunt Web Push Protocol, для подписания запроса с помощью вашего закрытого ключа.

И, вуаля

Вы должны увидеть нечто подобное на вашем клиенте — на компьютере или в мобильном устройстве. Хорошая работа!

Используя сервисных работников

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

Помещение работников сервисной службы

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

Предыдущая попытка, AppCache , казалась хорошей идеей, потому что она позволяла очень легко указывать активы для кэширования. Тем не менее, он сделал много предположений о том, что вы пытались сделать, а затем ужасно сломался, когда ваше приложение не полностью соответствовало этим предположениям. Прочтите статью Джейка Арчибальда (к сожалению, названную, но хорошо написанную) Application Cache is Douchebag для более подробной информации.

Примечание. В Firefox 84 AppCache был удален ( ошибка 1619673 ). Его также планируется удалить в Chromium 90, и он устарел в Safari.

Работники службы должны, наконец, исправить эти проблемы. Синтаксис сервис-воркера сложнее, чем у AppCache, но компромисс заключается в том, что вы можете использовать JavaScript для управления своим поведением, подразумеваемым AppCache, с высокой степенью детализации, что позволяет решать эту и многие другие проблемы. Используя Service worker, вы можете легко настроить приложение на использование сначала кэшированных ресурсов, тем самым обеспечивая работу по умолчанию даже в автономном режиме, а затем получать больше данных из сети (обычно это называется Offline First ). Это уже доступно в нативных приложениях, что является одной из основных причин, по которой нативные приложения часто выбирают вместо веб-приложений.

Настройка на игру с обслуживающим персоналом

В наши дни сервис-воркеры включены по умолчанию во всех современных браузерах. Чтобы запустить код с помощью сервис-воркеров, вам нужно обслуживать свой код через HTTPS — сервис-воркеры могут работать только через HTTPS из соображений безопасности. Таким образом, GitHub — хорошее место для проведения экспериментов, поскольку он поддерживает HTTPS. Чтобы облегчить локальную разработку, браузеры также считают localhost безопасным источником.

Basic architecture

Для работников сервисной службы при базовой настройке,как правило,соблюдаются следующие этапы:

1. URL-адрес работника службы выбирается и регистрируется с помощью serviceWorkerContainer.register() .
2. В случае успеха сервисный работник выполняется в ServiceWorkerGlobalScope ; это в основном особый вид рабочего контекста, запускающийся из основного потока выполнения сценария без доступа DOM.
3. Работник сервисной службы теперь готов к обработке событий.
4. Установка рабочего выполняется при последующем обращении к страницам,управляемым рабочим сервисом.Событие Install всегда является первым событием,отправляемым на рабочий сервис (это может быть использовано для запуска процесса заполнения IndexedDB и кэширования активов сайта).Это фактически та же процедура,что и установка родного приложения или приложения для Firefox OS-все становится доступным для использования в автономном режиме.
5. Когда обработчик oninstall завершает работу, сервисный работник считается установленным.
6. Далее идет активация. Когда сервисный работник установлен, он получает событие активации. Основное использование onactivate предназначено для очистки ресурсов, которые использовались в предыдущих версиях рабочего сценария Service.
7. Работник службы теперь будет контролировать страницы, но только те, которые открываются после того, как register() успешно завершен . т. е. документ начинает жизнь с работником службы или без него и сохраняет его на протяжении всей жизни. Таким образом, документы должны быть перезагружены для фактического контроля.

На приведенном ниже графике показана краткая информация о доступных событиях,связанных с работниками сервисных служб:

Демонстрация работников сферы обслуживания

Чтобы продемонстрировать только самые основы регистрации и установки сервис-воркера, мы создали простую демонстрацию под названием sw-test , которая представляет собой простую галерею изображений Lego из «Звездных войн». Он использует функцию на основе обещаний для чтения данных изображения из объекта JSON и загрузки изображений с помощью Ajax перед отображением изображений в строке вниз по странице. Пока что мы сделали все статично и просто. Он также регистрирует, устанавливает и активирует сервис-воркер, и когда браузеры поддерживают больше спецификаций, он будет кэшировать все необходимые файлы, чтобы он мог работать в автономном режиме!

Регистрация вашего работника

Первый блок кода в файле JavaScript нашего приложения — app.js — выглядит следующим образом. Это наша отправная точка в использовании сервис-воркеров.

const registerServiceWorker = async ( ) => < if (‘serviceWorker’ in navigator) < try < const registration = await navigator.serviceWorker.register( ‘/sw-test/sw.js’, < scope: ‘/sw-test/’, > ); if (registration.installing) < console.log(‘Service worker installing’); > else if (registration.waiting) < console.log(‘Service worker installed’); > else if (registration.active) < console.log(‘Service worker active’); > > catch (error) < console.error(`Registration failed with $ `); > > >; // . registerServiceWorker();

1. Блок if выполняет тест на обнаружение возможностей,чтобы убедиться,что сервисные работники поддерживаются,прежде чем пытаться зарегистрировать один из них.
2. Затем мы используем функцию ServiceWorkerContainer.register() чтобы зарегистрировать работника службы для этого сайта, который представляет собой просто файл JavaScript, находящийся внутри нашего приложения (обратите внимание, что это URL-адрес файла относительно источника, а не JS-файл, который ссылается на него. )
3. Параметр scope является необязательным и может использоваться для указания подмножества вашего контента, которое вы хотите, чтобы работник службы контролировал. В этом случае мы указали « /sw-test/’ , что означает весь контент в источнике приложения. Если вы пропустите его, оно все равно будет по умолчанию иметь это значение, но мы указали его здесь в целях иллюстрации.

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

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

Примечание: ваш сервис-воркер работает как прокси-сервер, позволяя вам изменять запросы и ответы, заменять их элементами из собственного кеша и т. Д.

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

Почему мой работник не регистрируется?

Это может быть по следующим причинам:

1. Вы не запускаете свое приложение через HTTPS.
2. Путь к вашему файлу сервис-воркера написан неправильно — он должен быть указан относительно источника, а не корневого каталога вашего приложения. В нашем примере рабочий находится по адресу https://mdn.github.io/sw-test/sw.js , а корень приложения — по https://mdn.github.io/sw-test/ . Но путь должен быть записан как /sw-test/sw.js , а не /sw.js .
3. Также не разрешается указывать на сервисный работник другого происхождения,чем ваше приложение.

• Работник сервисной службы будет ловить запросы от клиентов только в пределах компетенции работника сервисной службы.
• Максимальный объем работника сервисной службы определяется его местонахождением.
• Если ваш сервисный работник активен на клиенте, обслуживаемом с заголовком Service-Worker-Allowed , вы можете указать список максимальных областей для этого работника.
• В Firefox API Service Worker скрыты и не могут использоваться, когда пользователь находится в режиме частного просмотра .

Установка и активация:заполнение кэша

После того,как Ваш сервисный работник зарегистрирован,браузер попытается установить,а затем активировать сервисного работника для Вашей страницы/сайта.

Событие установки запускается, когда установка успешно завершена. Событие установки обычно используется для заполнения возможностей автономного кэширования вашего браузера активами, необходимыми для запуска приложения в автономном режиме. Для этого мы используем API хранилища Service Worker — cache — глобальный объект в сервис-воркере, который позволяет нам хранить активы, доставленные ответами, и ключи по их запросам. Этот API работает аналогично стандартному кешу браузера, но зависит от вашего домена. Он сохраняется до тех пор, пока вы не скажете ему не делать этого — опять же, у вас есть полный контроль.

Вот как наш сервис-воркер обрабатывает событие install

const addResourcesToCache = async (resources) => < const cache = await caches.open(«v1»); await cache.addAll(resources); >; self.addEventListener(«install», (event) => < event.waitUntil( addResourcesToCache([ «/sw-test/», «/sw-test/index.html», «/sw-test/style.css», «/sw-test/app.js», «/sw-test/image-list.js», «/sw-test/star-wars-logo.jpg», «/sw-test/gallery/bountyHunters.jpg», «/sw-test/gallery/myLittleVader.jpg», «/sw-test/gallery/snowTroopers.jpg», ]) ); >);

1. Здесь мы добавляем обработчик события install self ), а затем связываем метод ExtendableEvent.waitUntil() с событием — это гарантирует, что сервис-воркер не установится до тех пор, пока код внутри waitUntil() не будет успешно выполнен.
2. Внутри addResourcesToCache мы используем метод caches.open() для создания нового кеша с именем v1 , который будет версией 1 кеша ресурсов нашего сайта. Затем мы вызываем функцию, которая вызывает addAll() для созданного кеша, который в качестве своего параметра принимает массив URL-адресов, относящихся к источнику, ко всем ресурсам, которые вы хотите кэшировать.
3. Если обещание отклонено,установка не удается,и рабочий ничего не делает.Это нормально,так как вы можете исправить свой код и повторить попытку в следующий раз,когда произойдет регистрация.
4. После успешной установки сервис-воркер активируется. Это не имеет особого смысла при первой установке/активации вашего сервисного работника, но имеет большее значение, когда сервисный работник обновляется (см . раздел Обновление вашего сервисного работника позже).

Примечание: localStorage работает аналогично кешу сервис-воркеров , но он синхронный, поэтому не разрешен в сервис-воркерах.

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

Web APIs

Использование серверных событий
Разработка веб-приложения,использующего события,посылаемые сервером,проста.
API Service Worker

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

Индивидуальные ответы на запросы

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

Обновление вашего работника службы поддержки

Если ваш сервис-рабочий был ранее установлен,но затем доступна новая версия обновления загрузки страницы,фоновая,еще не активированная.

Источник: runebook.dev