Próbál rájönni, mi is az a szervizmunkás? Nem vagy egyedül!
A Service Worker egy olyan szkript, amely a háttérben, a böngésző felhasználói felületétől különálló szálban fut. A service worker cache lehetővé teszi, hogy egy webhely offline is működjön. Ők azok a technikai erőművek, amelyek egy weboldalt progresszív webalkalmazássá szinteznek. Mély platformintegrációt tesznek lehetővé, például gazdag gyorsítótárazást, push-értesítéseket és háttérszinkronizálást.
A szolgáltatásmunkásokat bővíthető platformnak tervezték, további funkciókat jelenleg is terveznek.
A DOM-hoz nem férnek hozzá, de minden hálózati kérést képesek elfogni. Ez lehetővé teszi a fejlesztők számára, hogy ellenőrizzék a kérések kezelését, gazdag lehetőséget biztosítva a weboldalak offline működéséhez.
A szolgáltatási munkásokat a web játékváltoztatójának nevezték. Szerintem ez nem egyszerű túlzás, mert számos nagyon szükséges képességet tesznek lehetővé, és az általam évekig használt alapvető architektúrát natívvá teszik.
A szolgáltatásmunkások elképesztően hangzanak!
Ez a kulcsfontosságú technológia vagy modern webes API a Progressive Web Applications mögött. Szervizmunkás nélkül egy weboldal csak egy weboldal, adjunk hozzá egy szervizmunkást, és máris van egy alkalmazásunk.
A szervizmunkásokkal kapcsolatban van néhány kulcsfontosságú jellemző, amit meg kell értened:
- A Service Worker egy JavaScript fájl
- A UI-tól külön szálon futnak
- Nem férnek hozzá közvetlenül a DOM-hoz
- Létezik egy életciklus vagy eseménysorozat, amin a Service Worker átfolyik, hogy aktív legyen, ezt később magyarázzuk el
- Csak addig élnek, amíg használják őket, így nem terheli az akkumulátort
- Elszigeteltek az eredethez vagy a tartományhoz, amelyhez regisztrálták őket
- A szolgáltatásmunkások HTTPS-t igényelnek
- Képesek üzeneteket küldeni a felhasználói felületre és onnan
- Nem igényelnek nyitott weboldalt a működéshez
- Minden nagyobb böngésző támogatja őket, beleértve az iOS Safarit is
- Hasonlítanak a webmunkásokhoz, de sok szempontból jobbak
- Hogyan működnek a szolgáltatásmunkások?
- Szolgálati munkások bővíthetősége
- Szolgálati munkások életciklusa
- Meddig tartanak a szervizmunkások?
- Hogyan ellenőrizhetem, hogy egy szervizmunkás regisztrálva van-e?
- Hogyan törölhetem egy Service Worker regisztrációját
- Service Worker Cache
- Hogyan frissíthetem a Service Worker Cache-t
- Mely böngészők támogatják a Service Workereket?
- Mi a különbség a Service Worker és a Web Worker között
- Mit nem tud a Service Worker
Hogyan működnek a Service Workerek?
A Service Worker a böngésző és a hálózat között helyezkedik el, proxy szerverként működik, és nem felhasználói felület központú feladatok gyűjteményét kezeli. Eseményvezéreltek, és a böngésző folyamatán kívül élnek, lehetővé téve, hogy aktív böngésző munkamenet nélkül is működjenek. A szervizmunkás egy szkript, amely a felhasználói felülettől elkülönülve, egy szálban fut. Ez lehetővé teszi a szervizmunkás számára, hogy nem felhasználói felülethez kapcsolódó feladatokat végezzen, így a webhely jobban teljesít.
A szervizmunkások megszűnnek, amikor nem használják őket, és szükség esetén újraindulnak, így nem terhelik a CPU-t és nem merítik az akkumulátorokat. Programozható hálózati proxyként vagy közvetítőként működnek a böngésző és a hálózat között, lehetővé téve a fejlesztők számára, hogy megtervezzék, hogyan kezeljék a hálózati kéréseket.
A szervizmunkások első ereje a weboldalak számára az offline képességek granuláris vezérléssel történő engedélyezése. Ez egy gazdag gyorsítótárazási API-val és az összes hálózati kérés elfogásával érhető el, mielőtt azok elhagynák a weboldalt.
A gyorsítótárazás nemcsak offline élményeket tesz lehetővé, hanem a weboldalak a gyorsítótárból való lekérdezéskor azonnal betöltődnek. A szervizmunkások gyorsítótárazása a hálózatot progresszív kiegészítéssé teszi, vagy nem szükséges ahhoz, hogy a webhely használható legyen.
Szervizmunkások bővíthetősége
A szervizmunkások egyik alábecsült tulajdonsága a bővíthetősége A szervizmunkásokat úgy tervezték, hogy a gerincet képezzék, amely támogatja a további funkciókat. A böngészőkben szállított első két funkció a natív push értesítések és a háttérben történő szinkronizálás. Jelenleg további új API-król folyik a vita, amelyeknek a közeljövőben meg kell jelenniük a böngészőkben.
A szervizmunkások saját szálban élnek, és nem férnek hozzá a DOM-hoz. Saját globális hatókörrel is rendelkeznek, amelyre a ‘self’ objektummal hivatkoznak.
Ezek is megkövetelik, hogy a webhelyet HTTPS használatával szolgálják ki. Ez a követelmény a szervizmunkások által kínált erőteljes funkciók miatt van. A HTTPS számos gyakori támadást megakadályoz. Ma már minden webhelyet HTTPS használatával kell kiszolgálni, mivel a megvalósítás előtt álló akadályok megszűntek, és minimális biztonságot nyújtanak.
Az aszinkronitásukat is biztosítják. Ez azt jelenti, hogy minden API támogatja az ígéreteket. Ez azt is jelenti, hogy bizonyos API-k és funkciók nem érhetők el a szervizmunkásokban. A legjelentősebb a localStorage. Ehelyett az adatokat az IndexedDB segítségével kell tárolni.
Service Worker életciklus
Mielőtt belemerülnénk ezekbe a nagyszerű service worker funkciókba, a fejlesztőknek meg kell érteniük az életciklust.
A service worker-t egy weboldalnak regisztrálnia kell. Mivel egyes böngészők még mindig nem támogatják a szervizmunkásokat, a szervizmunkás regisztrálása előtt el kell végezni egy funkcióellenőrzést. Ez a ‘serviceWorker’ jelenlétének ellenőrzésével történik a navigátorban.
if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(function(registration) { // Registration was successful }) .catch(function(err) { // registration failed :( }); } A szervizmunkás regisztrálásához hívja a navigator.serviceWorker.register parancsot. Adja meg a szervizmunkás elérési útvonalát. A register függvény egy ígéretet ad vissza.
Siker esetén az ígéret visszaad egy hivatkozást a szervizmunkás regisztrációs objektumára. Onnan szükség szerint elvégezhetünk bizonyos UI-feladatokat.
Szokásos Service Worker események
- install
- activate
- fetch
- push (a Safari nem támogatja)
- sync (a legtöbb böngésző még nem támogatja)
A service worker regisztrálásakor a “install” eseményt. Ebben az eseményben a leggyakrabban elvégzendő feladat az úgynevezett előzetes gyorsítótárazás.
Az előzetes gyorsítótárazás az, amikor egy oldal vagy webhely kialakításához szükséges eszközfájlok előre meghatározott listáját, és hozzáadjuk a gyorsítótárhoz, mielőtt lekérnénk őket. Ez kihasználja a szervizmunkás gyorsítótárát, hogy ezeket a válaszokat tartósan tárolja.
self.addEventListener("install", event => { event.waitUntil( caches.open(preCacheName) .then(function (cache) { return cache.addAll(precache_urls); }) ); }); A telepítési eseményt a szervizmunkás életében csak egyszer váltja ki. Az esemény nem fog újra bekövetkezni, amíg a szervizmunkás nem frissül.
A következő esemény, amely a regisztrációs életciklus részeként tüzel, az ‘activate’. Amikor egy szervizmunkás telepítésre kerül, nem válik azonnal aktívvá. A természetes sorrend az, hogy egy új szervizmunkás megvárja, amíg az összes szervizmunkás ‘kliens’ bezáródik.
A szervizmunkások azért nem veszik át azonnal az irányítást, hogy ne törjék meg a felhasználói élményt.
A skipWaiting függvény arra kényszeríti a várakozó szervizmunkást, hogy aktívvá váljon. Ezt csak akkor érdemes alkalmazni, ha biztosak vagyunk benne, hogy az új szervizmunkás nem fogja megtörni a meglévő ügyfeleket.
self.skipWaiting(); 
Amint a szervizmunkás aktívvá válik, az ‘activate’ eseményt tüzel.
self.addEventListener("activate", event => { //on activate event.waitUntil(clients.claim()); }); Ezt az eseményt általában a tisztítási vagy migrációs feladatok elvégzésére használjuk. Például a régi gyorsítótárak eltávolítására, amelyek konfliktusba kerülhetnek az új szervizmunkás gyorsítótárakkal.
Mennyi ideig működnek a szervizmunkások?
Nincs kemény szabály arra vonatkozóan, hogy a böngésző meddig tart egy szervizmunkás futását. A böngésző motorja belsőleg egy sor heurisztika segítségével határozza meg, hogy mikor fejezze be a szervizmunkás folyamatot.
Általában, ha egy weboldal nyugalmi állapotban van, a folyamat egy-két perc után leáll, esetleg már 30 másodperc után.
A valóságban a pontos idő a hardvertől, a használati szokásoktól stb. függ.
A jó hír az, hogy egy szervizmunkás bekapcsolása néhány milliszekundumot vesz igénybe. Ez olyan gyors, hogy nem igazán fogsz észrevenni semmilyen késleltetést. Szintén nem kell semmi különlegeset programoznod a szervizmunkás nélküli forgatókönyvhöz, az oldalad egyszerűen működni fog. A progresszív fejlesztés varázsa.
Hogyan ellenőrizhetem, hogy egy szervizmunkás regisztrálva van-e?
Többféleképpen is ellenőrizhetjük, hogy egy szervizmunkás regisztrálva van-e. A legegyszerűbb a serviceworkers.getRegistrations metódus meghívása.
navigator.serviceWorker.getRegistrations().then(registrations => { console.log(registrations); });Ezt a kódot hozzáadhatja az oldalak szkriptjéhez, hogy naplózza a regisztrációt a technikai támogatás vagy a fejlesztők hibakeresése céljából.
A ‘getRegistrations’ metódus az aktuális hatókör vagy weboldal alatt regisztrált összes szervizmunkás tömbjét adja vissza.
Ha csak a regisztrációt naplózza a konzolra, akkor jobb, ha a Dev Tools ‘Application’ fülön nézi meg. Ennek van egy alpanelje, amely megjeleníti az origó regisztrált szervizmunkásainak vizuális megjelenítését. Emellett háttérben szinkronizálási eseményeket indíthat és push-értesítéseket tesztelhet.
A szolgáltatásmunkást törölheti, frissítést kényszeríthet és egyéb, a fejlesztést segítő általános menedzsmentet is végezhet.
A getRegistrations valódi értéke valamiféle hátsó ajtós támogatási funkció. Mindannyian tudjuk, milyen az, amikor távolról próbálunk segíteni valakinek, és nem tudunk hozzáférni a DevToolshoz, hogy valóban elhárítsuk a problémát. Néha szükség van valamilyen vizuális támogatási oldalra vagy modálra, amely információt nyújt az alkalmazás állapotáról.
Az átlagos fogyasztó nem fogja tudni, hogyan lehet elérni a DevTools konzolpanelt. Ehelyett létrehozhat egy felhasználói felületet az alkalmazáson belül, amely visszhangozza a szervizmunkás regisztrációs objektum tulajdonságait.
Hogyan törlöm egy szervizmunkás regisztrációját
Remélhetőleg nem fog olyan forgatókönyvvel találkozni, amelyben a szervizmunkás kódja felhasználói élményt okozó hibát hozott létre. Ha mégis előfordulna, van néhány dolog, amivel eltávolíthat vagy törölhet egy szervizmunkást.
A legtöbb olyan forgatókönyv, amikor el kell távolítania egy szervizmunkást, az alkalmazás fejlesztése során történik. Ebben az esetben a DevTools segítségével eltávolíthatja vagy törölheti a szervizmunkást.
Ha egy telepített service worker eltávolítására vagy törlésére van szükség, akkor kicsit bonyolultabb a helyzet. Vannak programozási módszerek, amelyekkel kihúzhatjuk magunkat a csávából.
Az eltávolítási technikákról bővebben olvashat.
Szolgáltatómunkás gyorsítótárazása
A szolgáltatómunkás specifikáció tartalmaz natív gyorsítótárazási képességeket. Ez felváltja a hagyományos appCache-t, amely létrehozása óta sok kezelési problémát okozott. A szervizmunkás gyorsítótárazása sokkal jobban kezelhető.
A gyorsítótár API egy olyan állandósági réteget biztosít, amely hálózati válaszokat tárol, amelyeket a megfelelő kéréssel le lehet kérdezni.
A kulcs a szervizmunkás gyorsítótárazásának használatához a szervizmunkás ‘fetch’ eseménye. Ez az esemény minden egyes hálózati kérésnél kiváltódik, lehetővé téve a kérés elfogását és annak ellenőrzését, hogy a válasz gyorsítótárba került-e, mielőtt a hálózatra kerülne.
A helyi gyorsítótárban lévő eszközök elérésével lemondhatunk a drága hálózati kérésekről. Ez azt jelenti, hogy a webhely akkor is működhet, ha nincs hálózat, offline vagy gyenge hálózati kapcsolat, alacsony sáv vagy hamis mobilkapcsolat (LiFi néven ismert).
self.addEventListener("fetch", event => { event.respondWith( fetchFromCache(event) .catch(() => fetch(request) .then(response => addToCache(cacheKey, request, response)) .catch(() => offlineResponse(resourceType, opts)) ) ); }); A fenti példában a kód ellenőrzi, hogy a válasz korábban gyorsítótárazva lett-e már. Ha igen, akkor a gyorsítótárban tárolt válasz kerül visszaküldésre. Ha nem, a kérést továbbítja a hálózatnak.
Amikor a kérés visszatér, a válasz gyorsítótárba kerül és visszakerül a felhasználói felületre.
Hálózati hiba esetén a logika visszalép egy offline válaszra.
A példakódban sok mozgó alkatrész van. További részletekkel egy következő cikkben fogok szolgálni.
Hogyan frissíthetem a Service Worker gyorsítótáramat
Egy gyakori tévhit, hogy ha egyszer egy hálózati kérést gyorsítótárba helyezünk, az az örökkévalóságig tárolódik. Ez nem így van. Teljes mértékben Ön irányíthatja, hogy mikor és hogyan érvénytelenítik és frissítik a gyorsítótárat.
Ez egy nagyon összetett és bonyolult téma. Azt hiszem, személyesen körülbelül 3 tucatnyi cache-stratégiát tudok részletezni, mindegyik magában foglalja a cache érvénytelenítésének vagy frissítésének kezelését.
Az érvénytelenítés kulcsa szerintem vagy egy érvénytelenítési idő (time to live) érték, egy manifeszt vagy egy háttérben futó frissítési folyamat meghatározása. Az utóbbinál egy HEAD kéréssel megnézheted, hogy történt-e frissítés a szerveren, összehasonlítva az utolsó frissített fejléc értékét a válasz gyorsítótárba helyezésének idejével.
Nincs egyetlen válasz minden alkalmazáshoz. Meg kell terveznie a stratégiáját, és készen kell állnia a kiigazításra, ahogy látja, hogyan használják az alkalmazást.
Mely böngészők támogatják a szervizmunkásokat?
Minden modern böngésző támogatja a szervizmunkásokat, legalábbis a gyorsítótárazást. A Chrome, a FireFox és az Edge támogatja a natív push-értesítéseket, a Chrome és az Edge pedig támogatja a háttérben történő szinkronizálást.
Ez azt jelenti, hogy az alapvető PWA funkciók minden eszközön és böngészőben elérhetők. A push és a háttérszinkronizálás fejlesztések.
Elkészítettünk több olyan progresszív webes alkalmazást, amely kifinomult offline gyorsítótárazási stratégiákat igényelt, hogy az alkalmazások offline is működhessenek, még iOS-en is. Ezek az alkalmazások megkövetelik, hogy minden kérést, még a POST, PUT és DELETE műveleteket is egy várólistában gyorsítótárba helyezzük. Ezeket az alkalmazásokat még iOS-en is szinkronizáltuk, amikor a kapcsolatokról ismert volt, hogy elérhetőek.
Mi a különbség a Service Worker és a Web Worker között
A Service Worker és a Web Worker hasonló eszközök. Mindkettő a felhasználói felülettől különálló szálban hajt végre folyamatokat. Az igazi különbség a tényleges használati kontextusban rejlik.
Egyik sem fér hozzá a DOM vagy az ablakobjektumhoz. Jobbak a középszintű vagy hosszú, folyamatintenzív feladatokhoz.
A webmunkások csak akkor futnak, ha egy weblap nyitva van, és a feladatot az oldalon lévő szkript indítja el.
A service worker szintén akkor futhat, ha egy oldal nyitva van, de egy platformesemény, például egy push notification is indíthatja. Egy weboldalnak nem kell nyitva lennie ahhoz, hogy egy szervizmunkás végre tudja hajtani.
A szervizmunkások proxy-ként is működnek a hálózat és a felhasználói felület között. Oldal használata esetén (ez a leggyakoribb forgatókönyv) minden HTTPS hálózati kérés áthalad a szervizmunkáson, ahogyan azt a gyorsítótárazási szakaszban megtanulta.
A felhasználói felület és a két munkás közötti kommunikáció a postMessage metódus és az üzenet esemény segítségével történik. Ha már végeztél többszálú programozást, ez a modell nagyon ismerős lesz.
Mit nem tud a szervizmunkás
A szervizmunkások nem érhetik el az ablakobjektumot
Az ablakobjektum a felhasználói felület szálában, a szervizmunkás szálától elkülönítve fut. Ez azt jelenti, hogy a szervizmunkás nem tudja közvetlenül manipulálni a DOM elemeket. A szervizmunkás és az ablak a postMessage metóduson keresztül kommunikálhat. Ez lehetővé teszi az üzenetek oda-vissza továbbítását. Mindkét oldalon szükség lesz logikára az üzenetek feldolgozásához és a különböző munkafolyamatok elindításához.
Service Workers Require HTTPS
Miatt a Service Workerek olyan nagy hatalommal rendelkeznek, csak akkor engedélyezettek, ha az oldalt HTTPS használatával szolgálják ki. Ez biztosítja azt a biztonsági szintet, amely lehetővé teszi, hogy a szervizmunkás elvégezze azokat a dolgokat, amelyekre tervezték.
HTP-n keresztül a szervizmunkás ki lenne téve a man in the middle támadásoknak. A fejlesztők localhoston dolgozhatnak, ami megakadályozza, hogy helyi TLS-tanúsítványt telepítsünk.
Más szóval a válasz arra a kérdésre, hogy működik-e a szervizmunkás HTTP-n, nem. A webhely továbbra is renderelni fog, de a service worker nem regisztrál és nem hajtódik végre.
Kizárólag aszinkron
A service workerek aszinkronok, ami azt jelenti, hogy Promises és Promises-t használó API-kat használnak és támaszkodnak rájuk. Ez azt jelenti, hogy az olyan szinkron API-k, mint az XHR és a localStorage nem elérhetőek a szervizmunkások számára. Sose félj, használhatod a Fetch API-t (amely felváltotta az XHR-t) és az IndexedDB-t. A legtöbb olyan API, amely nem lép közvetlenül kapcsolatba az ablakobjektummal, elérhető egy service workerben.