Avanserte strategier for Service Workers: Mellomlagring og bakgrunnssynkronisering

Service Workers er en kraftig teknologi som gjør det mulig for utviklere å bygge Progressive Web Apps (PWA) med forbedret ytelse, frakoblet funksjonalitet og en bedre brukeropplevelse. De fungerer som en proxy mellom nettapplikasjonen og nettverket, og lar utviklere avskjære nettverksforespørsler og svare med mellomlagrede ressurser eller starte bakgrunnsoppgaver. Denne artikkelen dykker ned i avanserte strategier for Service Worker-mellomlagring og bakgrunnssynkronisering, og gir praktiske eksempler og beste praksis for å bygge robuste og motstandsdyktige nettapplikasjoner for et globalt publikum.

Forståelse av Service Workers

En Service Worker er en JavaScript-fil som kjører i bakgrunnen, atskilt fra nettleserens hovedtråd. Den kan avskjære nettverksforespørsler, mellomlagre ressurser og sende push-varsler, selv når brukeren ikke aktivt bruker nettapplikasjonen. Dette gir raskere lastetider, frakoblet tilgang til innhold og en mer engasjerende brukeropplevelse.

Nøkkelfunksjoner i Service Workers inkluderer:

• Mellomlagring: Lagre ressurser lokalt for å forbedre ytelsen og muliggjøre frakoblet tilgang.
• Bakgrunnssynkronisering: Utsette oppgaver som skal utføres når enheten har nettverkstilkobling.
• Push-varsler: Engasjere brukere med tidsriktige oppdateringer og varsler.
• Avskjæring av nettverksforespørsler: Kontrollere hvordan nettverksforespørsler håndteres.

Avanserte mellomlagringsstrategier

Å velge riktig mellomlagringsstrategi er avgjørende for å optimalisere ytelsen til nettapplikasjonen og sikre en sømløs brukeropplevelse. Her er noen avanserte mellomlagringsstrategier å vurdere:

1. Cache-først (Cache-First)

Cache-First-strategien prioriterer å servere innhold fra mellomlageret når det er mulig. Denne tilnærmingen er ideell for statiske ressurser som bilder, CSS-filer og JavaScript-filer som sjelden endres.

Slik fungerer det:

1. Service Worker avskjærer nettverksforespørselen.
2. Den sjekker om den forespurte ressursen er tilgjengelig i mellomlageret.
3. Hvis den finnes, blir ressursen servert direkte fra mellomlageret.
4. Hvis den ikke finnes, blir forespørselen sendt til nettverket, og svaret blir mellomlagret for fremtidig bruk.

Eksempel:

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // Treff i cache - returner respons
        if (response) {
          return response;
        }

        // Ikke i cache - returner fetch
        return fetch(event.request).then(
          function(response) {
            // Sjekk om vi mottok en gyldig respons
            if(!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // VIKTIG: Klon responsen. En respons er en strøm
            // og fordi vi vil at både nettleseren og cachen skal konsumere
            // responsen, må vi klone den slik at vi har to strømmer.
            var responseToCache = response.clone();

            caches.open(CACHE_NAME)
              .then(function(cache) {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
    );
});

            

              
                Copy
              
            
          

2. Nettverk-først (Network-First)

Network-First-strategien prioriterer å hente innhold fra nettverket når det er mulig. Hvis nettverksforespørselen mislykkes, faller Service Worker tilbake på mellomlageret. Denne strategien passer for innhold som oppdateres ofte, der ferskhet er avgjørende.

Slik fungerer det:

1. Service Worker avskjærer nettverksforespørselen.
2. Den prøver å hente ressursen fra nettverket.
3. Hvis nettverksforespørselen er vellykket, blir ressursen servert og mellomlagret.
4. Hvis nettverksforespørselen mislykkes (f.eks. på grunn av en nettverksfeil), sjekker Service Worker mellomlageret.
5. Hvis ressursen finnes i mellomlageret, blir den servert.
6. Hvis ressursen ikke finnes i mellomlageret, vises en feilmelding (eller et reservesvar gis).

Eksempel:

            self.addEventListener('fetch', event => {
  event.respondWith(
    fetch(event.request)
      .then(response => {
        // Sjekk om vi mottok en gyldig respons
        if(!response || response.status !== 200 || response.type !== 'basic') {
          return response;
        }

        // VIKTIG: Klon responsen. En respons er en strøm
        // og fordi vi vil at både nettleseren og cachen skal konsumere
        // responsen, må vi klone den slik at vi har to strømmer.
        var responseToCache = response.clone();

        caches.open(CACHE_NAME)
          .then(function(cache) {
            cache.put(event.request, responseToCache);
          });

        return response;
      })
      .catch(err => {
        // Nettverksforespørsel mislyktes, prøv å hente den fra cachen.
        return caches.match(event.request);
      })
  );
});

            

              
                Copy
              
            
          

3. Gammel-mens-revalidering (Stale-While-Revalidate)

Stale-While-Revalidate-strategien returnerer mellomlagret innhold umiddelbart, samtidig som den henter den nyeste versjonen fra nettverket. Dette gir en rask innledende lasting med fordelen av å oppdatere mellomlageret i bakgrunnen.

Slik fungerer det:

1. Service Worker avskjærer nettverksforespørselen.
2. Den returnerer umiddelbart den mellomlagrede versjonen av ressursen (hvis tilgjengelig).
3. I bakgrunnen henter den den nyeste versjonen av ressursen fra nettverket.
4. Når nettverksforespørselen er vellykket, oppdateres mellomlageret med den nye versjonen.

Eksempel:

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(cachedResponse => {
        // Selv om responsen er i cachen, henter vi den fra nettverket
        // og oppdaterer cachen i bakgrunnen.
        var fetchPromise = fetch(event.request).then(
          networkResponse => {
            caches.open(CACHE_NAME).then(cache => {
              cache.put(event.request, networkResponse.clone());
              return networkResponse;
            });
          })
        // Returner den mellomlagrede responsen hvis vi har den, ellers returner nettverksresponsen
        return cachedResponse || fetchPromise;
      })
  );
});

            

              
                Copy
              
            
          

4. Cache, deretter nettverk (Cache, then Network)

Cache, then Network-strategien prøver først å servere innhold fra mellomlageret. Samtidig henter den den nyeste versjonen fra nettverket og oppdaterer mellomlageret. Denne strategien er nyttig for å vise innhold raskt, samtidig som man sikrer at brukeren til slutt mottar den mest oppdaterte informasjonen. Den ligner på Stale-While-Revalidate, men sikrer at nettverksforespørselen *alltid* blir gjort og mellomlageret oppdatert, i stedet for bare ved et cache-miss.

Slik fungerer det:

1. Service Worker avskjærer nettverksforespørselen.
2. Den returnerer umiddelbart den mellomlagrede versjonen av ressursen (hvis tilgjengelig).
3. Den henter alltid den nyeste versjonen av ressursen fra nettverket.
4. Når nettverksforespørselen er vellykket, oppdateres mellomlageret med den nye versjonen.

Eksempel:

            self.addEventListener('fetch', event => {
  // Svar først med det som allerede er i cachen
  event.respondWith(caches.match(event.request));

  // Oppdater deretter cachen med nettverksresponsen. Dette vil utløse en
  // ny 'fetch'-hendelse, som igjen vil svare med den mellomlagrede verdien
  // (umiddelbart) mens cachen oppdateres i bakgrunnen.
  event.waitUntil(
    fetch(event.request).then(response =>
      caches.open(CACHE_NAME).then(cache => cache.put(event.request, response))
    )
  );
});

            

              
                Copy
              
            
          

5. Kun nettverk (Network Only)

Denne strategien tvinger Service Worker til alltid å hente ressursen fra nettverket. Hvis nettverket er utilgjengelig, vil forespørselen mislykkes. Dette er nyttig for ressurser som er svært dynamiske og alltid må være oppdaterte, som sanntids-datafeeder.

Slik fungerer det:

1. Service Worker avskjærer nettverksforespørselen.
2. Den prøver å hente ressursen fra nettverket.
3. Hvis vellykket, blir ressursen servert.
4. Hvis nettverksforespørselen mislykkes, kastes en feil.

Eksempel:

            self.addEventListener('fetch', event => {
  event.respondWith(fetch(event.request));
});

            

              
                Copy
              
            
          

6. Kun cache (Cache Only)

Denne strategien tvinger Service Worker til alltid å hente ressursen fra mellomlageret. Hvis ressursen ikke er tilgjengelig i mellomlageret, vil forespørselen mislykkes. Dette passer for ressurser som er eksplisitt mellomlagret og aldri skal hentes fra nettverket, som for eksempel offline reservesider.

Slik fungerer det:

1. Service Worker avskjærer nettverksforespørselen.
2. Den sjekker om ressursen er tilgjengelig i mellomlageret.
3. Hvis den finnes, blir ressursen servert direkte fra mellomlageret.
4. Hvis den ikke finnes, kastes en feil.

Eksempel:

            self.addEventListener('fetch', event => {
  event.respondWith(caches.match(event.request));
});

            

              
                Copy
              
            
          

7. Dynamisk mellomlagring

Dynamisk mellomlagring innebærer å mellomlagre ressurser som ikke er kjent på installasjonstidspunktet for Service Worker. Dette er spesielt nyttig for å mellomlagre API-svar og annet dynamisk innhold. Du kan bruke fetch-hendelsen til å avskjære nettverksforespørsler og mellomlagre svarene etter hvert som de mottas.

Eksempel:

            self.addEventListener('fetch', event => {
  if (event.request.url.startsWith('https://api.example.com/')) {
    event.respondWith(
      caches.open('dynamic-cache').then(cache => {
        return fetch(event.request).then(response => {
          cache.put(event.request, response.clone());
          return response;
        });
      })
    );
  }
});

            

              
                Copy
              
            
          

Bakgrunnssynkronisering

Bakgrunnssynkronisering lar deg utsette oppgaver som krever nettverkstilkobling til enheten har en stabil forbindelse. Dette er spesielt nyttig for scenarioer der brukere kan være frakoblet eller ha ustabil tilkobling, som ved innsending av skjemaer, sending av meldinger eller oppdatering av data. Dette forbedrer brukeropplevelsen dramatisk i områder med upålitelige nettverk (f.eks. landlige områder i utviklingsland).

Registrering for bakgrunnssynkronisering

For å bruke bakgrunnssynkronisering, må du registrere din Service Worker for `sync`-hendelsen. Dette kan gjøres i koden til nettapplikasjonen din:

            navigator.serviceWorker.ready.then(function(swRegistration) {
  return swRegistration.sync.register('my-background-sync');
});

            

              
                Copy
              
            
          

Her er `'my-background-sync'` en tag som identifiserer den spesifikke synkroniseringshendelsen. Du kan bruke forskjellige tagger for ulike typer bakgrunnsoppgaver.

Håndtering av synkroniseringshendelsen

I din Service Worker må du lytte etter `sync`-hendelsen og håndtere bakgrunnsoppgaven. For eksempel:

            self.addEventListener('sync', event => {
  if (event.tag === 'my-background-sync') {
    event.waitUntil(
      doSomeBackgroundTask()
    );
  }
});

            

              
                Copy
              
            
          

`event.waitUntil()`-metoden forteller nettleseren at den skal holde Service Worker i live til løftet (promise) er oppfylt. Dette sikrer at bakgrunnsoppgaven blir fullført selv om brukeren lukker nettapplikasjonen.

Eksempel: Sende inn et skjema i bakgrunnen

La oss se på et eksempel der en bruker sender inn et skjema mens han er frakoblet. Skjemadataene kan lagres lokalt, og innsendingen kan utsettes til enheten har nettverkstilkobling.

1. Lagre skjemadataene:

Når brukeren sender inn skjemaet, lagre dataene i IndexedDB:

            function submitForm(formData) {
  // Lagre skjemadataene i IndexedDB
  openDatabase().then(db => {
    const tx = db.transaction('submissions', 'readwrite');
    const store = tx.objectStore('submissions');
    store.add(formData);
    return tx.done;
  }).then(() => {
    // Registrer for bakgrunnssynkronisering
    return navigator.serviceWorker.ready;
  }).then(swRegistration => {
    return swRegistration.sync.register('form-submission');
  });
}

            

              
                Copy
              
            
          

2. Håndtere synkroniseringshendelsen:

I Service Worker, lytt etter `sync`-hendelsen og send skjemadataene til serveren:

            self.addEventListener('sync', event => {
  if (event.tag === 'form-submission') {
    event.waitUntil(
      openDatabase().then(db => {
        const tx = db.transaction('submissions', 'readwrite');
        const store = tx.objectStore('submissions');
        return store.getAll();
      }).then(submissions => {
        // Send hvert skjemadata til serveren
        return Promise.all(submissions.map(formData => {
          return fetch('/submit-form', {
            method: 'POST',
            body: JSON.stringify(formData),
            headers: {
              'Content-Type': 'application/json'
            }
          }).then(response => {
            if (response.ok) {
              // Fjern skjemadataene fra IndexedDB
              return openDatabase().then(db => {
                const tx = db.transaction('submissions', 'readwrite');
                const store = tx.objectStore('submissions');
                store.delete(formData.id);
                return tx.done;
              });
            }
            throw new Error('Failed to submit form');
          });
        }));
      }).catch(error => {
        console.error('Failed to submit forms:', error);
      })
    );
  }
});

            

              
                Copy
              
            
          

Beste praksis for implementering av Service Worker

For å sikre en vellykket implementering av Service Worker, bør du vurdere følgende beste praksis:

• Hold Service Worker-skriptet enkelt: Unngå kompleks logikk i Service Worker-skriptet for å minimere feil og sikre optimal ytelse.
• Test grundig: Test implementeringen av Service Worker i ulike nettlesere og under forskjellige nettverksforhold for å identifisere og løse potensielle problemer. Bruk nettleserens utviklerverktøy (f.eks. Chrome DevTools) for å inspisere oppførselen til Service Worker.
• Håndter feil elegant: Implementer feilhåndtering for å elegant håndtere nettverksfeil, cache-miss og andre uventede situasjoner. Gi informative feilmeldinger til brukeren.
• Bruk versjonering: Implementer versjonering for din Service Worker for å sikre at oppdateringer blir brukt korrekt. Øk cachenavnet eller filnavnet til Service Worker når du gjør endringer.
• Overvåk ytelsen: Overvåk ytelsen til implementeringen av Service Worker for å identifisere områder for forbedring. Bruk verktøy som Lighthouse for å måle ytelsesmetrikker.
• Vurder sikkerhet: Service Workers kjører i en sikker kontekst (HTTPS). Distribuer alltid nettapplikasjonen din over HTTPS for å beskytte brukerdata og forhindre man-in-the-middle-angrep.
• Tilby reserveinnhold: Implementer reserveinnhold for frakoblede scenarioer for å gi en grunnleggende brukeropplevelse selv når enheten ikke er koblet til nettverket.

Eksempler på globale applikasjoner som bruker Service Workers

• Google Maps Go: Denne lettvektsversjonen av Google Maps bruker Service Workers for å gi frakoblet tilgang til kart og navigasjon, noe som er spesielt nyttig i områder med begrenset tilkobling.
• Starbucks PWA: Starbucks' Progressive Web App lar brukere bla gjennom menyen, legge inn bestillinger og administrere kontoene sine selv når de er frakoblet. Dette forbedrer brukeropplevelsen i områder med dårlig mobildekning eller Wi-Fi.
• Twitter Lite: Twitter Lite bruker Service Workers til å mellomlagre tweets og bilder, noe som reduserer databruk og forbedrer ytelsen på trege nettverk. Dette er spesielt verdifullt for brukere i utviklingsland med dyre dataabonnementer.
• AliExpress PWA: AliExpress PWA utnytter Service Workers for raskere lastetider og frakoblet surfing av produktkataloger, noe som forbedrer handleopplevelsen for brukere over hele verden.

Konklusjon

Service Workers er et kraftig verktøy for å bygge moderne nettapplikasjoner med forbedret ytelse, frakoblet funksjonalitet og en bedre brukeropplevelse. Ved å forstå og implementere avanserte mellomlagringsstrategier og teknikker for bakgrunnssynkronisering, kan utviklere skape robuste og motstandsdyktige applikasjoner som fungerer sømløst under ulike nettverksforhold og på forskjellige enheter, og dermed skape en bedre opplevelse for alle brukere, uavhengig av deres plassering eller nettverkskvalitet. Etter hvert som webteknologier fortsetter å utvikle seg, vil Service Workers spille en stadig viktigere rolle i å forme fremtiden for nettet.