Decouvrez les secrets d'une PWA React survitaminée

Dans un premier temps, nous allons redéfinir ensemble la signification d’une PWA (Progressive Web App) pour s'assurer que tout le monde parte bien des mêmes bases.

Lors du premier contact avec une PWA, on peut avoir l’impression de rencontrer un site web classique et puis progressivement l’expérience ressemble davantage à celle d’une application native. Si l’un des premiers objectifs des PWA était de rendre possible une expérience hors connexion, comme expliqué dans notre introduction aux progressives web app, aujourd’hui les possibilités vont bien au delà.

Google dépense beaucoup d’énergie pour réduire le gap entre les applications web et les applications native. C’est en partie expliqué par le fait que nous utilisons de plus en plus nos mobiles pour accéder à internet. Mais pas exclusivement...

En effet, de nombreuses applications web utilisées au bureau sont maintenant des PWA. Par exemple, la version web de Microsoft Teams repose sur ces technologies.

Petit à petit, ces applications deviennent de plus en plus musclées, il est donc important de voir ce que l’on appelle une application web survitaminée.

Les objectifs du projet

Pour notre PWA survitaminée, nous avions besoin d’une application capable de fonctionner pendant plusieurs heures consécutives (au moins dix heures) sur une tablette répondant aux critères de la norme ATEX, qui doit pouvoir être utilisable hors ligne et se synchroniser de façon automatique quand la connexion est disponible.

Quand la connexion est bonne, cette application affiche des graphiques qui évoluent en quasi temps réel pour surveiller un processus industriel. Pour compliquer encore l’exercice, notre application communique avec des API protégées par jeton, de quoi pimenter encore plus la gestion du mode hors ligne.

Architecture technique retenue

Une architecture cross framework pour résister à l’épreuve du temps.

Nx : Les fondations d’une architecture pérenne

Nx est à l’origine une extension d’Angular CLI apportant des fonctionnalités avancées autour du concept de monorepos. Pour rappel, une structure monorepos c’est un repos git unique permettant de gérer plusieurs applications et plusieurs bibliothèques, qu’elles soient frontend ou backend. Si dans les premiers temps, il était question de pouvoir mettre en place un monorepos fullstack centré autour d’Angular, Nx est maintenant un outil unifiant l’expérience de développement frontend.

On peut désormais gérer un parc applicatif composé d'applications Angular, AngularJS, React comprenant next et gatsby. Le support de vue.js est également prévu mais pour pouvoir utiliser vue.js avec un monorepos Nx, nous devons attendre la sortie de vue 3. Nx dispose d’un système de plugin, ce qui nous permet de l’étendre et de l’adapter à nos besoins. Stencil est géré par un plugin de la communauté.

Dans le cadre de notre application, nous avons utilisé Nx pour développer une application React. Nous avons tiré profit du concept de bibliothèque pour concevoir et documenter le design system de notre PWA avec StoryBook, aussi pris en charge par Nx. Venant d’Angular, le passage à React s’est fait sans friction : la macro architecture est la même qu’une application Angular. TypeScript a également été d’une précieuse aide lorsqu’en cours de projet, nous devions passer du développement d’une application au développement de deux applications. La refactorisation du code nécessaire pour y arriver n’a pas dépassée une demi-journée.

Akita : Simplicité et puissance un redux à la sauce RxJS.

Akita est une librairie de state management construite au-dessus de RxJS. Ce n’est probablement pas l’approche la plus standard pour une application React mais ce choix va dans le même sens que celui de Nx. Bien que RxJS soit surtout connu des développeurs Angular, pour nous, la découverte de RxJS s’est faite avant même la sortie d’Angular 2. Notre PWA reposant massivement sur la programmation asynchrone, il était évident que RxJS serait de la partie. RxJS, ou plutôt le concept des observables et la programmation réactive, sont les champions de l’asynchrone côté client. Akita ayant une approche cross framework, le choix s’est fait naturellement, d’autant plus que la librairie est très facile à utiliser. Un autre point important : Akita dispose d’un plugin de persistance qui permet de sauvegarder l’état de l’application avec IndexDB en toute simplicité.

Workbox : La boîte à outils du mode hors connexion

En très peu de temps, Workbox s’est imposé comme étant le standard du marché pour la gestion des Service Workers. Développée par Google, cette bibliothèque permet de simplifier grandement la gestion du mode offline. Parmi les fonctionnalités, nous retrouvons :

• Le precaching (mise en cache du squelette à l’installation)
• Le runtime caching (la mise en cache dynamique)
• Différentes stratégies de gestion du cache
• La configuration des routes
• La synchronisation en arrière plan

Note : si Workbox ne suffit pas à couvrir tous vos cas d’utilisation, sachez qu’il y a un système de plugin pour étendre ses fonctionnalités. Pour les besoins de notre application, nous avons eu besoin de dériver un plugin à partir du code source de Workbox.

Le code source est extrêmement clair et facile à suivre et nous avons réussi à ajouter une mécanique de rafraîchissement de jeton sans trop de difficulté. Nous avons ainsi pu tirer profit de la fonctionnalité de synchronisation en arrière plan.

Une architecture serverless pour une grande flexibilité.

Ce projet a été déployé sur une infrastructure cloud. Le plus important n’est pas de savoir que nous avons utilisé AWS mais de prendre conscience des avantages du cloud.

Le frontend a été déployé sur le CDN (Content Delivery Network) CloudFront. L’utilisation d’un CDN permet aux techniciens qui utilisent l’application d’y accéder le plus rapidement possible, peu importe le pays dans lequel ils interviennent.

Concernant l'infrastructure backend, elle s'appuye sur AWS CloudFormation. Cette approche serverless exploite des fonctions Lambda NodeJs et Python.

Et le plus important : il faut un chef d'orchestre car sans expertise, les outils ne font pas grand chose. L’utilisation de tous ces outils a été possible grâce à une véritable expertise transverse de toutes ces technologies.

• Les PWA offrent de plus en plus de possibilités
• Nx est un outil permettant d’unifier les outils de développement frontend
• TypeScript donne la possibilité de faire du refactoring dans un délai court
• Une architecture serverless permet d’utiliser le langage le plus adapté au projet
• Une bonne architecture logiciel facilite le changement et réduit les coûts à court et long terme

Chez Eurelis, nous possédons une expertise poussée sur les PWA, n’hésitez pas à nous contacter à ce sujet.