CMS sans tête : Gatsby JS avec WordPress

Il est de notoriété publique que WordPress couvre environ un tiers des 1 million de sites Web les plus importants au monde avec plus de 50% de part de marché dans les systèmes de gestion de contenu. Pas plus tard qu'en 2016, WordPress a décidé d'introduire une API REST pour fournir à d'autres applications un accès amélioré au contenu de la base de données WordPress. En conséquence, offrant aux développeurs la possibilité d'exploiter WordPress en tant que CMS sans tête.

Cela impliquait inévitablement que les ingénieurs ne seraient plus limités à utiliser la couche de présentation conventionnelle de WordPress (frontend), mais pourraient désormais exploiter n'importe quelle application frontale pour fournir leurs données. À la lumière de cela, la majorité de ce blog explorera la relation entre WordPress et Gatsby.js en ce qui concerne l'effectuation Headless CMS.

Une brève histoire de CMS

Alors que nous prenons du recul pour comprendre la révolution Headless CMS, je pense qu'il est important de récapituler l'histoire des systèmes de gestion de contenu (CMS). Traditionnellement, au début des années 90, les pages Web statiques étaient le principal moyen d'exécuter des sites Web où un webmaster éditait directement des fichiers HTML et les téléchargeait sur un serveur via FTP. Finalement, au milieu des années 90, la technologie Web a commencé à évoluer et le contenu est devenu plus dynamique, ce qui a conduit à l'émergence des premiers systèmes de gestion de contenu monolithiques.

Essentiellement, un CMS monolithique est une application logicielle qui comprend tout ce qui est nécessaire pour éditer et publier du contenu sur le Web. Les premiers de ces systèmes étaient limités à des entreprises telles qu'EpiServer, cependant, des variantes open source ultérieures sont apparues comme WordPress, Drupal et Joomla. Le reste appartient à l'histoire car WordPress a gagné la plus grande part de marché au fil du temps.

Cependant, plus tard au cours de la révolution des smartphones, les appareils mobiles ont commencé à affecter la façon dont le contenu Web était consommé et diffusé. C'était un défi pour les CMS monolithiques traditionnels conçus pour fournir du contenu Web pour les ordinateurs portables et les ordinateurs de bureau.

Pour atténuer cela, la conception réactive est née, ce qui a abouti à des mises en page de sites Web qui s'adaptaient à la taille de l'écran. Par conséquent, cela a également permis de découpler la gestion de contenu de la couche d'affichage. C'est là qu'interviennent nos CMS Headless.

CMS sans tête

Comme mentionné précédemment, un Headless CMS est un CMS sans couche de présentation. En conséquence, le contenu est livré via une API (RESTful ou GraphQL) à une application frontale distincte qui le présente ensuite. L'API rend le contenu disponible sur n'importe quel canal et appareil en utilisant une variété d'outils et de langages de programmation avec un niveau de sécurité et d'évolutivité plus élevé.

Essentiellement, le CMS est découplé des préoccupations frontales, ce qui permet aux développeurs de créer des expériences riches pour les utilisateurs finaux, en utilisant la meilleure technologie disponible. Un mode « headless » ou « découplé » est actuellement supporté par la plupart des CMS, ce qui a ouvert la voie aux sites Gatsby.

Ainsi, pour tirer parti d'un CMS sans tête, vous devrez d'abord créer votre site ou votre application, puis utiliser l'API du CMS pour y intégrer votre contenu.

L'exécution du CMS sans tête WordPress

En ce qui concerne la chronologie des événements partagés ci-dessus, nous avons vu comment WordPress a fini par réaliser un CMS Headless. WordPress Contient une API (Application Programming Interface) qui vous permet de l'étendre avec des plugins (essentiellement comme un 'framework d'application'). Ceci est notamment réalisé via l'API REST comme nous le verrons plus loin.

Cependant, l'un des concepts clés de l'API WordPress est les hooks. Fondamentalement, les crochets permettent aux plugins de modifier les fonctionnalités de base de WordPress. Pratiquement, les crochets fonctionnent de manière à ce que lorsqu'un certain événement dans WordPress se produit (par exemple, le chargement de la page ou la post-édition), WordPress appelle un certain crochet pour exécuter la fonction.

Plus précisément, les crochets sont divisés en "Actions" et "Filtres". Les actions peuvent être exploitées pour exécuter certaines fonctions PHP dans certains événements, bien que les fonctions n'aient pas besoin de renvoyer quoi que ce soit. Alors que les filtres peuvent être utilisés pour exécuter des fonctions par lesquelles WordPress transmet des données lors de certains événements, ces fonctions prenant des données en tant que paramètre et renvoyant une version modifiée des données.

WordPress et l'API REST

Le transfert d'état représentatif (REST) ​​est basé sur le protocole HTTP et fournit une sémantique d'interface uniforme pour créer, lire, mettre à jour et supprimer des données (CRUD).

Généralement, l'exécution de l'API REST dans WordPress permet aux développeurs d'accéder à distance aux données d'une base de données WordPress en envoyant et en recevant des objets JSON (JavaScript Object Notation). Par conséquent, cela offre aux développeurs la possibilité de créer, lire, mettre à jour et supprimer les données WordPress d'autres applications qui ne sont pas conçues avec WordPress. Par exemple, les applications Web JavaScript ou les applications mobiles natives.

Cependant, à mesure que nous approfondissons notre compréhension de la relation du CMS Headless WordPress avec les API REST et Gatsby, nous devrons noter quelques concepts fondamentaux de l'API WordPress :

• Routes et points de terminaison : les routes sont des chemins auxquels vous pouvez accéder via un appel HTTP, tandis qu'un point de terminaison est une méthode HTTP (telle que get, post, put ou delete) mappée à cette route.
• Requête : lorsque vous lancez une requête HTTP vers une route REST enregistrée, WordPress crée automatiquement un objet de requête. Les données spécifiées dans la demande détermineront la réponse que vous obtiendrez.
• Réponse : un objet Response est constitué de données que vous recevez lorsque vous faites une demande. Il peut comprendre des données demandées ou des messages d'erreur.
• Schéma : un schéma fait référence à la structure de données dans le point de terminaison. Chaque point de terminaison peut avoir une structure de données légèrement ou significativement différente qu'il peut renvoyer. En conséquence, un schéma déterminera toutes les propriétés possibles qu'un point de terminaison peut renvoyer et tous les paramètres possibles qu'il peut recevoir.
• Classes de contrôleur : les classes de contrôleur permettent aux développeurs de gérer et d'enregistrer des points de terminaison et des itinéraires, tout en leur permettant également de gérer les demandes, d'utiliser le schéma et de générer des réponses.

Le "cadre" de React

Alors que nous entrons maintenant dans le vif du sujet de la relation Gatsby.js et WordPress, pour plus de contexte, nous devons déchiffrer ce paysage technologique à partir de bases plus historiques. React est la clé de cette histoire car il s'agit de la bibliothèque/framework JavaScript qui connaît la croissance la plus rapide. Rendus célèbres par Facebook (ses principaux développeurs), d'autres grands sites Web utilisent React pour leur interface tels que : Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace et Tesla.

Par conséquent, étant donné que React est une bibliothèque dans la pratique (car il lui manque encore les fonctionnalités notables d'un framework à part entière), cela signifie que d'autres "frameworks" peuvent être conçus par-dessus. En conséquence, l'un d'entre eux est Gatsby.js.

Présentation de Gatsby

Selon son site Web parent, Gatsby.js est un framework JavaScript gratuit et open source basé sur React qui aide les développeurs à créer des sites Web et des applications rapides. En principe, Gatsby.js génère des pages HTML statiques à partir d'applications pour le chargement initial, puis procède comme une application React (SPA) d'une seule page.

Attributs Gatsby.js

Dans ces circonstances, Gatsby exploite les principes de l'application Web progressive (PWA) pour récupérer uniquement les éléments requis en premier, puis charge le reste de l'application en arrière-plan ultérieurement. De plus, pour s'assurer que seules les données requises sont chargées, Gatsby utilise le langage de requête GraphQL (également de Facebook) pour charger les données à partir de la source. Il maintient également une optimisation d'image exceptionnelle.

Toutes ces fonctionnalités fusionnées donnent aux développeurs les outils nécessaires pour créer les sites Web et les applications Web les plus rapides possibles, car il ne charge que les codes HTML, CSS, données et JavaScript critiques. Ainsi, une fois qu'une page est chargée, Gatsby prélève les ressources pour les pages liées, et la navigation sur le site est donc assez rapide.

De plus, comme les pages sont générées à la compilation, avant la mise en ligne, vous n'avez plus besoin de serveurs PHP puissants et pouvez servir des fichiers statiques (HTML, JS et CSS, directement depuis le bucket storage). De plus, puisque Gatsby est propulsé par React, vous pourrez bien tout structurer avec des composants. Cet aspect modulaire permet aux développeurs de réutiliser facilement les composants.

Les autres fonctionnalités importantes de Gatsby prêtes à l'emploi incluent :

• Générateur de site statique
• Accès hors ligne
• Préchargement des pages liées
• Mise en cache des pages
• Pas de récupération de code superflu
• Exporter en tant que code
• Contenu de rechargement à chaud
• Code de rechargement à chaud
• Composantisation
• Liaison de données unidirectionnelle
• Requêtes de données API déclaratives (GraphQL)
• Interface utilisateur déclarative
• Chargement progressif des images
• Chargement d'image réactif
• Inlining du CSS critique
• Auto-hébergement de polices
• Sans serveur
• Pipelines d'actifs
• Extensions CSS (SaSS)
• Syntaxe JavaScript avancée
• Écosystème de composants React

Plugins Gatsby

Essentiellement, les plugins Gatsby sont fondamentalement des packages Node.js qui utilisent l'API Gatsby. Ces plugins peuvent ajouter des sources de données, transformer des données dans d'autres formats et ajouter des services tiers. Bien que Gatsby.org gère une bibliothèque de plugins qui comprend de nombreux plugins déjà créés par l'équipe principale de Gatsby ou des tiers. Idéalement, pour installer un plugin pour un projet Gatsby, les développeurs utilisent le gestionnaire de packages de nœud (NPM) sur leur terminal UNIX et exécutent la commande npm install.

Comment GraphQL Comes est lié à Gatsby.

GraphQL tourne autour de l'idée que vous pouvez décrire à l'API exactement les données que vous voulez précisément, et vous recevrez exactement cela. En conséquence, il est plus efficace que REST. À cette fin, Gatsby utilise Webpack et GraphQL. Plus important encore, avec GraphQL comme langage de requête, tout est défini du côté du client exécutant la requête, le client inconscient des sous-fonctionnements de l'application.

Cette implémentation unique permet aux développeurs de connecter n'importe quelle source de données à Gatsby. Par exemple, les articles de blog peuvent provenir de fichiers Markdown, de feuilles Google ou même d'un autre site Web WordPress. Par conséquent, offrant une flexibilité accrue avec la livraison de contenu.

Mécanisme Gatsby-WordPress (Plugins source)

Au fur et à mesure que nous déballons cette relation, nous devons comprendre les plugins source. Les plugins source sont des plugins spéciaux qui fonctionnent dans le système de données de Gatsby. Comme leur nom l'indique déjà, ils s'approvisionnent en données à partir de différents emplacements, locaux ou distants. Par conséquent, les données sont ensuite transformées en ce que Gatsby appelle des nœuds et des champs de nœuds. Fondamentalement, les champs de nœud représentent un seul élément de données à l'intérieur d'un nœud, et finalement, ces nœuds sont accessibles via une requête GraphQL.

Dans la même étendue, grâce aux plugins source, Gatsby prend en charge des dizaines d'options CMS sans tête, offrant aux équipes d'ingénierie et de contenu le confort et la familiarité de son interface d'administration préférée avec l'expérience de développement améliorée et les avantages de performances de l'utilisation de Gatsby, GraphQL et React pour construire un l'extrémité avant.

Le plugin 'Gatsby-source-WordPress' est construit et maintenu par l'équipe principale de Gatsby, et extrait des données soit de sites WordPress auto-hébergés, soit de WordPress.com. Il implique également l'authentification OAuth à l'API Word-Press.com et permet également aux développeurs d'interroger des images réactives.

Essentiellement, ce plugin prend en charge toutes les entités de l'API WordPress REST telles que les publications, les pages, les balises, les catégories, les médias, les types, les utilisateurs, les statuts, les taxonomies, les métadonnées du site et les types de publications personnalisées. De plus, les entités Advanced Custom Fields (ACF) et les informations de langage Polylang et WPML sont également prises en charge, en plus d'autres post-méta enregistrés auprès de l'API REST.

Ainsi, avec ce plugin, les développeurs peuvent choisir les routes à récupérer, bien qu'il récupère tous les points de terminaison de wpjson par défaut. Ainsi, les développeurs peuvent récupérer des données de WordPress avec GraphQL en utilisant le mécanisme ci-dessus.

En pratique, l'outil 'Gatsby-source-WordPress' fournit un slug pour tous les messages et autres entités. Et ainsi, tout ce qu'un ingénieur doit faire est de créer une page appelant la fonction 'createPage'. Ceci est exécuté dans le fichier Gatsby-node.js, généralement en exécutant d'abord une requête pour la source de données, puis en appelant 'createPage' pour chaque nœud trouvé, puis en définissant un fichier modèle à utiliser comme composant.

CI/CD et automatisation des versions d'applications.

Lors de la mise en œuvre d'un CMS WordPress sans tête avec Gatsby, la façon dont le déploiement est effectué est très critique. En règle générale, de telles exécutions nécessitent le déploiement d'une application à automatiser à l'aide d'Application Release Automation (ARA).

Généralement, ARA implique des fonctions principales :

• Déploiement des données, du code d'application et des artefacts.
• Déploiement de configurations spécifiques pour chaque environnement
• Conception de flux de travail de processus pour automatiser les tâches et les étapes de déploiement.
• Enfin, la modélisation de l'environnement et/ou le provisionnement des binaires

Puisque Gatsby produit des sites statiques, il est impératif de mettre en place un pipeline ARA afin que lorsque le contenu est mis à jour dans WordPress, il puisse être mis à jour en conséquence dans le site Gatsby. En règle générale, le déploiement continu est déclenché uniquement lorsque le code change, cependant, pour cette instance, il est souhaitable de le déclencher lorsque les données changent. Donc, pour cela, nous vous recommandons d'utiliser Netlify car il possède d'impressionnantes capacités de déploiement continu intégrées et est convivial à configurer.

Interrogation à partir de WordPress en utilisant GraphQL et gatsby-source-WordPress

À titre d'illustration, gatsby-source-WordPress fonctionne de manière à récupérer d'abord tout sur votre point de terminaison à l'aide de REST. Ensuite, il générera une API GraphQl interne basée sur ces données. Par la suite, il passera en revue vos requêtes et rassemblera les données de cette API GraphQL interne. Donc, fondamentalement, votre construction ne se termine qu'avec les données que vous avez demandées et rien d'autre.

Avantages du développement Headless WordPress avec Gatsby.js

Depuis que nous avons abordé le développement de WordPress sans tête avec Gatsby, nous pouvons maintenant détailler les avantages de ce type d'approche technique. Cela devrait essentiellement guider votre décision d'adopter ou non Gatsby !

• Le premier avantage est la possibilité d'avoir un site statique et pré-rendu. C'est le moyen le plus efficace de rendre une page Web, et puisque Gatsby utilise GraphQL pour exécuter la quantité minimale de données nécessaires, cela offre une efficacité supplémentaire pour le temps après le chargement initial.
• Amélioration de la visibilité SEO : Les pages statiques sont faciles à lire pour les moteurs de recherche car tout est pré-rendu et indexable. C'est un point positif, contrairement à d'autres mécanismes sans tête où le rendu des pages avec JavaScript est un problème concernant l'optimisation des moteurs de recherche (SEO).
• Vitesse de développement relativement rapide : par rapport à d'autres approches sans tête, Gatsby dispose d'un moyen unifié et facile à comprendre de récupérer des données, quelle que soit la source. Cela rend le développement plutôt simplifié car vous pouvez vous concentrer sur votre site actuel et laisser Gatsby faire la majorité du gros du travail.
• Hébergement moins cher : Vous pouvez héberger votre application Gatsby n'importe où car elle ne sert que des fichiers statiques, réduisant ainsi les dépenses d'hébergement. De plus, étant donné que WordPress n'est appelé que pendant le processus de construction, et jamais pendant la session utilisateur, il peut également être hébergé sur une solution d'hébergement abordable.
• Sécurité renforcée : D'une manière générale, les générateurs de sites statiques sont extrêmement sûrs car il n'y a pas de connexion directe à une base de données, des dépendances, des données utilisateur ou d'autres informations sensibles.
• Sans plugin : Du point de vue d'un non-développeur, WordPress est assez facile à utiliser grâce aux plugins disponibles. Cependant, cela limite la mise en œuvre de fonctionnalités personnalisées. Malheureusement, trop de plugins peuvent également ralentir un site car il devient lourd et plus difficile à rendre. Une exécution de Gatsby contourne essentiellement tous ces goulots d'étranglement.

Plus de facettes qui peuvent vous motiver à envisager Gatsby avec WordPress :

• Panneau d'administration WordPress facile à gérer.
• Système de connexion et d'autorisation utilisateur prêt à l'emploi.
• Avec l'éditeur Gatsby et Gutenberg, vous pouvez créer un constructeur de site Gatsby par glisser-déposer.

Inconvénients du développement Headless WordPress avec Gatsby.js

• Limitations de mise à jour : lorsque le contenu change à partir de zéro, il définit des restrictions sur la fréquence de mise à jour de votre site. De plus, l'exécution de Gatsby build peut prendre jusqu'à 10 minutes si votre site contient beaucoup de données, ce qui peut être un problème pour les sites qui se mettent à jour fréquemment.
• Mises à jour régulières Hustles : De plus, puisque Gatsby est un générateur de site statique, il ne peut pas simplement être "modifié", car même un petit changement de texte nécessitera un nouveau déploiement. Ainsi, si vous avez une page qui nécessite de nombreux changements de contenu quotidiens dynamiques, cela peut prendre beaucoup de temps et être fastidieux.
• Retards : vous devez généralement attendre plusieurs minutes pour voir les modifications apportées à votre contenu au fur et à mesure de leur mise en ligne.
• Manque d'aperçus : contrairement aux applications WordPress traditionnelles, vous n'avez aucun type d'aperçu dans Gatsby. Malheureusement, cela a été le plus gros problème rencontré par les créateurs de contenu avec Gatsby. Il vous faudra tout compiler, probablement avec les pipelines Gitlab CI/CD qui compilent le site web et mettent tout en ligne.
• Courbe d'apprentissage abrupte : Généralement, si vous souhaitez travailler avec Gatsby et WordPress en même temps, vous devez être relativement familier avec les langages PHP et JavaScript. Depuis que Gatsby fusionne React et GraphQL, cela peut être une courbe d'apprentissage abrupte pour beaucoup.

Dernières pensées.

En conclusion, grâce à ses performances et ses avantages commerciaux, de plus en plus d'entreprises implémentent Gatsby dans le cadre de leur pile technologique. Bien qu'il soit important de se rappeler qu'en fusionnant Gatsby avec WordPress, WP devient uniquement backend, ce qui implique que vous perdrez certaines de ses fonctionnalités et capacités.

De plus, les développeurs expérimentés dans le développement WordPress trouveront Gatsby comme un excellent outil avec ses avantages modernes en termes de performances, d'évolutivité, de sécurité et de vitesse de développement. Tout cela tout en leur permettant de conserver l'interface utilisateur de création de contenu familière offerte par WordPress.

Cependant, avant de lancer cette technologie, il faut toujours tenir compte des spécifications et des objectifs du projet. Par exemple, si l'accent est mis sur l'évolutivité, les performances, la vitesse de développement, le long cycle de vie, Gatsby fera l'affaire. Cependant, si l'accent est mis sur une flexibilité et des outils améliorés pour les créateurs de contenu non programmeurs avec un contenu mis à jour à la seconde ou à la minute, vous pouvez envisager une autre approche.