Découvrir le Service Worker #1 - Tour d'horizon

# web# mobile# js# pwa
écrit par Amrou OUNI publié le samedi 25 avril 2020

Les applications web progressives (PWA) sont la prochaine étape logique du web. Elles bénéficient d'une large communauté et d’une documentation étoffée. C’est le meilleur moment pour commencer à s’y former. Si vous voulez savoir ce qu’est une application web progressive alors je vous conseille vivement de consulter le très bon article de mon collègue Félix Sébatié sur le sujet.

Dans cet article nous traitons en profondeur une des plus, si ce n’est la plus importante technique employée dans ce type d’application : les services workers !

 

Qu’est-ce qu’un service worker ?

 

Un service-worker est tout simplement un script qui s’exécute en tache de fond de manière autonome. Il joue le rôle d’un proxy programmé coté client et intervient entre votre application web et le monde extérieur. Il vous offre un contrôle fin des requêtes réseau.

 

Pourquoi on a besoin des service workers ?

 

Les services workers permettent une intégration profonde des fonctionnalités principales d’une application web progressive, comme la disponibilité du mode hors ligne, la synchronisation en arrière-plan, la mise en cache et les notifications "push".

 

Cette capacité à garder en cache le contenu statique garantit de meilleures performances et un chargement plus rapide même si le réseau est de qualité médiocre. Ceci offre une expérience utilisateur se rapprochant de celle des applications natives.

 

Le service worker s’exécute indépendamment de votre page web et est capable de recevoir les messages même quand l’application web est fermée. Il peut être associé avec une base de données locale pour assurer la persistance des données au redémarrage (du service worker). 

Deux APIs principales permettent au service worker un fonctionnement efficace :

  • FETCH pour récupérer du contenu à partir du réseau.
  • CACHE offre un stockage persistant de contenu pour les données de l'application web. Ce cache est indépendant du cache du navigateur ou du « state ».

 

Mise en cache des données

Les connexions Internet peuvent être défaillantes ou momentanément indisponibles, c'est pourquoi que l’accès hors ligne est une caractéristique courante des applications web progressives. Même dans des environnements avec un bonne connexion, une utilisation judicieuse de la mise en cache et d'autres techniques de stockage peut améliorer considérablement l'expérience de l'utilisateur. Ils existent plusieurs solutions de stockage de données hors ligne pour les applications web progressives, elles permettent de gérer des données JSON, des images et des données statiques nécessaires.

 

De manière générale, on privilégie deux types de cache pour le stockage des données hors ligne :

  • Cache storage : accessible via l'API Cache pour les ressources nécessaires au chargement de l’application hors ligne (html, css, javascript, images, etc)
  • IndexedDB : pour les autres données, comme par exemple les « payloads » JSON. Cet API prend en charge les observateurs, ce qui offre une synchronisation facile entre les onglets.

 

Les deux API sont asynchrones (IndexedDB est basée sur les événements et l'API Cache est basée sur les promesses).

 

Quel niveau de sécurité pour les services workers ?

 

Les services workers sont très puissants et nécessitent donc un niveau de sécurité élevé. Ils sont disponibles uniquement par le biais du protocole HTTPS. Ce qui permet de se prémunir des attaques de type « Man-In-The-Middle » par exemple.

Attention, il existe une exception à cette règle ! les services workers sont disponibles hors https uniquement pour des fins de tests et pour des applications servies à partir du localhost.

 

Les évènements du service worker

 

Les services workers sont pilotés par des évènements, ils agissent en répondant aux évènements d’installation et d’activation.

 

L’évènement install permet de préparer le service worker pour être utilisé, par exemple en créant un cache pour le contenu du dossier "assets" de l’application. L’évènement activate correspond parfaitement pour nettoyer votre cache et tout ce qui est associé à la version précédente du service worker.

Le service worker peut recevoir des informations provenant d'autres scripts en utilisant des événements de type message. Il existe également des événements fonctionnels, tels que fetch, push et sync auxquels le système peut répondre.

 Les evenements du Service Worker

 

Fetch

Un évènement fetch est déclenché chaque fois qu'une ressource est demandée.

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

 service-worker.js

Sync

Le service worker peut utiliser la synchronisation en arrière-plan. Dans l’exemple suivant on commence par enregistrer un service worker et dès qu’il est enregistré on enregistre un événement sync avec le tag « foo », le service worker peut maintenant écouter l’évènement de synchronisation.

 navigator.serviceWorker.register('/sw.js');

// Later request a one-off sync:

navigator.serviceWorker.ready.then(function(swRegistration) {

  return swRegistration.sync.register('foo');

});

main.js

 

Le code suivant permet de s’abonner à l’évènement « sync » enregistré précédemment dans le main.js :

 

self.addEventListener('sync', function(event) {

  if (event.tag === 'foo') {

    event.waitUntil(doSomething());

  }

});

service-worker.js

 

La fonction "doSomething" doit retourner une promesse indiquant le succès ou l’échec de ce qu’elle essaie d’achever. Dans le premier cas l’évènement est considéré comme accompli, sinon un autre évènement sync sera programmé pour réessayer.

 

Push

Le service worker peut écouter l'événement push

// var options = {...}

self.addEventListener('push', function(event) {

    event.waitUntil(

      self.registration.showNotification('Hello!', options);

    );

});

 service-worker.js

 

Les événements push sont initiés par votre "backend" à travers un des services de notification du navigateur. Cet exemple montre une notification lorsqu'un événement push est reçu. L'objet options est utilisé pour personnaliser la notification.

 

Pour conclure 

Les services workers sont une technologie revolutionnaire qui se base sur un simple script et qui joue le role d'un proxy entre votre application web et le monde extérieur.

Ils permettent principalement de : 

  • Garder en caches des assets critiques de votre application
  • Lancer plus rapidement votre application grace au "offline-first" 
  • Gerer les notifications
  • Utiliser l’API "Push" (partiellement disponible) 

Dans le prochain article nous verrons plus de details sur la gesion du cycle de vie d'un service worker afin de mieu comprendre le fonctionnent de cette technologie prometteuse.

References

Cet article fait partie de la série : « Découvrir le Service Worker » :