Bidouilleux d'Web

Voici mon premier billet sur Hacks et mon premier billet en tant que Mozillien (malgré mon blog personnel). Ce dernier mois, j’ai pu travailler sur le projet de Service Worker Cookbook (NdT : livre de « recettes » pour les service workers) qui fait partie de l’initiative pour les développeurs d’applications web (WADI). J’ai ainsi pu mettre en pratique l’expertise que j’avais sur les service workers et découvrir de nouvelles façons d’utiliser cette nouvelle technologie au bénéfice du Web. Voici donc où j’en suis.

Dans le billet précédent de cette série, mon collègue David Walsh évoquait Application Cache, son manque de flexibilité et je ne m’étendrai pas davantage sur ce point. Toutefois, j’aborderai plus en détails certaines des « recettes » disponibles dans ce cookbook. David avait traité de certaines recettes pour l’aspect hors connexion, ici, j’irai un peu plus loin et me consacrerai à d’autres scénarios pour lesquels les service workers peuvent s’avérer utiles.

L’état actuel des services workers

Bien que leur développement ait pris un certain temps, ce n’est que maintenant que nous commençons à entendre parler de l’utilisation des service workers. Pour résumer, cette API était initialement prévue pour réussir là où Application Cache avait échoué. Avec un peu d’archéologie, on s’aperçoit que l’intention de départ était effectivement de corriger la mise en cache hors connexion pour permettre aux développeurs web de construire des applications hors connexion pouvant fonctionner avec des URL et organisées sur des couches de façon saine et structurée.

L’approche initiale apportait le concept de contrôle de navigation à travers une notion qui est depuis devenue l’événement fetch des service workers. Cela permet d’intercepter les requêtes réseau et de répondre avec les données obtenues depuis le réseau, des bases de données ou encore depuis des données générées de façon procédurale. Le meilleur dans tout ça ? Les pages contrôlées n’ont pas besoin de savoir qu’elles le sont (enfin on peut leur dire) et la logique du service est donc complètement décorrélée de la logique de l’application. On a véritablement affaire à un « homme du milieu ».

Mais nous bidouillons (voyez le titre de blog) et nous aimons trouver des solutions ingénieuses à nos problèmes. Le concept de la bidouille c’est que ces solutions ingénieuses étaient en fait destinées à autre chose. À Mozilla, au travers des initiatives WADI et Firefox OS, nous avons exploré les scénarios suivants en tirant parti des service workers.

Analyser l’usage d’une API

Commençons avec une application directe de cet homme du milieu : analyser l’usage d’une API. Plaçons-nous dans le cas où on souhaite obtenir des informations sur l’utilisation qui est faite d’une API, sans avoir accès au serveur. Les solutions actuelles utilisent le code côté client pour générer des requêtes HTTP et envoyer les journaux au service analytique. Avec un service worker, on peut aller plus loin : intercepter chaque requête, extraire ses paramètres, envoyer le journal pour l’analyse et laisser la requête suivre sa route sur le réseau.

Installer des applications empaquetées

Avant d’aller vers des utilisations plus exotiques, voici un cas plus traditionnel : un service worker peut être utilisé pour créer des ressources hors connexion en installant des applications empaquetées. On peut télécharger un paquet sous la forme d’un fichier zip et le décompresser au moment où on active un service worker. Ainsi, on réduit la couche ajoutée par les requêtes HTTP et le téléchargement des ressources devient une opération atomique. La mise en cache, intelligente et automatique, des fichiers statiques (polices ou images par exemple) est un autre exemple pertinent d’application.

Se faire passer pour un serveur

Vous vous rappelez l’analogie faite plus tôt avec l’homme du milieu ? Un service worker peut agir comme un proxy pour imiter un serveur et implémenter l’API que le client utilise habituellement avec le réseau. ServiceWorkerWare, développé dans le cadre de Firefox OS, est une bibliothèque qui supporte la nouvelle architecture Gaia pour les applications et qui permet aux développeurs d’utiliser les service workers de façon déclarative, en suivant la même philosophie que la bibliothèque Express pour Node.js mais pour côté-client.

Implémenter des fonctionnalités pour des frameworks modernes

Les service workers peuvent tout à fait être des briques de construction pour les frameworks modernes. Prenons par exemple l’interpolation de gabarits (template interpolation). De nombreux frameworks d’application web comme backbone.js et Angular effectuent le rendu des modèles en interpolant leurs propriétés via des templates. La nouvelle architecture de Gaia, évoquée plus haut, introduit le concept de render store (NdT : stockage de rendu) : un cache hors connexion qui stocke le résultat de l’interpolation du template avec les données du modèle afin que, lors d’un deuxième appel du client vers le même modèle, on puisse récupérer le rendu depuis le render store et éviter les temps d’interpolation.

Injecter les dépendances

Un autre concept populaire est lié aux frameworks récents : l’injection des dépendances. Ce concept indique que le code qui utilise les dépendances n’a pas besoin de connaître la façon dont elles ont été construites. Le code final doit uniquement connaître les interfaces abstraites qui lui sont offertes et les implémentations correspondantes sont fournies par une factory abstraite qu’on appelle injecteur (ou injector en anglais). Un service worker peut être utilisé comme injecteur. Un framework pourrait ainsi demander aux composants de déclarer les dépendances d’API via des balises de script, ensuite le service worker agirait comme injecteur, pourrait identifier les requêtes vers ces ressources abstraites et répondre avec les modules réels.

Reporter des requêtes

Si jamais l’appareil n’est plus connecté à Internet, mais que l’application continue d’accepter des opérations, l’application du client et les données dans le cloud ne seront plus synchronisées. Une fonctionnalité intéressante serait de proposer un report des requêtes. Par exemple, un service worker pour retenir les requêtes à l’API et les lancer lorsque l’application est de nouveau connectée à internet. Durant cette retenue, le service worker pourrait imiter les réponses d’un serveur, en envoyant des réponses OK (code de statut 200) ou ACCEPTED (code de statut 202) au client. Une fois la connexion revenue, le service worker enverrait les requêtes dans l’ordre où il les as reçues.

Idées pour le réseau

Et pour finir, les service workers pourraient aussi gérer la logique du réseau de l’application, en faisant plusieurs requêtes simultanées vers plusieurs sources, mesurant la qualité et la disponibilité des sources afin d’envoyer les données vers la meilleure source disponible. Prenons un petit exemple. Imaginons que nous avons un site de streaming vidéo. L’utilisateur veut voir un film en HD, donc l’application fait la demande. Mais, avant de commencer à envoyer le fichier, le service worker intercepte la requête, demande la charge de tous les serveurs, sélectionne celui avec la plus petite charge et demande le film à ce serveur spécifique. Ça vous rappelle quelque chose ? Il s’agit d’un load balancer (NdT : répartiteur de charge), mais cette fois-ci, il est implémenté directement sur le client. Plutôt sympa non ?

Résumé

C’est tout pour aujourd’hui ! Sept usages, sept recettes exotiques qui dépassent l’idée de simplement mettre en cache du contenu pour qu’il soit disponible hors connexion. Le livre de recettes des service workers illustre tous ces moyens (et même plus) pour utiliser les fonctionnalités proposées par l’API Service Worker. Et nous ne nous arrêterons pas là. Il y a bien plus à explorer ; l’API Push est ici pour longtemps et la synchronisation en arrière-plan arrive bientôt, avec des réponses HTTP en « stream » et les requêtes annulables à l’horizon. Qui sait ce qui viendra ensuite ?

Pour plus d’informations au sujet des service workers et des autres implémentations en cours, allez voir [Platapus]((https://platatus.herokuapp.com/), nous vous tiendrons informé.

À propos de Salva

Développeur front-end à Mozilla, défenseur d’un Web ouvert, j’aime les langages de programmation, le cinéma, la musique, les jeux vidéo et la bière.