Update Article “2023-02-28-staticcms-une-autre-approche-aux-cms”

_posts/2023-02-28-staticcms-une-autre-approche-aux-cms.md

@@ -9,6 +9,27 @@ description: Si Worpdress tient le haut du panier des CMS, il n'est pas dénué
   défauts. Découvrez Static CMS, une alternative qui permet de concevoir des
   sites webs sobres, rapides, et très configurables
 ---
-Deuxfleurs a fait le choix de stocker ses données via un système de notre cru nommé [Garage](https://garagehq.deuxfleurs.fr). Ce dernier a de nombreux avantages dont un va particulièrement nous intéresser ici, c'est de publier un “dossier” (on appelle ça un _bucket_) directement comme un site web. C'est très efficace car on minimise les abstractions et les calculs à réaliser. Par contre, le site web doit être sous forme de fichiers HTML, CSS et Javascript : on ne peut pas le générer à la volée comme le fait un Wordpress, en allant chercher les informations dans une base de données.
+Deuxfleurs a fait le choix de stocker ses données via un système de son cru nommé [Garage](https://garagehq.deuxfleurs.fr). Ce dernier a de nombreux avantages dont un va particulièrement nous intéresser ici, c'est de publier un “dossier” (on appelle ça un _bucket_) directement comme un site web. C'est très efficace car on minimise les abstractions et les calculs à réaliser : ça consomme peu de ressources chez Deuxfleurs, et ça fait des sites rapides à consulter pour les internautes. Par contre, le site web doit être sous forme de fichiers HTML, CSS et Javascript : on ne peut pas le générer à la volée comme le fait un Wordpress, en allant chercher les informations dans une base de données. On appelle ce genre de site, “des sites statiques”, car ce sont simplement les mêmes fichiers qui sont envoyés à tout le monde pour constituer le site final.
 
-Alors si vous avez l'habitude de réaliser vos sites webs à la main, vous devriez être aux anges : 
+Alors si vous avez l'habitude de réaliser vos sites webs à la main, vous devriez être aux anges : en une commande, ou un glisser/déposer, votre site web est en ligne. Mais si vous êtes plutôt du genre à utiliser une interface, comme un système de gestion de contenu, alors tout devient plus compliqué…
+
+À moins que… à moins qu'on puisse combiner “sites statiques” et “CMS”. Et heureusement pour nous, les sites statiques sont à la mode, donc pas mal de gens ont travaillé sur la question ces dernières années ! Quand on est cool, on appelle ça une [Jamstack](https://jamstack.org/). Ici rien à voir avec la confiture ou des concerts de musique, JAM veut dire Javascript, API et Markup, et c'est issu de réflexion par des développeurs web sur l'architecture idéale pour développer des sites webs. Nous, on va prendre juste les principes qui nous intéressent dedans. 
+
+![](/assets/screenshot-2023-02-28-at-14-47-22-for-fast-and-secure-sites-jamstack.png)
+Un premier principe, c'est un découplage entre le _front_, c'est à dire le site web que voient les internautes, et le _back_, c'est à dire l'interface qui permet de créer, modifier, ou supprimer du contenu. Un autre principe, c'est que le _front_ qui est présenté aux internautes doit être le plus _pré-calculé_ possible pour que ce soit le aussi rapide et économe que possible de charger une page web. À partir de ces deux principes, on a tout un ensemble de conséquences très désirables (bonnes performances, faibles coûts, sécurité, passage à l'échelle, mise en cache facilitée, etc.).
+
+Maintenant qu'on a vu la théorie, passons à la pratique, et prenons ce (billet de) blog comme exemple ! Vous lisez ce billet depuis le _front_ qui est en réalité une série de fichiers HTML, CSS et Javascript. Ces fichiers sont stockés dans garage et ont été créés par un _générateur de site statique_, ici le vénérable [Jekyll](https://jekyllrb.com/), qui va transformer des fichiers [Markdown](https://fr.wikipedia.org/wiki/Markdown) en HTML. Bien sûr, Jekyll ne fonctionne pas tout seul, ni automatiquement, il faut le lancer à chaque modification. Pour automatiser ce lancement et l'envoi des fichiers, on va utiliser un _exécuteur de tâches_, ici [Drone](https://www.drone.io/). Maintenant, il faut bien stocker ces fichiers Markdown quelque part, pour ça on utilise Git, et plus particulièrement [Gitea](https://gitea.io). Enfin, parce qu'éditer ces fichiers Markdown à la main, et les envoyer dans Git, est une tâche fastidieuse, on a créer une interface _back_ qui permet de cacher toute cette complexité et proposer un environnement d'écriture. 
+
+Pour vous en convaincre, voici le tableau de bord :
+
+![](/assets/20230228_15h03m03s_grim.png)
+Et voici l'interface d'écriture pour un article :
+
+
+
+
+
+![](/assets/20230228_15h02m40s_grim.png)
+À l'instant où je vais appuyer sur “Publier”, alors c'est tout le système qui va se mettre en branle automatiquement : mes modifications seront enregistrées (avec la gestion d'un historique pour pouvoir revenir en arrière), Drone va se lancer et construire les nouvelles pages de mon site web avec Jekyll, et ensuite les envoyer sur Garage.
+
+Alors face à tout ces composants, on pourrait critiquer que ça ajoute une complexité importante, avec de nombreuses _pièces mobiles_ (_moving parts_ en anglais), c'est à dire des composants indépendants, qui ont leur propre cycle de vie, et qu'il faut pourtant garder _gluer_ entre eux.