Le web d’aujourd’hui comme celui de demain tend à se définir comme mobile-first. Cette notion que l’on entend partout aujourd’hui est souvent placée dans le contexte du design, un design mobile-first étant un design d’application non seulement adapté à l’utilisation sur téléphone, mais qu’on aura avant tout pensé pour une utilisation sur téléphone, puis adapté pour navigateur web, contrairement à l’ancienne tendance qui consistait à faire son application web pour navigateur et, dans un second temps, de modifier la disposition de ses éléments sur mobile.

Le concept de mobile-first est cependant plus général que de juste parler de design, une application mobile-first est une application dont la cible première sera simplement le téléphone.

Au-delà du design, l’utilisation sur téléphone pose d’autres sujets de réflexion, l’un des plus “niche” autrefois et pourtant aujourd’hui l’un des plus importants pour certaines entreprises est la possibilité de rendre son application disponible sans connexion, et ainsi permettre à nos utilisateurs d’utiliser notre application dans des endroits reculés où le réseau n’est pas toujours stable voir présent, ou tout simplement sur des sites urbains mais présentant les mêmes caractéristiques, comme sous terre ou dans des bâtiments protégés, le tout sans avoir besoin de développer une vraie application mobile en plus d’un site internet.

Dans le cadre où l’on voudrait rendre notre application accessible hors ligne, une série d’outils sont à notre disposition. Pour les comprendre, il est important de rappeler quelques fondamentaux de Web standard.

Rappel du processus Web standard

Lorsque vous désirez requêter un serveur web afin de récupérer une page, ou encore juste du contenu via une API, votre navigateur web envoie une requête au serveur détenant la page, en lui demandant de lui servir le contenu qu’il détient pour un hôte (nom de domaine), une route (URL) et des paramètres précis. Le serveur calcule ensuite ce qu’il doit retourner, délégant parfois le travail à d’autres outils, puis retourne le contenu à votre navigateur, qui l’affiche.

Le processus réel est bien plus complexe que cela mais je simplifie ici car cela ne changerait rien à la conclusion que pour pouvoir requêter notre serveur, eh bien il faut pouvoir le joindre, donc être en ligne. Si vous tentez ce processus sans disposer de connexion internet, votre navigateur vous dira simplement que c’est impossible.

Afin de pouvoir accéder hors ligne à une application, votre navigateur doit auparavant avoir placé les éléments nécessaires à l’affichage de la page dans son cache local, et disposer d’un mécanisme qui lui permettrait de dire que si je veux accéder à cette page, sans connexion, qu’il me retourne ses éléments, mis en cache lors d’une précédente navigation.

Ce mécanisme existe aujourd’hui, ce sont les Service Workers.

Les Service Workers sont un mécanisme implémenté dans tous les navigateurs modernes, jouant le rôle de proxy entre les navigateurs et les serveurs web. Ils présentent de nombreuses facettes et sont utilisés dans des cas d’usage très variés, l’un des plus connus étant de pouvoir vous envoyer des notifications, directement dans votre navigateur, sans que vous ayez besoin de vous connecter au site internet qui vous les envoie.

L’un des autres cas d’usage les plus connus, celui qui nous intéresse ici, est de configurer un Service Worker pour notre application, dont le but sera de mettre en cache local les fichiers composant notre application, et d’être capable lors de nos navigations futures de servir ces fichiers à notre navigateur selon un ensemble de règles.

Parmi ces règles on notera par exemple :

  • Systématiquement servir les fichiers à notre navigateur sans aller les chercher sur le réseau, ce qui permet une accélération du temps de chargement des applications
  • Systématiquement aller chercher les ressources nécessaires en ligne, ce qui permettrait d’avoir toujours les données à jour
  • D’aller chercher les fichiers de notre application en ligne si la connexion est disponible, mais de les servir depuis le cache local si la connexion est indisponible

C’est ce troisième point qui nous intéresse dans la majorité des cas, mais il est bon de noter que d’autres existent également.

Comme d’habitude, on ne rentrera pas ici dans le détail de la mise en place et de la configuration des Service Workers, de nombreuses ressources existent en ligne qui expliquent cela bien mieux que moi.

La persistance des données

Notre application est maintenant disponible hors ligne. C’est un grand pas de franchi, car nous pouvons maintenant couper les données de notre téléphone ou de notre ordinateur et réussir à charger notre site internet, ce qui est une première étape.

Malheureusement, notre application charge mais… aucune donnée ne s’affiche.

C’est normal quand on y réfléchit, notre application a chargé les fichiers Javascript, HTML et CSS dont elle avait besoin pour afficher sa structure, mais les requête à notre serveur d’API, elles, ne sont pas cachées (normalement).

Vous pourriez vouloir les cacher, bien sûr, cela fonctionnerait, mais pensez à ne pas cacher les requêtes à des points de votre API qui proposent une expérience différente selon les utilisateurs, ou qui retourneraient des données accessibles seulement aux utilisateurs identifiés, car si des utilisateurs différents utilisaient le même périphérique, cela poserait des problèmes de sécurité…

La meilleure solution est d’implémenter dans votre application un système de store local. De la même manière que les Service Workers le font, cette couche de données tenterait de récupérer les données d’une API en ligne et, en cas d’échec, récupèreraient une donnée mise en cache lors d’une précédente navigation.

On peut même pousser le caching encore plus loin en créant une base de données locale pour l’application de l’utilisateur et en la synchronisant avec une base serveur au besoin.

L’excellent Redux-offline offre la possibilité aux développeurs ayant utilisé Redux dans leur application d’ajouter cette couche de persistance locale sans trop d’efforts, d’autres extensions vous proposent même de retenir tous les appels qui auraient dû être faits à votre API, et de tous les dépiler automatiquement au retour de la connexion internet.

Conclusion

Créer des applications accessibles sans connexion internet est aujourd’hui possible. Cela demande une réflexion particulière sur l’organisation des flux de données entre l’application et les serveurs, ce qui sera caché, ce qui ne pourra pas l’être, les règles de récupération de contenu etc…

Ajouter un mode hors ligne à une application existante est cependant plus complexe que de l’inclure dans une nouvelle application qui est encore en cours de conception.

©️ Julien PONTILLO | Consultant KLANIK