Découverte de Gatsby

J’entends souvent parler depuis quelques mois de Gatsby, un générateur JavaScript / React de sites statiques comme l’écosystème JavaScript en raffole !

Le principe est simple : Gatsby va générer un site statique (des fichiers HTML, CSS, JavaScript donc) à partir d’une ou plusieurs sources de données externes (cela peut aller d’une API d’une installation WordPress à une API REST ou GraphQL de votre conception, ou encore du système de fichiers !).

GatsbyJS - fonctionnement
Le fonctionnement simplifié de GatsbyJS

Prenez ces données, uniformisez-les au format attendu avec un des nombreux transformer plugins disponibles, ajoutez vos templates et vos composants comme vous feriez pour n’importe quelle application React, et vous obtenez des fichiers HTML,CSS et JS prêts à héberger chez vous, ou a déployer sur n’importe quel service (Heroku, Now, Netlify…) !

En pratique : Handy Web Resources

Pour tester Gatsby, j’ai donc décidé de créer une petite application très simple, permettant de lister des ressources utiles au design et développement Web : Handy Web Resources.

Gérer les données

Handy Web Resources

Rien de bien compliqué ici : Une ressource est caractérisée par un titre, une courte description, une image et différents tags. Pas de commentaires, de notes… Est-ce vraiment donc utile ici de créer un service API à part avec une base de données juste pour stocker ces ressources ? Non !

La solution par défaut proposée par Gatsby est la publication par fichiers Markdown. Une ressource est donc représentée comme tel dans l’arboresence de l’application :

Au moment de la phase de build, le plugin transformer-remark va récupérer tous ces fichiers et les parser pour les indexer. Contribuer au site devient alors très simple : cloner le dépôt Git de l’application, y ajouter son fichier markdown et l’image de miniature dans un commit, et reconstruire le site, aussi simplement qu’un petit gatsby build !

Ajouter un backoffice

Par contre me direz-vous, en général les contributeurs d’un blog ou d’un site vitrine ne sont pas adeptes de Markdown 😛

Vous pouvez, comme je le disais précédemment, tout à fait brancher votre propre service, un CMS Headless ou bien un backoffice du CMS de votre choix ! Mais pour ma part, j’en ai profité pour tester NetlifyCMS qui est un mini-backoffice pour Gatsby mais bien d’autres générateurs de sites statiques, et qui tient en 2 fichiers à ajouter dans un répertoire admin sur le dépôt du projet (un fichier HTML qui appellera un script distant et un YAML de configuration)

L’authentification se fait depuis n’importe quel service, mais évidemment, NetlifyCMS est optimisé pour fonctionner avec… Netlify ! 😀

L’appli sera donc déployée sur Netlify donc ! Je relie mon dépôt Git, et j’active Netlify Identity qui va me permettre d’avoir un compte pour accéder à mon administration ! Un peu de configuration plus tard… 🎉

L’interface est très simple, mais elle fait ce qu’on attend d’elle : upload d’images, éditeur WYSIWYG… Et rien d’autre à changer sur ce qui fonctionne déjà !

Sauvegardes et déploiement

Le fait d’avoir branché le dépôt Git à Netlify facilite encore la tâche : créer ou mettre à jour un article depuis ce backoffice va créer les 2 fichiers (image + markdown) dans le dépôt, faire un commit et pousser sur la branche master.

Ce push sera détecté par Netlify qui va automatiquement déclencher une nouvelle procédure de build prenant en compte le dernier ajout ! Une minute plus tard, les nouveaux fichiers statiques sont en production !

Netlify déploiement
L’écran de visualisation des déploiements

Gérer les recherches

Bien parti, je continue avec la gestion de la barre de recherche. Elle doit donc permettre de trouver une ressource par titre, résumé et tag.

Gatsby propose un plugin Algolia, qui va, pendant la phase de build, récupérer toutes les entrées (grâce toujours à une requête GraphQL) et construire un index qu’on retrouvera instantanément dans l’interface de gestion). Je peux ensuite configurer les règles de recherche (tolérance aux fautes dans la requête, prise en compte de la casse…)

Chaque ressource devient un enregistrement (record) de l’index

Ensuite côté application, je n’ai plus qu’à utiliser le plugin d’Algolia pour React, InstantSearch, pour récupérer les résultats de la recherche dans l’UI, et changer le state de mes divers composants !

À noter que je m’étais penché également du côté d’Elasticlunr et de son plugin Gatsby qui fait tout ce traitement, mais en local (les données indexées sont envoyées au client sous forme de JSON, et la fonctionnalité de recherche est traitée par le navigateur)

Bilan

  • 💶 Financier : 0€ ! J’utilise les versions gratuites de chaque service (Netlify, Algolia) à chaque fois. Pour Netlify, tant qu’il s’agit d’un projet mono-utilisateur, les quotas ne sont pas vraiment un problème. Par contre sinon, le plan suivant démarre à 45$/mois ! Il existe néanmoins d’autres fournisseurs de services équivalents, et il ne faut pas oublier que le build n’est qu’au final un ensemble de fichiers statiques hébergeables n’importe où, y compris sur des espaces mutualisés ! Concernant Algolia, les 10000 enregistrements du plan gratuit ne m’inquiètent pas, ce qui est moins le cas pour les 50000 opérations (recherche, index…) qui est selon moi une limite qui peut très vite être atteinte avec un minimum de trafic. Ici encore, il y a de nombreuses alternatives (elasticsearch, solr…).
  • Rapidité : La folie ! Lors du build, tout est optimisé automatiquement, chaque fichier HTML ne contient donc que l’essentiel à son fonctionnement. La recherche est également ultra-rapide. Un autre aspect mis en avant par Gatsby mais que je n’ai pas encore pu étudier est la génération de PWA (Progressive Web Apps), consultables en partie hors-connexion. Un prochain article sans doute 😉
  • 🔍 SEO : Ici aussi je n’ai pas creusé la question à 100%, mais Gatsby embarque Helmet qui permet de gérer l’affichage dans la balise <head> depuis n’importe quel endroit du template. Niveau SEO, on a donc de nombreuses possibilités (si chaque fichier markdown est voué à devenir une page, on peut y ajouter une meta description sans souci par exemple)

Chaque projet est différent, mais au vu de tous ces avantages Gatsby a un bon potentiel pour du blogging ou de l’éditorial en général. Niveau développement, étant encore assez nouveau dans l’univers React il faut parfois batailler un peu, mais une fois la logique acquise et comprise le tout devient très intuitif !

À bientôt pour d’autres tests 🙂