Mais c’est quoi Jamstack ?

Jamstack est une architecture de développement pour les applications web. Son objectif est de séparer le développement des interfaces graphiques de celui des back ends (c’est-à-dire le traitement des données).

Dans JAM-Stack, JAM veut dire Javascript, API, Markup, les trois éléments essentiels de l’architecture Jamstack.

• JavaScript pour créer des applications dynamiques.
• API pour tout ce qui n’est pas directement visible pour les utilisateurs finaux (requêtes de données, connexion avec les CMS-Headless, moteurs de recherche, …).
  Certaines APIs seront appelées durant la compilation du site, d’autres lorsque les utilisateurs naviguent entre les pages.
• Markup, ou le code HTML qui est généré par les générateurs statistiques de sites (SSG).

En 2008 Jekyll a rendu populaire la génération statique de sites, mais c’est en 2015 que le cofondateur de Netlify, Mathias Biilmann introduit l’architecture Jamstack, qui n’a eu de cesse de gagner en popularité depuis.

Pourquoi pas SPA ?

Beaucoup de sites aujourd’hui utilisent l’architecture Single Page Application (SPA), ce qui est en général bien pour créer des WebApps, mais assez mauvais pour le référencement (SEO). Jamstack de son côté utilise des pages statiques, ce qui est bien meilleur pour le référencement et comme les IHMs sont créées au moment de la compilation, avant même qu’un utilisateur ait visité la page, les performances sont en général meilleures et ne sont pas affectées par l’augmentation du trafic.

Pourquoi utiliser Jamstack ?

Parce que c’est plus relaxe : la séparation des données (back end) et leurs consommation (front end) permet une organisation plus ciblée, plus simple et finalement moins stressante.

Pour gagner en performances : étant donné que les pages sont statiques, et prêtes à être servies aux utilisateurs, il est possible d’avoir d’excellentes performances. En utilisant des CDNs il est possible d’avoir des sites très rapides, où que se trouvent les utilisateurs.

Pour ne pas avoir à se soucier de la sécurité : votre site étant composé uniquement de fichiers statiques, il n’y a littéralement rien à attaquer. Évidemment il peut rester une vulnérabilité sur les APIs si vous en utilisez, mais nous recommandons de ne développer votre propre back end que quand vous faites quelque chose d’unique, et que vous êtes capable d’en assurer la sécurité. En général, il est plus sûr d’utiliser des API tierces, reconnues et éprouvées.

Pour le coût : l’hébergement d’un site statique est gratuit sur les plateformes tel que Vercel ou Netlify. Mais étant donné qu’il y a une ségrégation claire entre les contenus statiques et dynamiques, il est très facile, et peu coûteux de changer d’hébergeur si besoin. Si le trafic sur le site augmente, il est également facile de décider d’augmenter les capacités d’une partie très spécifique du site, ce qui sera en général moins coûteux que de migrer tout un site avec ses serveurs et ses bases de données.

Notre expérience avec le site socraft.ch

Pour l’architecture de notre site internet nous avons décidé d’utiliser Jamstack, avec Gatsby comme SSG, Ghost pour nos articles de blog, et Contentful comme CMS (pour le contenu autre que le blog).

Gatsby et GraphQL

J’ai éprouvé beaucoup de plaisir à utiliser Gatsby car la librairie est très bien documentée, et la majorité des développements sont autour de la librairie React qui est également très bien documentée. J’ai également eu accès à des dizaines d’exemples d’apps pour à peu près tous les types de sites que j’aurais pu vouloir développer, j’ai facilement trouvé des réponses à toutes nos questions.

Ce qui m’a le plus séduit c’est la facilité de trouver des plugins pour connecter nos CMS, améliorer la SEO et avoir un site optimisé pour les appareils mobiles.

React en lui-même est une excellente librairie pour développer des sites, nous pensons même qu’on tire son plein potentiel en l’utilisant avec un SSG comme Gatsby ou Next.Js.

GraphQL est une alternative aux API REST, Gatsby l’utilise à la fois pour manipuler les fichiers locaux, mais aussi pour faire les requêtes d’APIs pour les CMS. Ce langage de requêtes est très puissant, et les plugins comme “gatsby-plugin-sharp” nous permettent d’obtenir des images optimisées pour toutes les tailles d’écran juste en écrivant une requête GraphQL.

Nous apprécions également la facilité avec laquelle nous avons pu créer une PWA avec Gatsby.

Pas que Jamstack, mais aussi la librairie TailwindCSS

Nous avons choisi Jamstack pour les avantages cités précédemment (coût, sécurité, performance, simplicité), mais nous voulions également une simplicité dans la création des styles pour notre site, et c’est exactement ce que propose TailwindCSS.

TailwindCSS est une librairie CSS qui permet d’écrire le style de son site internet en utilisant uniquement des classes CSS, directement dans le code HTML. Nous utilisons également Tailwind-Typography pour notre blog, ce plugin propose un style agréable pour la lecture d’articles.

Nos déboires avec Ghost

Nous utilisons Ghost pour écrire nos articles, sa fonctionnalité headless nous permet d’utiliser un style propre à notre site. Mais Ghost-headless vient aussi avec quelques inconvénients, dont :

• L’aperçu des articles dans Ghost est différent du rendu final.
• Nous aurions voulu créer toutes les pages de notre site dans Ghost, mais les “pages” de Ghost sont trop limitées pour ce que nous voulions faire.
• Ghost est payant, mais l’offre de base ne permet pas l’utilisation des API headless
• Pour traduire nos articles nous devons passer par un système de “tag” pas très pratique
• Nous avons encore quelques problèmes de CSS pour le contenu sur lequel Ghost ajoute ses propres styles

Nos déboires avec Contentful

Contentful permet de créer des “custom types” pour les différents composants de notre site, et la traduction de ces composants est assez intuitive. Toutefois il n’est pas possible d’avoir un aperçu du rendu final. De plus il est parfois difficile de savoir quel niveau de granularité est le mieux adapté, car avoir trop de composants rend plus difficile la lecture d’une page dans Contentful, alors que ne pas avoir assez de composant voudrait dire un découpage moins fin des composants dans React (Gatsby)

N’aurait-on pas mieux fait d’utiliser un CMS classique comme WordPress ?

Pour être honnête, nous aurions pu développer notre site beaucoup plus vite en utilisant WordPress, car ce dernier propose des outils très poussés pour à la fois écrire des articles et créer des pages. De plus des centaines de thèmes et autres plugins permettent d’avoir rapidement à peut prêt toutes les fonctionnalités qu’on pourrait attendre d’un site internet ou d’un blog, dont le multilangue, tout ça sans développements supplémentaires.

Ces avantages viennent avec l’inconvénient qu’en général ces sites sont un peu plus lents, et gourmands en ressources, c’est-à-dire bande passante, requêtes de bases de données, taille des images et d’une manière générale en électricité consommée par visite. Certes, il existe des outils pour améliorer les performances et la mise en cache, mais ils ne font pas partie intégrante de l’architecture.

Avec une architecture Jamstack on utilise un CMS Headless, donc des APIs pour récupérer le contenu du CMS mais sans la mise en forme, ce qui est très pertinent si le contenu doit être affiché d’une manière différente d’un appareil à l’autre par exemple. Mais cette approche est contre-productive si le contenu est affiché de la même manière sur tous les appareils.

Les bonnes et mauvaises pratiques

Si comme nous, vous voulez vous lancer dans le développement d’un site en utilisant l’architecture Jamstack, nous vous conseillons d’adopter ces quelques bonnes pratiques :

Bonnes pratiques

• Utilisez Git et automatisez autant de choses que possible en utilisant GitHub Actions, GitLab CI, ou la CI de votre choix
• Profitez des offres d’hébergement gratuites de Vercel ou Netlify, ces offres incluent un CDN qui augmentera grandement la vitesse de chargement de votre site
• Faites-vous plaisir, il existe plusieurs centaines d’excellents SSG, le meilleur choix est celui qui vous procurera le plus de fun.

Mauvaises pratiques

• Générer du HTML au runtime, c’est mauvais pour votre SEO, moins performant que du HTML statique et en général c’est une pratique des Single Page Applications (SPA) qui n’est pas forcément compatible avec Jamstack

Conclusion

Nous sommes content d’avoir fait le choix de Jamstack pour le développement du site socraft.ch. Nous pensons que ce choix est pertinent pour les sites qui ont un contenu qui ne change pas très souvent, et la variété d’outils permet de choisir des technologies funs et faciles d’utilisation pour les développeurs.

En plus de cela, j’ai beaucoup appris en travaillant avec cette architecture, et dans une certaine mesure, j’ai actualisé mon appréciation de quelques aspects du SSR (Server Side Rendering).

Nous mettons toutefois en garde les personnes qui veulent faire du Jamstack car si le contenu change souvent, alors le site aura souvent besoin d’être recompilé. Même si le processus est automatisé, ce délai nécessaire pour redéployer le site peut être un problème. Nous dirons également que l’utilisation d’un CMS headless ne sera jamais aussi fluide qu’un CMS directement intégré dans votre site tel que WordPress.