Gatsby, le tur-fu ?

Récemment j’ai migré tout le blog sous Gatsby. Retour d’expérience sur le pourquoi !

Disclaimer

Ceci n’est pas vraiment un tutoriel sur “comment migrer de WordPress à Gatsby.”

J’ai tenu à faire cet article pour préciser les raisons d’une telle migration car j’ai réçu des questions via l’Internet et je ne voudrais pas que certain(e)s se fourvoient.

Déjà vu sur le blog ?

Cela fait un moment que les générateurs de static m’intéressent.

Qu’il s’agisse d’Octopress (2015) propulsé par Jekyll (2014) ou d’autres ressources, les avantages de ce genre de solutions sont assez évidents en termes de performance donc je ne vais pas revenir dessus, cela me semble déjà assez documenté.

Gatsby est dans la même lignée mais permet d’aller beaucoup plus loin.

On pourrait aussi rédiger ses articles en markdown dans des fichiers .md et convertir ça à la compilation comme avec Jekyll (il y a un plugin pour ça), mais de vous à moi, on évitera ! En plus, on va pouvoir conserver son Back Office (tableau de bord) WordPress.

En effet, je tiens à conserver mon interface Gutenberg, que les réfractaires à Gut ne me jettent pas la pierre 🙂

Liberté, etc.

La promesse de Gatsby tient en une phrase :

load data from anywhere.

grosse punchline ! Fin du game 🙂

Ayant désormais une API RESTful, WordPress s’ouvre peu à peu à ce qu’on appelle le headless. Littéralement “sans tête” mais on traduira plutôt par “sans front” (et non pas “sans frontière”, ah la blague était si bonne XD).

En gros, un BO (back office) + des APIs qui exposent la data et après je fais ce que bon me semble là où j’ai envie d’afficher, mettre en forme, souligner, “showcaser”, faire tourbillonner ces data.

Derrière, ça permet de découpler le back et le front, qui, dans WordPress, sont mariés 4 enfants. Non Gatsby n’est pas un briseur de couples, c’est l’API REST de WordPress qui a libéré la parole et les mœurs et de plus un lien subsiste, ce n’est pas un divorce mais une relation plus ou moins à distance.

Les avantages

Au final, et en relativement peu de temps, quelques heures, par-ci par-là, c’est bouclé et encore ça peut aller beaucoup plus vite (y en a qui parlent de “10 minutes” mais attention c’est en partant de zéro).

Source

Attention, je dis bien “c’est bouclé” car mon but ici était de faire un “POC” (proof of concept) pas de réaliser l’ultime blog sous un Gatsby survitaminé.

J’apprécie la performance en front, on aura beau mettre du cache dans tous les sens, WordPress et son templating classique aura du mal à rivaliser avec Gastby. Au-delà du résultat purement chiffré, j’aime l’approche que met en avant Gastby :

While performance is already at the heart of Gatsby, it’s important to ensure you are doing all you can to make your content available to your users as fast as possible. Not all users are enjoying high speed connections, or browsing from a desktop

Source

Le poids des fichiers n’est pas négligeable et contrairement à ce qu’on aurait pu imaginer, c’est plutôt slim ! Slim & fast donc 🙂

De fait et moyennant quelques plugins, on obtient une PWA.

La portabilité est maximale.

Enfin, encore une fois, je garde mon Gutenberg (oui j’insiste ^^) et dans le thème et les config c’est du full React / GraphQL.

Humans

Inconvénients

Le temps, même si je viens de dire que c’était rapide, ce qui m’a fait perdre le plus de temps a été de migrer un blog existant et des conneries qui marchaient pas :

Mais sans coloration syntaxique ou alors partiellement, je ne voyais pas trop l’intérêt.

Du temps aussi consacré aussi à mon propre thème Gatsby, faisant évoluer légèrement l’ancienne version sous WordPress. À n’en pas douter, avec un thème tout fait, ça prendrait moins de temps mais si c’était pour mettre ça sur un twentynineteen (oui certains ont porté le thème sous Gatsby), idem, je voyais pas l’intérêt ici.

Certaines fonctionnalités deviennent complexes à réaliser alors que dans un système WordPress classique, c’est la base !

Les systèmes de commentaires à la Disqus ne sont pas très convaincants, surtout si on regarde leur politique de vie privée, stand by pour l’instant sur cette fonctionnalité.

Enfin, après chaque publication, il faut rebuilder le tout et l’envoyer sur le serveur (ça peut être accéléré néanmoins mais en connectant d’autres outils).

Les pièges à éviter

Le premier piège c’est Gatsby

N’allez pas migrer sur du full js pour la beauté du geste ou parce que ça a l’air hype. Ou alors si, faites-le, mais dans un contexte fun / veille / POC comme moi ici.

Deuxième piège : contourner GraphQL

Cette manie de vouloir prendre d’autres chemins, qui n’est pas si mauvaise, et même plutôt bonne, eh bien, oubliez-là ici, ce n’est pas moi qui le dit c’est internet :

Dois-je utiliser GraphQL ?

En plus WP GraphQL fait super bien le job et GraphQL est largement supporté dans la sphère React, on trouve beaucoup de docs.

Troisième piège : bien penser React

Et non pas “penser printemps” sinon on sait tous que cela ne veut absolument rien dire 🙂

Il faut bien adopter cette logique de composants réutilisables à la React sinon vous allez faire une usine à gaz. Des gaz, même de JavaScript ça pollue.

Quatrième piège : ça compile pas !

Je migrais mon petit blog, j’avais réussi à fixer les petits glitch évoqués plus haut et ça marchait avec :

gastby develop

mais bim, avec :

gatsby build

plantade !

Fixer des erreurs au build c’est ce qui a été le plus chronophage, ça peut démultiplier les minutes voire les heures 🙂

Cinquième élément : le SEO

Attention, attention, heureusement Gatsby a prévu des ressources, notez en revanche, que sur ce blog je me contre-fiche du SEO.

Les pages sont server-rendered (rendues côté serveur) grâce aux services worker ainsi utilisez l’inspecteur de la console et vous verrez le markup HTML alors qu’en affichant la source de la page directement non.

À ce propos ça marche pas de base, Gatsby prévient dans cette partie de la doc dédiée aux metadata. Pas de plugin helmet, pas de title, pas de meta seo, etc.

J’ai trouvé ça très très con, après je me suis rappelé qu’ils n’ont pas forcément pu tout faire, c’est déjà un travail remarquable mais pas sûr que ça génère du cash, c’est toujours le problème de l’open source, à un moment faut trouver un modèle pour soutenir le projet… des contributeurs… là dessus WordPress est à des années lumière devant.

Faut-il vraiment utiliser Gatsby ?

Attention je parle avec une source de données WordPress !

Je dirais donc oui pour le challenge, le fun, pour apprendre le React, le JavaScript, parce que dans cette jungle c’est ce qui se fait de plus simple.

AMHA pas le plus optimal avec WordPress ou alors dans des cas particuliers.

Conclusion

Migration bien cool, j’ai appris plein de trucs et je sais en plus que ça va me servir tôt ou tard. Gatsby est un super outil, bien conçu, bien pensé, on tire vraiment parti de NPM dès qu’on a besoin d’un petit fix ou d’un composant React.

Pour un blog ça fait un processus assez gras, pas tant que ça au final, mais quand même à prendre en compte. Si votre but est de publier rapidement tout en évitant le monde uniformisé “Gattaquesque” de Medium et que les contraintes du projet sont faibles restez sur un WordPress c’est très bien.

Pour de la production, si j’avais le choix, peu de contribution ou alors un CMS taillé pour le découplage, comme Directus, Contentful (Gatsby les supporte tous pratiquement de fait), pourquoi pas, challenge !

Pour des projets à forts enjeux, gros objectifs et impératifs SEO, sûrement pas en l’état. Peut-être plus Next.js qui est dit SEO friendly.

Bref comme toujours à arbitrer en fonction d’un contexte.