Доброго времени суток, друзья!
Вероятно, многие из вас слышали о таком новшестве в экосистеме JavaScript, как сервис-воркеры, которые являются ключевым элементом современной веб-разработки. Сервис-воркеры становятся все более востребованными, в первую очередь, благодаря популярности прогрессивных веб-приложений (Progressive Web Applications — PWA).
Когда я впервые услышал о них, я задался вопросом: «Когда мы должны использовать сервис-воркеры? В каким сценариях или контексте мы можем их использовать?»
В данной статье мы рассмотрим несколько практических примеров использования сервис-воркеров, что впоследствии, смею надеяться, сделает счастливыми ваших пользователей.
Полагаю, прежде чем разбирать практические примеры, необходимо хотя бы в общих чертах рассмотреть теоретические основы работы сервис-воркеров. Для начинающих разработчиков это послужит хорошим подспорьем в дальнейших начинаниях.
Что есть сервис-воркер?
Серсис воркер — это скрипт, запускаемый браузером в фоновом процессе. Помните, что сервис-воркер совершенно не зависит от страницы, с которой он взаимодействует или которой он служит (to serve — служить).
По сути, сервис-воркер представляет собой прокси сервер между веб-приложением, браузером и сетью.
Сервис-воркеры позволяют веб-приложениям работать подобно нативным приложениям.
Несколько фактов о сервис-воркерах
- Сервис-воркеры не имеют прямого доступа к DOM. Для этого они используют механизм ответов на запросы через интерфейс postMessages.
- Сервис-воркеры принудительно отменяются (останавливаются), когда не используются. Это означает, что они управляются с помощью событий.
- Сервис-воркеры предполагают использование обещаний (промисов).
- Ввиду больших возможностей сервис-воркеры могут использоваться только через HTTPS. На локальном сервере можно обойтись без HTTPS.
Как сервис-воркеры работают? Беглый взгляд
Сервис-воркеры позволяют перехватывать запросы к серверу и кешировать эти запросы с целью повышения производительности приложений. Таким образом, повышение производительности обеспечивается благодаря кешированию всего контента.
Но лучше один раз увидеть, так что вот вам изображение, показывающее работу сервис-воркера:
Жизненный цикл сервис-воркера
Как я упоминал ранее, сервис-воркеры работают независимо от управляющей страницы. Если вы хотите установить сервис-воркер в своем приложении, первым делом нужно его зарегистрировать.
После этого браузер, запустивший установку сервис-воркера, переходит в фоновый режим:
Самые распространенные случаи использования
Теперь, когда мы знаем, как работают сервис-воркеры, настало время поговорить о том, где они используются.
Кеширование
Как отмечалось выше, сервис-воркеры могут использоваться для кеширования. Вот некоторые примеры:
- Только кеширование — у вас есть статический контент, который никогда не меняется.
- Сеть или кеш — вы хотите показывать пользователям актуальный контент с условием быстрой загрузки.
- Кеш и обновление — вы хотите отображать контент мгновенно и не возражаете против периодической синхронизации с сервером.
- Кеш, обновление и перезагрузка — вы хотите показывать контент максимально быстро, подспудно обновляя отдельные его части и отображая их каким-либо «бесшовным» способом.
Веб-пуш (Web Push)
Веб-пуш позволяет приложениям отправлять пуш-уведомления и отображать контент, получаемый в ответ на эти уведомления.
- Пуш и обновление контента — вы хотите обмениваться (доставлять и получать) доступным контентом.
- Пуш и контент — вы хотите оперировать не только текстом, но также информацией других видов, обогащающей ваши сообщения.
- Насыщенный пуш- вы хотите показывать изображения, процесс загрузки и другие штуки, улучшающие сообщение, которое вы хотите доставить.
- Пуш и клиент — вы хотите показывать уведомления в зависимости от состояния приложения.
Более сложные примеры использования
API аналитики
У меня есть приложение. И я хочу добавить в него возможность следить за использованием приложения. Для этого я беру синхронное API для обновления собранных данных время от времени.
Балансировщик загрузки
Допустим, вы хотите иметь возможность выбирать лучшего провайдера контента, опираясь на показатели работы сервера. В этом случае вам нужен сервис-воркер для перехвата запросов и осуществления выбора.
Я настоятельно рекомендую вам посетить ServiceWorke.rs для более подробного изучения сервис-воркеров.
Отрабатываем навыки
Как я всегда говорю: «Хочешь научиться плавать — лезь в воду». Изучение теории — вещь замечательная, но пока не испачкаешь руки, ничему не научишься.
Регистрация сервис-воркера
Если мы вновь обратимся к иллюстрации жизненного цикла сервис-воркера, то увидим, что перво-наперво нам необходимо его установить. Чтобы это сделать нам нужно его зарегистрировать.
// проверяем поддержку браузером if('serviceWorker' in navigator){ console.log('Сервис-воркер поддерживается') // осуществляем регистрацию после загрузки страницы // для этого добавляем обработчик события "load" window.addEventListener('load', () => { // регистрируем сервис-воркер navigator.serviceWorker .register('/service-worker.js') .then(registration => { // регистрация прошла успешно console.log(`Сервис-воркер успешно зарегистрирован, scope: ${registration.scope}`) // scope - подмножество контента, которое находится под контролем сервис-воркера }) }) .catch(error => { // регистрация провалилась console.log(`В процессе регистрация возникла ошибка: ${error}`) }) } В работе сервис-воркера можно убедиться, перейдя по адресу: Chrome://inspect/#service-workers.
Также информацию о состоянии сервис воркера можно получить в инструментах разработчика: Application -> Service Workers.
Что дальше?
Теперь нам нужно закешировать все файлы. Мы можем выбирать файлы для кеширования. Вот как это выглядит:
// название кеша const CACHE_NAME = 'example.com-v1' // выбираем файлы для кеширования const cacheAssets = ['index.html', 'about.html', 'js/main.js'] // добавляем обработчик события "install" self.addEventListener('install', e => { console.log('Сервис-воркер установлен') e.waitUntil( caches .open(CACHE_NAME) .then(cache => { console.log('Сообщение от сервис-воркера: файлы кешируются') cache.addAll(cacheAssets) }) .then(() => { self.skipWaiting() }) ) }) Вот что здесь происходит:
- Определяем название кеша (example.com-v1).
- Выбираем файлы для кеширования. Для этого создаем массив.
- Внутри обработчика события «install» велим браузеру ожидать завершения промиса, затем открываем кеш, который будет сохранен под именем «example.com-v1».
- Наконец, добавляем выбранные файлы в кеш.
Удаляем неиспользуемый кеш
Далее нам необходимо удалить старые версии кеша:
// добавляем обработчик события "activate" self.addEventListener('activate', e => { console.log('Сервис-воркер активирован') e.waitUntil( caches.keys().then(cacheNames => { return Promise.all( cacheNames.map(cache => { if(cache !== CACHE_NAME){ console.log('Производится удаление старого кеша') return caches.delete(cache) } }) ) }) ) })
Получение ответа
Ничто из приведенного выше не имеет смысла, если у нас нет возможности получить закешированный контент.
Его можно получить с помощью обработчика события «fetch»:
// добавляем обработчик события "fetch" self.addEventListener('fetch', e => { e.respondWith( fetch(e.request) .then(res => { const copyCache = res.clone() caches.open(CACHE_NAME).then(cache => { cache.put(e.request, copyCache) }) return res }) .catch(error => caches.match(e.request).then(res => res)) ) }) Весь код можно посмотреть здесь.
Благодарю за внимание.
ссылка на оригинал статьи https://habr.com/ru/post/491840/
Добавить комментарий