Сервизните работници предлагат много вълнуващи възможности на съвременните уеб приложения. Те надхвърлят традиционните граници на обикновен JavaScript, работещ в браузъра. Тези работници работят във фонов режим и изпълняват задачи, които не се нуждаят от взаимодействие с потребителя.
В тази статия ще представя пет разширени функции, добавени към вашите уеб приложения.
След като се влюбите в сервизните работници, препоръчвам ви да създадете свои собствени функции за многократна употреба, които намаляват количеството шаблони, необходими, за да се насладите на една от многото възможности на SW. Можете да използвате хъбове за компоненти като Bit (Github), за да споделяте функциите си и да ги използвате повторно в бъдещи проекти (или дори да ги актуализирате и синхронизирате промените в проектите, които ги консумират).
1. Основа за офлайн уеб приложения
Проблемите със свързаността представляват значителна част от лошата използваемост, особено когато се гледа от мобилно устройство. Service Workers позволяват на разработчиците да създават първо офлайн изживяване в уеб приложението, което ще подобри цялостното потребителско изживяване. Има обаче множество области, които трябва да се имат предвид при разработването на офлайн първи уеб приложения.
Показване на персонализирана офлайн страница
Използването на отделна офлайн страница е обичайна стратегия за справяне с офлайн сценарии. Разработчикът може да създаде офлайн страница и да позволи на услугата да я изтегли предварително и да я добави към кеша. В случай на повреда на връзката, сервизният работник може да покаже персонализираната офлайн страница.
self.addEventListener("install", function (event) {
const offlineRequest = new Request("offline.html");
event.waitUntil(
fetch(offlineRequest).then(function (response) {
return caches.open("offline").then(function (cache) {
return cache.put(offlineRequest, response);
});
})
);
});
self.addEventListener("fetch", function (event) {
const request = event.request;
if (request.method === "GET") {
event.respondWith(
fetch(request).catch(function (error) {
return caches.open("offline").then(function (cache) {
return cache.match("offline.html");
});
})
);
}
});
В този сервизен работник, когато се инсталира, той ще извлече офлайн страницата и ще я кешира. След това, ако се опитаме да направим GET заявка и връзката вече не е налична, той ще провери кеша на браузъра и ще отговори с персонализираната офлайн страница.
Кеширайте ресурс с помощта на стратегия за кеширане и служи за заявка
Подаването на кеширано съдържание на потребителя е от съществено значение при прилагането на офлайн подход за уеб приложения. Има няколко стратегии за добавяне на ресурси към кеша.
- Stale-While-Revalidate
- Първо кеш, след това мрежова връзка
- Първо мрежова връзка, след това кеш
- Само кеш
Въпреки че стратегиите са различни, концепцията за кеширане е доста сходна. Нека да разгледаме следния фрагмент.
self.addEventListener("install", function (e) {
e.waitUntil(
caches.open("resources").then(function (cache) {
return cache.addAll([
"/",
"/index.html",
"/help.html",
"/about.html",
"/styles/main.css",
"/scripts/main.min.js",
"/assets/logo.jpg",
]);
})
);
});
self.addEventListener("fetch", function (event) {
event.respondWith(
caches.match(event.request).then(function (response) {
return response || fetch(event.request);
})
);
});
Тук, когато услугата се инсталира, тя извлича всички ресурси, необходими за функционирането на уеб приложението, като HTML страници, таблици със стилове, JavaScript и изображения. Всеки път, когато приложението се опитва да извлече обект, то ще отговори с кеширания обект, ако е наличен в кеша. В противен случай ще го донесе от сървъра за ресурси.
Използване на фоново синхронизиране с обслужващи работници
Горните два случая на употреба обясняват как можем да обслужваме кеширано съдържание. Все пак обаче не можем да считаме това за пълен жизнен цикъл офлайн, тъй като уеб приложението също трябва да изпрати всички модифицирани данни на сървъра, след като приложението стане онлайн.
Background Sync ни дава възможност да изчакаме връзката и след това да предприемем действия. Например, помислете за сценарий, при който приложението за чат трябва да извлече нови съобщения. Можем да делегираме операцията за четене на данни от сървъра към фоновата синхронизация и да я оставим да изчака връзката.
В главния файл на скрипта можем да регистрираме синхронизирането, както следва:
navigator.serviceWorker.ready.then(function (registration) {
return registration.sync.register("fetchChat");
});
В Service Worker можем да обработваме синхронизирането по следния начин:
self.addEventListener("sync", function (event) {
if (event.tag == "fetchChat") {
event.waitUntil(getChatMessagesFromServer());
}
});
2. Push известия
Push notification е друга възможност с обслужващи работници, която дава възможност за повторно ангажиране с потребителите.
С обслужващи работници можете да правите много неща с насочени известия, като например;
- Показване на просто известие за предупреждение
- Показване на богато съдържание
- Насочено известие за маркиране
- Управление на абонаменти и др
Тези възможности ще позволят набор от случаи на употреба.
3. Балансиране на натоварването от страна на клиента
Тъй като сервизният работник може да прихване извличането на заявки и да приложи алгоритъм за балансиране на натоварването.
self.onfetch = function(event) {
var request = event.request;
event.respondWith(loadBalancedFetch(request));
};
function loadBalancedFetch(request) {
// Your load balancing algorithm
}
Наличието на тази възможност на ниво браузър позволява много възможности. Един от най-добрите случаи на употреба е прилагането на A/B тестване. В горния кодов фрагмент може да се провери за извикване на API и в зависимост от вашата A/B стратегия за разделяне; можете съответно да насочвате заявки към различни версии на API.
4. Офлайн анализи
Улавянето на телеметрия, свързана с потребителите в уеб приложението, е много полезно, когато става въпрос за анализ на поведението на потребителите. Типичните аналитични рамки изискват активна връзка за изпращане на тези данни към сървър. С помощта на обслужващи работници обаче можете да улавяте поведението на потребителя от страна на клиента и да го изпращате до аналитична машина със фоново синхронизиране. Прилагането на това сами може да се окаже тромава задача. Google излезе с инструмент за поддръжка на офлайн анализи, наречен Workbox Google Analytics. Можете да прочетете повече за това, като използвате следната връзка.
5. Автоматични откази
Представете си, че имате множество сървъри за извличане на данни и един от сървърите ви започва да се проваля. Използвайки обслужващи работници, можем бързо да внедрим резервен механизъм за получаване на данни/ресурси от друг сървър. В примера по-долу можете да видите, че използваме catch блок, за да се справим с прехода при срив.
const FALLBACK_SERVER = "my.server.com";
self.addEventListener("fetch", function (event) {
event.respondWith(
fetch(event.request.url)
.then((response) => {
if (response.ok) {
return response;
} else {
throw new Error("Unable to fetch");
}
})
.catch((err) => {
return fetch(FALLBACK_SERVER);
})
);
});
Резюме
В тази статия обсъдихме възможностите и различните случаи на използване на Service Workers. Според точките за дискусия е очевидно, че Service Workers дават много власт на разработчиците да създават богати уеб приложения с отлично потребителско изживяване.
Споделяйте и управлявайте повторно използваеми JS компоненти с Bit
Използвайте Bit (Github), за да споделяте, документирате и управлявате компоненти за многократна употреба от различни проекти. Това е чудесен начин да увеличите повторното използване на кода, да ускорите разработката и да създадете приложения с мащаб.
Bit поддържа Node, TypeScript, React, Vue, Angular и др.
Свързани истории
Можете да посетите следните връзки за повече информация и мостри.
