Próbujesz dowiedzieć się, czym jest Service Worker? Nie jesteś sam!
Serwisant to skrypt, który wykonuje się w tle, w oddzielnym wątku od interfejsu użytkownika przeglądarki. Service worker cache umożliwia funkcjonowanie strony internetowej w trybie offline. Są one techniczną siłą napędową, która podnosi stronę internetową do rangi progresywnej aplikacji webowej. Umożliwiają głęboką integrację platformy, jak bogate buforowanie, powiadomienia push i synchronizację w tle.
Pracownicy usług są zaprojektowani jako rozszerzalna platforma, dodatkowe funkcje są obecnie planowane.
Nie mają dostępu do DOM, ale mogą przechwytywać wszystkie żądania sieciowe. Daje to programistom możliwość kontrolowania, w jaki sposób żądania są obsługiwane, zapewniając bogaty sposób, aby strony internetowe działały w trybie offline.
Pracownicy usług zostali nazwani zmieniaczem gry dla sieci. Nie sądzę, że jest to zwykła przesada, ponieważ umożliwiają one wiele bardzo potrzebnych możliwości i sprawiają, że podstawowa architektura, której używałem przez lata, jest natywna.
Pracownicy usług brzmią niesamowicie!
Jest to kluczowa technologia lub nowoczesne API sieciowe za Progresywnymi Aplikacjami Sieciowymi. Bez robotnika serwisowego strona internetowa jest po prostu stroną internetową, dodaj robotnika serwisowego i masz teraz aplikację.
Istnieją pewne kluczowe cechy dotyczące pracowników usług, które musisz zrozumieć:
- A Service Worker is a JavaScript File
- They execute on a separate thread from the UI
- They cannot access the DOM directly
- There is a life cycle or series of events a service worker flows through to become active, explained later
- They are only live while being used, więc nie obciążają baterii
- Są odizolowane od źródła lub domeny, w której są zarejestrowane
- Pracownicy usług wymagają HTTPS
- Mogą wysyłać wiadomości do i z UI
- Nie wymagają otwartej strony internetowej do działania
- Są obsługiwane przez wszystkie główne przeglądarki, w tym iOS Safari
- Są podobne do Web Workers, ale pod wieloma względami lepsze
- Jak działają Service Workers?
- Rozszerzalność robotów usługowych
- Cykl życia robotów usługowych
- Jak długo trwają roboty usługowe?
- Jak sprawdzić, czy robot usługowy jest zarejestrowany?
- Jak wyrejestrować Service Worker
- Buforowanie Service Worker
- Jak zaktualizować pamięć podręczną Service Worker
- Jakie przeglądarki obsługują Service Worker?
- Jaka jest różnica między robotem usługowym a robotem sieciowym
- Czego robot usługowy nie może zrobić
Jak działają roboty usługowe?
Pracownik usługowy siedzi między przeglądarką a siecią, działając jak serwer proxy, obsługując zbiór zadań niezwiązanych z interfejsem użytkownika. Są one sterowane zdarzeniami i żyją poza procesem przeglądarki, co umożliwia im pracę bez aktywnej sesji przeglądarki. Pracownik serwisowy to skrypt, który wykonuje się w wątku, oddzielnie od interfejsu użytkownika. Umożliwia to robotnikowi serwisowemu wykonywanie zadań nie związanych z UI, dzięki czemu strona internetowa działa lepiej.
Pracownicy serwisowi kończą pracę, gdy nie są używani i przywracani, gdy jest to wymagane, dzięki czemu nie obciążają procesora i nie wyczerpują baterii. Działają one jako programowalne proxy sieciowe lub pośrednik między przeglądarką a siecią, dając programistom możliwość zaprojektowania sposobu obsługi żądań sieciowych.
Pierwszą mocą, jaką pracownik serwisu wnosi do strony internetowej, jest możliwość włączenia możliwości offline z granularną kontrolą. Odbywa się to za pomocą bogatego API buforowania i przechwytywania wszystkich żądań sieciowych przed ich wyjściem.
Buforowanie nie tylko umożliwia doświadczenia offline, strony internetowe mogą ładować się natychmiast po pobraniu z pamięci podręcznej. Buforowanie robotów usługowych sprawia, że sieć staje się progresywnym ulepszeniem, lub nie jest wymagana, aby witryna była użyteczna.
Rozszerzalność robotów usługowych
Niedocenianą cechą robotów usługowych jest ich rozszerzalność Robotnicy usługowi są zaprojektowani jako szkielet, który obsługuje dodatkową funkcjonalność. Pierwsze dwie funkcje dostępne w przeglądarkach to natywne powiadomienia push i synchronizacja w tle. Więcej nowych API jest obecnie dyskutowanych i powinno zacząć pojawiać się w przeglądarkach w najbliższej przyszłości.
Pracownicy usług żyją w swoim własnym wątku i nie mają dostępu do DOM. Mają również swój własny globalny zakres, do którego odwołują się za pomocą obiektu 'self’.
Wymagają również, aby strona była obsługiwana za pomocą protokołu HTTPS. Wymóg ten wynika z potężnych funkcji, jakie oferują service workers. HTTPS zapobiega wielu powszechnym atakom. Obecnie wszystkie witryny powinny być obsługiwane przy użyciu HTTPS, ponieważ bariery do wdrożenia zostały zniesione i minimalna ilość bezpieczeństwa, które oferują.
Osoby te są również asynchroniczne. Oznacza to, że wszystkie interfejsy API obsługują obietnice. Oznacza to również, że niektóre interfejsy API i funkcje nie są dostępne w robotach usługowych. Najbardziej godnym uwagi jest localStorage. Zamiast tego dane powinny być przechowywane przy użyciu IndexedDB.
Cykl życia service worker
Przed zanurzeniem się w tych wspaniałych funkcjach service worker programiści muszą zrozumieć cykl życia.
Service worker musi być zarejestrowany przez stronę internetową. Ponieważ niektóre przeglądarki nadal nie obsługują pracowników usług, powinieneś wykonać sprawdzenie funkcji przed zarejestrowaniem pracownika usług. Odbywa się to poprzez sprawdzenie obecności 'serviceWorker’ w navigator.
if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(function(registration) { // Registration was successful }) .catch(function(err) { // registration failed :( }); } Aby zarejestrować pracownika serwisu wywołaj navigator.serviceWorker.register. Przekaż ścieżkę do pracownika serwisowego. Funkcja register zwraca obietnicę.
Jeżeli obietnica się powiedzie, zwraca ona odniesienie do obiektu rejestracji pracownika serwisowego. Stamtąd można wykonywać określone zadania UI w zależności od potrzeb.
Standardowe zdarzenia pracownika serwisowego
- install
- activate
- fetch
- push (nieobsługiwany przez Safari)
- sync (nieobsługiwany przez większość przeglądarek jeszcze)
Gdy pracownik serwisowy jest zarejestrowany, zdarzenie „install”. W tym zdarzeniu najczęstszym zadaniem do wykonania jest tzw. buforowanie wstępne.
Buforowanie wstępne to miejsce, w którym wstępnie zdefiniowana lista plików aktywów potrzebnych do utworzenia strony lub witryny, i dodanie ich do pamięci podręcznej przed ich zażądaniem. Wykorzystuje to pamięć podręczną pracownika serwisu do utrzymywania tych odpowiedzi.
self.addEventListener("install", event => { event.waitUntil( caches.open(preCacheName) .then(function (cache) { return cache.addAll(precache_urls); }) ); }); Zdarzenie instalacji jest wyzwalane tylko raz w czasie życia pracownika serwisu. Zdarzenie to nie zostanie uruchomione ponownie, dopóki pracownik serwisu nie zostanie zaktualizowany.
Następnym zdarzeniem, które uruchamia się w ramach cyklu życia rejestracji, jest „activate”. Po zainstalowaniu pracownika serwisu nie staje się on od razu aktywny. Naturalną sekwencją jest czekanie przez nowego pracownika serwisu, aż wszyscy 'klienci’ pracownika serwisu zostaną zamknięci.
Powodem, dla którego pracownicy serwisu nie są projektowani tak, aby natychmiast przejmować kontrolę, jest to, aby nie łamali doświadczenia użytkownika.
Funkcja skipWaiting zmusza oczekującego pracownika serwisu do aktywności. Powinno to być stosowane tylko wtedy, gdy jesteś pewien, że nowy pracownik serwisu nie złamie żadnych istniejących klientów.
self.skipWaiting(); 
Gdy pracownik serwisu stanie się aktywny, wystrzeliwane jest zdarzenie 'activate’.
self.addEventListener("activate", event => { //on activate event.waitUntil(clients.claim()); }); To zdarzenie jest powszechnie używane do wykonywania zadań czyszczenia lub migracji. Na przykład, usuwanie starszych pamięci podręcznych, które mogą być w konflikcie z nowymi pamięciami podręcznymi pracownika usług.
How Long to Service Workers Last?
Nie ma sztywnej reguły, jak długo przeglądarka utrzymuje pracownika usług działającego. Wewnętrznie silnik przeglądarki użyje zestawu heurystyk, aby określić kiedy zakończyć proces pracownika serwisowego.
Ogólnie, jeśli strona jest uśpiona, proces zakończy się po minucie lub dwóch, może nawet po 30 sekundach.
W rzeczywistości dokładny czas zależy od sprzętu, wzorców użytkowania, itp.
Dobrą wiadomością jest to, że włączenie pracownika serwisu zajmuje garść milisekund. Jest to tak szybkie, że wont naprawdę zauważysz jakiekolwiek opóźnienie. Nie musisz również programować niczego specjalnego, aby poradzić sobie ze scenariuszem bez pracownika serwisowego, twoja strona będzie po prostu działać. Magia progresywnego ulepszania.
Jak sprawdzić, czy pracownik serwisu jest zarejestrowany?
Istnieje wiele sposobów na sprawdzenie, czy pracownik serwisu jest zarejestrowany. Najprostszym z nich jest wywołanie metody serviceworkers.getRegistrations.
navigator.serviceWorker.getRegistrations().then(registrations => { console.log(registrations); });Jest to kod, który możesz dodać do skryptu strony, aby rejestrować rejestrację dla pomocy technicznej lub debugowania programisty.
Metoda 'getRegistrations’ zwraca tablicę wszystkich pracowników serwisu zarejestrowanych w bieżącym zakresie lub witrynie.
Jeśli po prostu logujesz rejestrację do konsoli, lepiej będzie, jeśli przejrzysz zakładkę 'Application’ w Dev Tools. Posiada ona pod-panel, który wyświetla wizualizację zarejestrowanego pracownika serwisowego pochodzenia. Możesz również wyzwalać zdarzenia synchronizacji w tle i testować powiadomienia push.
Możesz również usunąć pracownika serwisu, wymusić aktualizację i inne ogólne zarządzanie, które pomaga w rozwoju.
Prawdziwa wartość getRegistrations oferuje jest dla pewnego rodzaju funkcji wsparcia back-door. Wszyscy wiemy, jak to jest, gdy próbujesz pomóc komuś zdalnie i nie masz dostępu do narzędzi DevTools, aby naprawdę rozwiązać problem. Czasami będziesz chciał jakiegoś rodzaju wizualnej strony wsparcia lub modalnej, aby zapewnić informacje o stanie aplikacji.
Przeciętny konsument nie będzie wiedział, jak uzyskać dostęp do panelu konsoli DevTools. Zamiast tego możesz utworzyć interfejs użytkownika w aplikacji, aby uzyskać echo właściwości obiektu rejestracji pracownika serwisowego.
How do I Unregister a Service Worker
Miejmy nadzieję, że nie napotkasz scenariusza, w którym twój kod pracownika serwisowego stworzył błąd doświadczenia użytkownika. W przypadku, gdy to zrobisz, jest kilka rzeczy, które możesz zrobić, aby usunąć lub wyrejestrować pracownika serwisu.
Większość scenariuszy, w których musisz usunąć pracownika serwisu, będzie miała miejsce podczas tworzenia aplikacji. W tym przypadku możesz użyć DevTools, aby usunąć lub wyrejestrować pracownika serwisu.
Jeśli musisz usunąć lub usunąć wdrożonego pracownika serwisu, staje się to nieco bardziej skomplikowane. Istnieją programistyczne sposoby, które pozwolą ci wydostać się z zakleszczenia.
Czytaj więcej o technikach usuwania.
Buforowanie pracownika serwisu
Specyfikacja pracownika serwisu zawiera natywne możliwości buforowania. Zastępuje to tradycyjny appCache, który spowodował wiele problemów z zarządzaniem od czasu jego powstania. Buforowanie pracownika usługowego jest znacznie łatwiejsze do zarządzania.
Podręczny interfejs API zapewnia warstwę trwałości, która przechowuje odpowiedzi sieciowe, które mogą być odpytywane przez pasujące żądanie.
Kluczem do korzystania z buforowania pracownika usługowego jest zdarzenie 'fetch’ pracownika usługowego. To zdarzenie uruchamia się dla każdego żądania sieciowego pozwalając ci przechwycić żądanie i sprawdzić czy odpowiedź została zbuforowana zanim trafi do sieci.
Dzięki dostępowi do zasobów w lokalnej pamięci podręcznej możesz zrezygnować z kosztownych żądań sieciowych. Oznacza to, że witryna może działać, gdy nie ma sieci, offline, lub słaba łączność sieciowa, niskie bary lub fałszywe połączenie komórkowe (znane jako LiFi).
self.addEventListener("fetch", event => { event.respondWith( fetchFromCache(event) .catch(() => fetch(request) .then(response => addToCache(cacheKey, request, response)) .catch(() => offlineResponse(resourceType, opts)) ) ); }); W powyższym przykładzie kod sprawdza, czy odpowiedź została wcześniej zbuforowana. Jeśli tak, odpowiedź z bufora jest zwracana. Jeśli nie, żądanie jest przekazywane do sieci.
Gdy żądanie wraca, odpowiedź jest buforowana i zwracana do UI.
Jeśli sieć zawiedzie, logika wraca do odpowiedzi offline.
W przykładowym kodzie jest wiele ruchomych części. Dostarczę więcej szczegółów w kolejnych artykułach.
How do I Update My Service Worker Cache
Powszechne błędne przekonanie jest takie, że gdy buforujesz żądanie sieciowe, jest ono przechowywane przez wieczność. To nie jest prawda. Masz pełną kontrolę nad tym kiedy i jak pamięć podręczna jest unieważniana i aktualizowana.
To jest bardzo złożony i zaangażowany temat. Myślę, że osobiście mogę wyszczególnić około 3 tuziny strategii buforowania, wszystkie obejmują sposób zarządzania unieważnianiem pamięci podręcznej lub aktualizacją pamięci podręcznej.
Myślę, że kluczem do unieważnienia jest określenie wartości czasu do unieważnienia (czas życia), manifestu lub procesu aktualizacji w tle. W późniejszym przypadku możesz wykonać żądanie HEAD, aby sprawdzić, czy aktualizacja została wykonana na serwerze poprzez porównanie ostatnio zaktualizowanej wartości nagłówka z czasem, w którym odpowiedź została zbuforowana.
Nie ma jednej odpowiedzi dla każdej aplikacji. Będziesz musiał zaplanować swoją strategię i być przygotowanym na dostosowanie się, gdy zobaczysz jak twoja aplikacja jest używana.
Jakie przeglądarki obsługują Service Workers?
Wszystkie nowoczesne przeglądarki obsługują Service Workers, przynajmniej buforowanie. Chrome, FireFox i Edge obsługują natywne powiadomienia push, a Chrome i Edge mają obsługę synchronizacji w tle.
To oznacza, że podstawowe funkcje PWA są dostępne we wszystkich urządzeniach i przeglądarkach. Push i synchronizacja w tle to ulepszenia.
Zbudowaliśmy kilka aplikacji Progressive Web Apps, które wymagały wyrafinowanych strategii buforowania offline, aby umożliwić aplikacjom pracę w trybie offline, nawet na iOS. Te aplikacje wymagają, aby wszystkie żądania, nawet akcje POST, PUT i DELETE były buforowane w kolejce. Sprawiliśmy, że te aplikacje synchronizują się nawet na iOS, gdy wiadomo, że połączenia są dostępne.
Jaka jest różnica między robotnikiem serwisowym a robotnikiem sieciowym
Pracownicy serwisowi i robotnicy sieciowi są podobnymi narzędziami. Oba wykonują procesy w oddzielnym wątku od interfejsu użytkownika. Prawdziwa różnica leży w rzeczywistym kontekście użycia.
Nie mają dostępu do DOM lub obiektu okna. Są one lepsze dla warstwy średniej lub długich, intensywnych zadań.
Web workers działają tylko wtedy, gdy strona internetowa jest otwarta, a zadanie jest wyzwalane ze skryptu na stronie.
Service worker może również wykonywać się, gdy strona jest otwarta, ale może być również wyzwalany przez zdarzenie platformy, takie jak powiadomienie push. Strona internetowa nie musi być otwarta, aby pracownik serwisowy mógł się wykonać.
Pracownicy serwisowi działają również jako proxy pomiędzy siecią a interfejsem użytkownika. Jeśli używana jest strona (najczęstszy scenariusz), wszystkie żądania sieciowe HTTPS przechodzą przez pracownika serwisowego, jak dowiedziałeś się w sekcji caching.
Komunikacja między UI a oboma pracownikami odbywa się za pomocą metody postMessage i zdarzenia message. Jeśli zajmowałeś się programowaniem wielowątkowym, ten model jest bardzo znajomy.
Czego robotnik serwisowy nie może zrobić
Pracownicy serwisowi nie mogą uzyskać dostępu do obiektu Window
Obiekt Window wykonuje się w wątku UI, oddzielnie od wątku robotnika serwisowego. Oznacza to, że pracownik serwisowy nie może bezpośrednio manipulować elementami DOM. Pracownik serwisowy i okno mogą komunikować się za pomocą metody postMessage. Pozwala to na przekazywanie wiadomości tam i z powrotem. Będziesz musiał mieć logikę po każdej stronie, aby przetwarzać wiadomości i wyzwalać różne przepływy pracy.
Pracownicy serwisowi wymagają HTTPS
Ponieważ pracownicy serwisowi mają tak wiele możliwości, są one włączone tylko wtedy, gdy strona jest obsługiwana przy użyciu HTTPS. Zapewnia to poziom bezpieczeństwa, aby umożliwić robotowi serwisowemu robienie rzeczy, do których został zaprojektowany.
Poza HTTP robotnik serwisowy byłby podatny na ataki typu „człowiek w środku”. Programiści mogą pracować na localhost, co powstrzymuje nas od instalowania lokalnego certyfikatu TLS.
Innymi słowy odpowiedź na pytanie, czy pracownik serwisu działa na HTTP brzmi nie. Strona nadal będzie renderować, ale pracownik serwisowy nie rejestruje się i nie jest wykonywany.
Jest tylko asynchroniczny
Pracownicy serwisowi są asynchroniczni, co oznacza, że używają i polegają na obietnicach i API, które używają obietnic. Oznacza to, że synchroniczne API, takie jak XHR i localStorage nie są dostępne dla pracownika serwisowego. Bez obaw, możesz korzystać z API Fetch (które zastąpiło XHR) oraz IndexedDB. Większość interfejsów API, które nie wchodzą w bezpośrednią interakcję z obiektem okna, jest dostępna w robotniku usługowym.