Second post d'une série de 3 articles, proposés par Ludovic Coullet (@lcoullet) au sujet des Progressive Web App (PWA). Comment transformer tout ou partie de son site en PWA ? Dans quel intérêt ? Comment s'y prendre...
- Partie 1 : PWA et Drupal, généralités
- Partie 2 : Découplage
- Partie 3 : Exemple de PWA avec Drupal 8 et Gatsby
La manière la plus radicale de réaliser une PWA avec Drupal est de passer par un découplage total.
Décapitons Drupal !
Si vous vous demandez encore ce que cela veut dire, vous pouvez consulter cet article.
L’idée principale étant de n’utiliser Drupal que comme un entrepôt et une interface de saisie du contenu. C’est ce qu’il sait faire de mieux : gestion des rôles, Views, worflows compliqués, souplesse des types de contenus et des taxonomies !
Ce contenu est exposé via une API (REST ou GraphQL), avec ou sans authentification suivant les besoins.
Drupal 8 est capable nativement d’exposer ses ressources sous la forme d’une API REST. Mais des modules supplémentaire comme JSON API permettent d’obtenir des données mises en formes suivant un modèle standard. A ce propos, nous savons depuis peu que le module en question sera intégré à Drupal 8.7 !
Enfin il existe déjà des distributions qui sont orientées découplage et qui intègrent les modules ad-hoc pour commencer un projet du bon pied :
- Contenta CMS
- Lightning (Acquia)
Le rôle de Drupal s’arrête ici. La logique d’affichage se fait ailleurs et surtout elle a lieu principalement dans le navigateur de l’internaute et de moins en moins côté serveur !
React, VueJS et compagnie
Qui dit traitement côté client dit avant tout javascript. On pourrait tout à fait s’en sortir uniquement avec le langage et ses fonctionnalités et pourquoi pas avec un peu de jQuery, mais ce serait long…
Cela fait quelques années que plusieurs frameworks JS se partagent le marché sur l’affichage dynamique de contenu à partir de sources externes :
Nous ne citons ici que les plus connus, mais il en existe encore d’autres qui utilisent un autre langage ou une variante du JS et qui se compilent en bout de chaine en javascript pour être compris de tous les navigateurs :
L’offre est extrêmement vaste ! Chez bluedrop.fr nous avons fait le choix de nous concentrer sur 2 solutions en fonction des besoins :
- VueJS lorsqu’il s’agit de faire des choses simples ou dans le cas de découplages progressifs ;
- React pour les projets d’envergure et le découplage total.
Ce sont également 2 des 3 technologies qui reviennent le plus dans les demandes et les projets auxquels nous répondons.
Ces technologies reposent essentiellement sur la notion de composants web réutilisables (web components) qui regroupent au même endroit affichage, style, fonctionnalités et qui peuvent communiquer entre eux et s’assembler aisément.
Un petit exemple de compteur avec VueJS, voici la définition du composant contenant l’affichage et la logique métier :
// Définition d'un nouveau composant appelé `button-counter`
Vue.component('button-counter', {
data: function () {
return {
count: 0
}
},
template: '<button v-on:click="count++">Vous m\'avez cliqué {{ count }} fois.</button>'
})
et son application :
<div id="components-demo">
<button-counter></button-counter>
</div>
Ces composants peuvent accepter des paramètres qui vont modifier leurs affichages et comportements (des Props dans la terminologie Vue ou React).
Par exemple : un composant header à qui on pourrait passer des paramètres de couleur suivant la section du site sur laquelle on se trouve.
Dans le cas précis du découplage, il s’agit surtout de créer des composants auxquels on passe une URL (notre endpoint d’API et une méthode) et qui en retour nous affiche la liste des dernières actualités, le détail d’une actualité, un menu…
Ces technologies nous évitent d’avoir à ré-inventer la roue et s’intègrent très bien avec d’autres outils (au hasard webpack) qui permettent de disposer au final d’une version de production la plus optimisée possible avec un service worker déjà configuré. De quoi faire plaisir aux outils de test de performance !
Lorsque nous avons à faire à des projets complexes, un autre type de composant (des entrepôts ou stores) permet de gérer l’état de l’application à un niveau central et d’éviter pas mal de problèmes.
Citons : Redux et Vuex pour nos 2 frameworks de prédilection.
Mais… (car il y a toujours un mais)
Nous nous retrouvons en bout de chaine avec schématiquement une fichier HTML quasi-vide qui va appeler une feuille de style et surtout de nombreux fichiers JS à même de requêter l’API et de remplir le vide initial. C’est généralement le cas avec ce que l’on désigne sous le nom de SPA (Single Page Application).
Si nous réalisons une pure application métier protégée par une authentification et disponible dans les favoris de tous les collaborateurs d’une entreprise, ça n’est pas vraiment un problème.
Mais c’est une catastrophe lorsqu’il faut que le site en question soit bien positionné et référencé.
En effet, les crawlers des moteurs de recherche eux ne vont pas aller plus loin que le code HTML qui leur est fourni au départ.
Google a récemment communiqué sur le sujet dans une série de vidéos exposant leur position. Il en ressort que même si Google est en mesure d’exécuter ce code JS pour obtenir le contenu rendu, cela lui prend du temps, beaucoup plus qu’avec du code HTML généré côté serveur.
Le traitement des SPA se fait en 2 temps. Lorsqu’il rencontre des pages de ce type, il fait un noeud à son mouchoir en se disant qu’il y reviendra lorsqu’il aura plus de temps et de ressources pour exécuter le JS et crawler le contenu ainsi généré. Mais Google reste assez évasif sur le délais entre ces deux passages…
Il est fort probable qu’à l’avenir ce problème soit résolu, mais en attendant il est primordial de trouver une solution.
Le SSR à la rescousse
Le SSR ou server side rendering est une technique permettant d’offrir à vos utilisateurs et aux robots des moteurs de recherche des pages qui contiennent déjà une partie ou la totalité du contenu que votre JS aurait pu générer.
Ceci offre des avantages en terme de :
- performance ;
- SEO.
Dans le cas de contenu en temps réel, ce n’est pas forcément tout à fait raccord avec la réalité, mais le squelette de la page et les méta-données seront bien là. Une fois la page chargée, le JS prends le relais pour récupérer les bonnes informations dans un processus qui porte de le nom très imagé de ré-hydratation (hydration).
Le meilleur des deux mondes en somme, mais comme expliqué dans l’article en lien, cela a un coût et rajoute à la complexité du développement.
Enfin cela demande un serveur (généralement lui même en NodeJS) pour générer tout cela. Dans le cas d’un site statique, il faut pré-générer les pages avant des les envoyer sur le serveur.
Heureusement pour nous, il y a désormais des solutions qui cadrent et facilitent ce travail comme Gatsby que nous aborderons la prochaine fois !
A suivre...
Le SSR ou server side rendering est une technique permettant d’offrir à vos utilisateurs et aux robots des moteurs de recherche des pages qui contiennent déjà une partie ou la totalité du contenu que votre JS aurait pu générer.
