Frontend Web Lock API: Primitiver for Ressurssynkronisering

Moderne webapplikasjoner blir stadig mer komplekse, og opererer ofte på tvers av flere faner eller vinduer. Dette introduserer utfordringen med å håndtere samtidig tilgang til delte ressurser, som data lagret i localStorage, IndexedDB, eller til og med server-side ressurser som aksesseres via API-er. Web Lock API gir en standardisert mekanisme for å koordinere tilgang til disse ressursene, forhindre datakorrupsjon og sikre datakonsistens.

Forstå Behovet for Ressurssynkronisering

Se for deg et scenario der en bruker har webapplikasjonen din åpen i to forskjellige faner. Begge fanene prøver å oppdatere den samme posten i localStorage. Uten skikkelig synkronisering kan den ene fanens endringer overskrive den andres, noe som fører til datatap eller inkonsistens. Det er her Web Lock API kommer inn.

Tradisjonell webutvikling baserer seg på teknikker som optimistisk låsing (sjekker for endringer før lagring) eller server-side låsing. Disse tilnærmingene kan imidlertid være komplekse å implementere og passer ikke nødvendigvis i alle situasjoner. Web Lock API tilbyr en enklere, mer direkte måte å håndtere samtidig tilgang fra frontend.

Introduksjon til Web Lock API

Web Lock API er et nettleser-API som lar webapplikasjoner anskaffe og frigi låser på ressurser. Disse låsene holdes i nettleseren og kan avgrenses til et spesifikt opphav (origin), noe som sikrer at de ikke forstyrrer andre nettsteder. API-et tilbyr to hovedtyper låser: eksklusive låser og delte låser.

Eksklusive Låser

En eksklusiv lås gir eksklusiv tilgang til en ressurs. Bare én fane eller ett vindu kan holde en eksklusiv lås på et gitt navn om gangen. Dette egner seg for operasjoner som modifiserer ressursen, som å skrive data til localStorage eller oppdatere en database på serversiden.

Delte Låser

En delt lås lar flere faner eller vinduer holde en lås på en ressurs samtidig. Dette passer for operasjoner som kun leser ressursen, for eksempel å vise data til brukeren. Delte låser kan holdes samtidig av flere klienter, men en eksklusiv lås vil blokkere alle delte låser, og omvendt.

Bruk av Web Lock API: En Praktisk Guide

Web Lock API aksesseres gjennom navigator.locks-egenskapen. Denne egenskapen gir tilgang til request()- og query()-metodene.

Forespørsel om Lås

request()-metoden brukes til å be om en lås. Den tar navnet på låsen, et valgfritt opsjonsobjekt, og en tilbakekallingsfunksjon (callback). Tilbakekallingsfunksjonen utføres kun etter at låsen er blitt anskaffet. Opsjonsobjektet kan spesifisere låsemodus ('exclusive' eller 'shared') og et valgfritt ifAvailable-flagg.

Her er et grunnleggende eksempel på å be om en eksklusiv lås:

            navigator.locks.request('my-resource', { mode: 'exclusive' }, async lock => {
  try {
    // Utfør operasjoner som krever eksklusiv tilgang til ressursen
    console.log('Lås anskaffet!');

    // Simuler en asynkron operasjon
    await new Promise(resolve => setTimeout(resolve, 2000));

    console.log('Frigir låsen.');
  } finally {
    // Låsen frigis automatisk når tilbakekallingsfunksjonen returnerer eller kaster en feil
    // Men du kan også frigi den manuelt (selv om det generelt ikke er nødvendig).
    // lock.release();
  }
});

            

              
                Copy
              
            
          

I dette eksempelet prøver request()-metoden å anskaffe en eksklusiv lås med navnet 'my-resource'. Hvis låsen er tilgjengelig, utføres tilbakekallingsfunksjonen. Inne i tilbakekallingen kan du utføre operasjoner som krever eksklusiv tilgang til ressursen. Låsen frigis automatisk når tilbakekallingsfunksjonen returnerer eller kaster en feil. finally-blokken sikrer at eventuell oppryddingskode blir kjørt, selv om det oppstår en feil.

Her er et eksempel som bruker `ifAvailable`-opsjonen:

            navigator.locks.request('my-resource', { mode: 'exclusive', ifAvailable: true }, lock => {
  if (lock) {
    console.log('Lås anskaffet umiddelbart!');
    // Utfør operasjoner med låsen

  } else {
    console.log('Lås ikke umiddelbart tilgjengelig, gjør noe annet.');
    // Utfør alternative operasjoner
  }
}).catch(error => {
  console.error('Feil ved forespørsel om lås:', error);
});

            

              
                Copy
              
            
          

Hvis `ifAvailable` er satt til `true`, vil `request`-promiset løses umiddelbart med låsobjektet hvis låsen er tilgjengelig. Hvis låsen ikke er tilgjengelig, løses promiset med `undefined`. Tilbakekallingsfunksjonen utføres uavhengig av om en lås ble anskaffet, slik at du kan håndtere begge tilfellene. Det er viktig å merke seg at låsobjektet som sendes til tilbakekallingsfunksjonen er `null` eller `undefined` når låsen er utilgjengelig.

Å be om en delt lås er lignende:

            navigator.locks.request('my-resource', { mode: 'shared' }, async lock => {
  try {
    // Utfør leseoperasjoner på ressursen
    console.log('Delt lås anskaffet!');

    // Simuler en asynkron leseoperasjon
    await new Promise(resolve => setTimeout(resolve, 1000));

    console.log('Frigir den delte låsen.');
  } finally {
    // Låsen frigis automatisk
  }
});

            

              
                Copy
              
            
          

Sjekke Låsestatus

query()-metoden lar deg sjekke den nåværende statusen til låser. Den returnerer et promise som løses med et objekt som inneholder informasjon om de aktive låsene for det nåværende opphavet.

            navigator.locks.query().then(lockInfo => {
  console.log('Låsinformasjon:', lockInfo);

  if (lockInfo.held) {
    console.log('Låser holdes for øyeblikket:');
    lockInfo.held.forEach(lock => {
      console.log(`  Navn: ${lock.name}, Modus: ${lock.mode}`);
    });
  } else {
    console.log('Ingen låser holdes for øyeblikket.');
  }

  if (lockInfo.pending) {
      console.log('Ventende låseforespørsler:');
      lockInfo.pending.forEach(request => {
          console.log(` Navn: ${request.name}, Modus: ${request.mode}`);
      });
  } else {
      console.log('Ingen ventende låseforespørsler.');
  }
});

            

              
                Copy
              
            
          

lockInfo-objektet inneholder to egenskaper: held og pending. held-egenskapen er en array av objekter, der hvert objekt representerer en lås som for øyeblikket holdes av opphavet. Hvert objekt inneholder name og mode for låsen. `pending`-egenskapen er en array av låseforespørsler som er i kø og venter på å bli innvilget.

Feilhåndtering

request()-metoden returnerer et promise som kan bli avvist (rejected) hvis en feil oppstår. Vanlige feil inkluderer:

• AbortError: Låseforespørselen ble avbrutt.
• SecurityError: Låseforespørselen ble nektet på grunn av sikkerhetsrestriksjoner.

Det er viktig å håndtere disse feilene for å forhindre uventet oppførsel. Du kan bruke en try...catch-blokk for å fange feil:

            navigator.locks.request('my-resource', { mode: 'exclusive' }, lock => {
  // ...
}).catch(error => {
  console.error('Feil ved forespørsel om lås:', error);
  // Håndter feilen på en passende måte
});

            

              
                Copy
              
            
          

Brukstilfeller og Eksempler

Web Lock API kan brukes i en rekke scenarier for å håndtere samtidig tilgang til delte ressurser. Her er noen eksempler:

Forhindre Samtidige Skjemainnsendinger

Se for deg et scenario der en bruker ved et uhell klikker på send-knappen på et skjema flere ganger. Dette kan resultere i at flere identiske innsendinger blir behandlet. Web Lock API kan brukes til å forhindre dette ved å anskaffe en lås før skjemaet sendes inn og frigi den etter at innsendingen er fullført.

            async function submitForm(formData) {
  try {
    await navigator.locks.request('form-submission', { mode: 'exclusive' }, async lock => {
      console.log('Sender inn skjema...');
      // Simuler skjemainnsending
      await new Promise(resolve => setTimeout(resolve, 3000));
      console.log('Skjemaet ble sendt inn!');
    });
  } catch (error) {
    console.error('Feil ved innsending av skjema:', error);
  }
}

// Knytt submitForm-funksjonen til skjemaets submit-hendelse
const form = document.getElementById('myForm');
form.addEventListener('submit', async (event) => {
  event.preventDefault(); // Forhindre standard skjemainnsending
  const formData = new FormData(form);
  await submitForm(formData);
});

            

              
                Copy
              
            
          

Håndtere Data i localStorage

Som nevnt tidligere, kan Web Lock API brukes til å forhindre datakorrupsjon når flere faner eller vinduer har tilgang til de samme dataene i localStorage. Her er et eksempel på hvordan du kan oppdatere en verdi i localStorage ved hjelp av en eksklusiv lås:

            async function updateLocalStorage(key, newValue) {
  try {
    await navigator.locks.request(key, { mode: 'exclusive' }, async lock => {
      console.log(`Oppdaterer localStorage-nøkkel '${key}' til '${newValue}'...`);
      localStorage.setItem(key, newValue);
      console.log(`localStorage-nøkkel '${key}' ble oppdatert!`);
    });
  } catch (error) {
    console.error(`Feil ved oppdatering av localStorage-nøkkel '${key}':`, error);
  }
}

// Eksempel på bruk:
updateLocalStorage('my-data', 'new value');

            

              
                Copy
              
            
          

Koordinere Tilgang til Server-Side Ressurser

Web Lock API kan også brukes til å koordinere tilgang til ressurser på serversiden. For eksempel kan du anskaffe en lås før du gjør en API-forespørsel som endrer data på serveren. Dette kan forhindre "race conditions" og sikre datakonsistens. Du kan implementere dette for å serialisere skriveoperasjoner til en delt databasepost.

            async function updateServerData(data) {
  try {
    await navigator.locks.request('server-update', { mode: 'exclusive' }, async lock => {
      console.log('Oppdaterer serverdata...');
      const response = await fetch('/api/update-data', {
        method: 'POST',
        body: JSON.stringify(data),
        headers: {
          'Content-Type': 'application/json'
        }
      });
      if (!response.ok) {
        throw new Error('Kunne ikke oppdatere serverdata');
      }
      console.log('Serverdata ble oppdatert!');
    });
  } catch (error) {
    console.error('Feil ved oppdatering av serverdata:', error);
  }
}

// Eksempel på bruk:
updateServerData({ value: 'updated value' });

            

              
                Copy
              
            
          

Nettleserkompatibilitet

Per slutten av 2023 har Web Lock API god støtte i moderne nettlesere, inkludert Chrome, Firefox, Safari og Edge. Det er imidlertid alltid lurt å sjekke den nyeste informasjonen om nettleserkompatibilitet på ressurser som Can I use... før du bruker API-et i produksjon.

Du kan bruke funksjonsdeteksjon for å sjekke om Web Lock API støttes av brukerens nettleser:

            if ('locks' in navigator) {
  // Web Lock API støttes
  console.log('Web Lock API støttes!');
} else {
  // Web Lock API støttes ikke
  console.warn('Web Lock API støttes ikke i denne nettleseren.');
}

            

              
                Copy
              
            
          

Fordeler med å Bruke Web Lock API

• Forbedret Datakonsistens: Forhindrer datakorrupsjon og sikrer at data er konsistente på tvers av flere faner eller vinduer.
• Forenklet Samtidighetsstyring: Tilbyr en enkel og standardisert mekanisme for å håndtere samtidig tilgang til delte ressurser.
• Redusert Kompleksitet: Fjerner behovet for komplekse, egendefinerte synkroniseringsmekanismer.
• Forbedret Brukeropplevelse: Forhindrer uventet oppførsel og forbedrer den generelle brukeropplevelsen.

Begrensninger og Hensyn

• Avgrenset til Opphav (Origin): Låser er avgrenset til opphavet, noe som betyr at de kun gjelder for faner eller vinduer fra samme domene, protokoll og port.
• Potensial for Vranglås (Deadlock): Selv om det er mindre utsatt enn andre synkroniseringsprimitiver, er det fortsatt mulig å skape vranglåssituasjoner hvis det ikke håndteres forsiktig. Strukturer logikken for anskaffelse og frigjøring av låser nøye.
• Begrenset til Nettleseren: Låser holdes i nettleseren og gir ikke synkronisering på tvers av forskjellige nettlesere eller enheter. For server-side ressurser må serveren også implementere låsemekanismer.
• Asynkron Natur: API-et er asynkront, noe som krever nøye håndtering av promises og tilbakekallinger.

Beste Praksis

• Hold Låser Korte: Minimer tiden en lås holdes for å redusere sannsynligheten for konkurranse.
• Bruk Spesifikke Låsnavn: Bruk beskrivende og spesifikke låsnavn for å unngå konflikter med andre deler av applikasjonen eller tredjepartsbiblioteker.
• Håndter Feil: Håndter feil på en passende måte for å forhindre uventet oppførsel.
• Vurder Alternativer: Evaluer om Web Lock API er den beste løsningen for ditt spesifikke bruksområde. I noen tilfeller kan andre teknikker som optimistisk låsing eller server-side låsing være mer passende.
• Test Grundig: Test koden din grundig for å sikre at den håndterer samtidig tilgang korrekt. Bruk flere nettleserfaner og -vinduer for å simulere samtidig bruk.

Konklusjon

Frontend Web Lock API gir en kraftig og praktisk måte å håndtere samtidig tilgang til delte ressurser i webapplikasjoner. Ved å bruke eksklusive og delte låser kan du forhindre datakorrupsjon, sikre datakonsistens og forbedre den generelle brukeropplevelsen. Selv om det har sine begrensninger, er Web Lock API et verdifullt verktøy for enhver webutvikler som jobber med komplekse applikasjoner som trenger å håndtere samtidig tilgang til delte ressurser. Husk å vurdere nettleserkompatibilitet, håndtere feil på en passende måte og teste koden din grundig for å sikre at den fungerer som forventet.

Ved å forstå konseptene og teknikkene som er beskrevet i denne guiden, kan du effektivt utnytte Web Lock API for å bygge robuste og pålitelige webapplikasjoner som kan håndtere kravene til det moderne nettet.