Before it was cool
Tel monsieur Jourdain, on faisait du Jamstack sans le savoir, en utilisant un générateur de site statique, qui publie via de l'intégration continue, depuis maintenant 3 ans.
Si on prend la peine de scroller Jamstack.org on voit tout en bas le logo de Netlify, qui, coïncidence, propose un workflow et un hébergement ultime de site statique.
L'idée est simple : tout préparer en amont, puis livrer un site statique en suivant toutes les bonnes pratiques et optimisations.
L'utilisation massive de javascript et de services tiers pour améliorer l'expérience utilisateur est encouragé. L'acronyme JAM est pour Javascript (tout ce que propose HTML5 en fait), Api (des services tiers), Markup (du Markdown, comme tout le monde).
Concrètement, on va générer le contenu (html, médias), mais aussi les assets (feuilles de styles, javascript, polices de caractère…), compresser ce qui est compressible, et utiliser un CDN si on a des ambitions internationales.
Ça ira vite, ça mangera peu de RAM/CPU sur le serveur, et la surface d'attaque est minimaliste, le serveur http n'ayant pas besoin de pouvoir écrire le contenu qu'il sert.
Cerise sur le gâteau : le SEO adore les sites statiques.
Ce qui est moins cool
Git est un superbe outil, pour écrire des trucs destinés à des machines, mais pas forcément pour écrire du texte destiné à des êtres humains, surtout quand des rédacteurs doivent collaborer (annoter, corriger, discuter…).
Un éditeur collaboratif (comme codimd) et de la VOIP seront plus efficaces pour de la relecture et corrections.
À l'usage, le point important dans le workflow Jamstack, c'est l'intégration continue, qui construit et déploie, git reprenant son rôle d'outil de stockage de fichiers.
Contenu structuré
Les fichiers plats, pour décrire du contenu sont fort pratiques (et parfaitement adapté à git). Mais, souvent, du contenu structuré, bah, ça permet de structurer le contenu et d'avoir de jolies interfaces d'édition, construites automatiquement, avec des règles de validations pour renforcer cette cohérence. On passe du fichier plat à la base de données. Évolution classique dans le monde de l'informatique.
Pour visualiser cette évolution, on peut imaginer le passage de la notion de pages vers celle de catalogues.
On oublie la notion de patch et de branches, on se rattrape avec des instantanés. En échange, on a une jolie interface, et une notion de publication, pour que le contenu actuel soit utilisé pour générer et publier le site.
Bienvenu dans le monde des éditeurs de contenu sans tête, les headless CMS.
Contenu comme un service
En séparant l'édition de contenu du site produit, on isole complètement ces deux parties qui ne seront pas forcément gérées par les mêmes équipes. Les cycles de mises à jour peuvent être gérés tranquillement, qu'ils soient liés à la sécurité ou à de nouvelles fonctionnalités. On n'a plus la crainte de casser le site lors d'une mise à jour majeure, tout comme on devient nettement plus confiant sur les risques d'Armaggedon sur votre site qui vous obligent à surveiller comme le lait sur le feu toutes les versions de tous les modules de tous vos sites. Ainsi, l'équipe en charge de la création du site peut se concentrer sur la rédaction du contenu, et toute la partie visuelle (graphisme et UX).
On peut choisir d'utiliser un CMS headless que l'on déploie (et maintient) ou d'utiliser un service en ligne.
Un graphql pour les lier tous
Pour ne pas embêter les créateurs de contenu et de gabarits avec des détails d'implémentation, et ne surtout pas se disperser dans différentes technologies, il est sage d'utiliser une abstraction pour requêter les données.
C'est ce que promet Graphql, issu de Facebook, jeune technologie ayant maintenant atteint sa maturité, avec des outils fort pratiques, comme l'incontournable Apollo.
Intégration continue
D'un coté on a le contenu, interrogeable en graphql, de l'autre, on a des gabarits et des règles, hébergés dans un très classique git.
Au milieu, on a de l'intégration continue.
La CI sera déclenchée par les git push des gabarits, mais aussi par des webhooks, depuis l'éditeur de contenu.
Environnement de dev et de prod, mais pas pour le contenu
En choisissant un CMS headless, on fait le choix de sortir le contenu de git, ce qui a pour conséquence directe de n'avoir qu'un seul contenu, alors que l'on va avoir plusieurs environnements sur plusieurs branches pour les gabarits et les assets.
Pour garder la possibilité de corriger une faute de frappe ou n'importe modification mineure, il faut qu'à tout instant, on puisse reconstruire le site depuis la branche master (la production), sans s'empêcher de travailler sur la branche staging (la préprod). Pour ça, il ne faut jamais casser le modèle, et graphql a été conçu dans cette optique, ce qui devrait vous aider.
Le contenu devra avoir une colonne indiquant le statut brouillon/publié, pour pouvoir préparer tranquillement un contenu, sans qu'il risque de se retrouver en ligne de manière impromptue. Rien de neuf sous le soleil, cette notion est aussi vieille que l'invention du CMS, mais autant ne pas se laisser surprendre.
Ajouter des services tiers
Les sites statiques sont les bons petits élèves d'Internet, mais… ils sont statiques. Qu'à cela ne tienne, il est maintenant simple d'ajouter des services à son joli site statique.
Pour avoir le poul de son lectorat, ajouter un service de tracking web (à la Google Analytic) est trivial : un snippet de javascript inséré dans ses gabarits, et il se retrouvera dans les pages web déployées.
Pour des commentaires, ce sera similaire, le commentaire étant attaché à un type de contenu et ne devrait s'afficher que dans un seul gabarit.
La création de formulaire pour répondre à des questions ou s'abonner à une lettre de nouveautés ne devrait pas poser de problème, mais ne négligez pas les CSRF, ça limitera le spam, et les usages détournés.
Pour intégrer un moteur de recherche, bah, comme vous avez choisi de n'avoir qu'une seule référence pour les données (et plusieurs environnements), le cas est simple, vous indexez quand vous déclenchez le déploiement de l'application depuis l'éditeur de contenu.
Attention aux identifiants de services tiers qui vont dépendre de l'environnement (vous n'allez pas mélanger les stats de la préprod avec celle de la prod), et de les insérer au dernier moments avant de déployer.
L'ambition de Jamstack
Jamstack, par sa conception, permet d'avoir des sites à la navigation fluide (tout est déjà prêt), avec une forte sécurité (grâce à sa forte isolation), et tiendra tranquillement la charge (il a la sobriété d'un chameau). Votre bilan carbone vous remerciera.
Jamstack est parfaitement à l'aise avec tout ce qui est site plaquette, c'est une évidence, mais il va surtout beaucoup secouer le monde si vaste et si bien établi des CMS de taille raisonnable. Si votre CMS gère un site plus modeste que le New York Times, allez jeter un oeil dans le nouveau monde des CMS sans tête (et sans Varnish).
