gatsbyjs.com

De quoi traite Gatsby ?

Gatsby est un framework React permettant de créer des sites web à partir de composants et de contenu structuré. Il peut recueillir des données provenant de fichiers, de systèmes de gestion de contenu, d’API et d’autres services, organiser ces données au moyen d’une couche GraphQL et les utiliser pour créer des pages avec un rendu statique, différé, côté serveur ou côté client.

Gatsby est le framework. gatsbyjs.com est son site officiel et son centre de documentation. Cette distinction est importante, car l’architecture, les packages et le dépôt du framework sont les sujets de ce guide, tandis que le domaine est l’endroit où le projet publie sa documentation.

Un projet Gatsby réunit généralement plusieurs aspects dans un même flux de travail :

• Les composants React définissent l’interface et les éléments de page réutilisables.
• Les plugins sources importent du contenu et des données depuis des systèmes locaux ou distants.
• Gatsby normalise les enregistrements importés sous forme de nœuds dans sa couche de données.
• Les requêtes GraphQL sélectionnent les champs nécessaires aux pages et aux composants.
• Les API de page et les modèles transforment les données en routes.
• Les paramètres de rendu déterminent à quel moment chaque page est produite.

La relation entre Gatsby et React

React fournit le modèle de composants de Gatsby. Les développeurs composent les mises en page, la navigation, les modèles et les fonctionnalités interactives à partir de composants React, tandis que Gatsby fournit le framework environnant pour le routage, l’importation des données, la création des pages, le traitement des ressources et la production du résultat final.

Gatsby n’est donc ni un substitut à React ni une simple bibliothèque de composants. C’est un framework web avec des conventions précises, construit autour de React. Les équipes peuvent employer les pratiques familières de JSX, de composition de composants, de props, d’état et d’interaction côté navigateur, tout en utilisant les API propres à Gatsby pour les données et le rendu.

Ce que Gatsby ajoute autour de React

Aspect	Ce que fournit React	Ce qu’ajoute Gatsby
Interface	Composants et état	Conventions de pages, mises en page et intégration à la compilation
Données	Choix de récupération des données au niveau de l’application	Une couche de données normalisée et un flux de requêtes GraphQL
Routes	Éléments de base d’une application	Pages fondées sur les fichiers, création programmatique de pages et routes exclusivement côté client
Résultat	Interfaces rendues dans le navigateur	Rendu de pages statique, différé et au moment de la requête
Intégrations	Un écosystème JavaScript généraliste	Plugins, thèmes, modèles de démarrage et API de cycle de vie du framework Gatsby

Cette structure peut convenir à une équipe React qui crée un site public riche en contenu. Elle peut être superflue lorsqu’un petit projet intègre peu de contenu ou lorsque ses besoins relèvent principalement d’une application rendue côté client.

La couche de données et GraphQL

La couche de données de Gatsby est conçue pour fournir une interface de requête commune à différentes sources de contenu. Les plugins sources récupèrent les enregistrements et créent des nœuds Gatsby. Gatsby rend ensuite ces nœuds accessibles au moyen d’un schéma GraphQL que les pages et les composants peuvent interroger.

Un site peut combiner des fichiers Markdown, des images, un système de contenu headless et certaines données de services. Au lieu d’obliger chaque page à comprendre le format de réponse d’origine de chaque source, Gatsby peut exposer les enregistrements pertinents au moyen d’un graphe partagé.

Un parcours de contenu type se présente ainsi :

1. Un fichier, un service ou une plateforme de contenu contient les éléments d’origine.
2. Un plugin source importe ces éléments pendant le processus d’importation des données de Gatsby.
3. Gatsby représente les enregistrements importés sous forme de nœuds et construit un schéma.
4. Des requêtes GraphQL demandent les champs requis par une page ou un composant.
5. Un modèle utilise le résultat de la requête pour produire la page.
6. Gatsby rend la page selon le mode de rendu sélectionné.

GraphQL joue un rôle central dans le flux de données importées de Gatsby, mais il ne remplace pas toutes les valeurs React ordinaires. Les props de composants, l’état local, les événements du navigateur et les requêtes côté client peuvent toujours exister en dehors du graphe créé lors de la compilation. La question utile est de savoir si le schéma partagé de Gatsby simplifie le contenu qui doit être assemblé dans les pages.

La couche de données ajoute également du travail. Les équipes doivent comprendre le comportement des sources, les relations entre les nœuds, les modifications du schéma et les dépendances des requêtes. Un graphe réunissant plusieurs systèmes peut être utile, mais son coût de compilation et sa charge de maintenance doivent être testés avec du contenu représentatif plutôt que déduits d’un modèle de démarrage.

Les plugins sources et le modèle d’extension au sens large

Les plugins sources relient Gatsby aux données. Ils peuvent lire des fichiers locaux ou intégrer des systèmes de contenu et des services, puis créer des nœuds qui participent à la couche GraphQL. Ils se distinguent ainsi des plugins qui ajoutent du traitement, des outils d’analyse, des styles, la prise en charge des images ou d’autres comportements liés au cycle de vie.

Gatsby regroupe le travail réutilisable sous trois formes liées :

• Les plugins ajoutent une source, une transformation, une intégration ou une fonctionnalité au framework.
• Les thèmes regroupent une configuration et des fonctionnalités Gatsby réutilisables que les sites peuvent étendre.
• Les modèles de démarrage fournissent un projet initial que les développeurs copient et adaptent.

Un modèle de démarrage peut raccourcir la configuration, mais ses dépendances et ses conventions deviennent la responsabilité de l’équipe qui l’adopte. Un thème peut préserver la cohérence des fonctionnalités entre plusieurs sites, mais les équipes doivent comprendre ce qu’il contrôle. Un plugin peut éviter d’écrire du code d’intégration personnalisé, bien que sa compatibilité et sa maintenance doivent être évaluées individuellement.

L’existence d’une vaste catégorie de plugins ne prouve pas qu’un package donné prend en charge la version de Gatsby, la source de données ou le modèle de déploiement d’une équipe. Une évaluation pratique doit déterminer les packages précis qui sont nécessaires, examiner leur documentation et l’activité de leur dépôt, puis les tester au sein de l’architecture proposée.

Les options de rendu dans Gatsby

Gatsby a d’abord été fortement associé à la génération de sites statiques, mais sa documentation définit désormais plusieurs options de rendu. Celles-ci peuvent être sélectionnées page par page, ce qui permet à un article public, à de vastes archives, à une route dépendant d’une requête et à une zone d’application d’utiliser différents modèles de production.

Option de rendu	Moment où la page est produite	Question pertinente à poser
Génération de site statique (SSG)	Pendant la compilation	Le contenu requis par la page est-il disponible avant le déploiement ?
Génération statique différée (DSG)	Lors de la première requête d’une page différée	Cette page peut-elle être exclue de la compilation initiale, et l’hébergeur prend-il en charge le DSG de Gatsby ?
Rendu côté serveur (SSR)	Au moment de la requête, avec getServerData	La réponse nécessite-t-elle des données ou un contexte disponibles au moment de la requête ?
Route côté client	Dans le navigateur pour un chemin d’application	Cette section est-elle volontairement conçue comme une application, et qu’est-ce qui est disponible avant la fin de l’exécution de JavaScript ?

Pages statiques et différées

Le SSG produit le HTML et les ressources associées pendant la compilation. Il constitue une option naturelle pour le contenu dont les données d’entrée sont connues à l’avance. Les fichiers générés peuvent être faciles à distribuer, mais un grand nombre de pages, des requêtes coûteuses, de nombreuses sources de contenu ou un traitement intensif des images peuvent accroître les exigences de compilation.

Le DSG reporte la création de certaines pages jusqu’à leur première requête. Cela peut réduire le nombre de pages créées pendant la compilation initiale, surtout lorsqu’un site possède une longue traîne de contenus rarement consultés. Il nécessite également un environnement de déploiement qui mette en œuvre le comportement de génération différée de Gatsby ; il ne revient pas à téléverser uniquement des fichiers statiques vers n’importe quel hébergeur.

Rendu au moment de la requête et dans le navigateur

Le SSR génère une réponse au moment de la requête au moyen de l’API getServerData de Gatsby. Il peut servir des pages dont le résultat dépend d’informations disponibles au moment de la requête, mais il introduit une exécution côté serveur, des décisions de mise en cache, une gestion des échecs et des exigences d’infrastructure qu’une page purement statique évite.

Les routes côté client prennent en charge les sections d’application gérées dans le navigateur. Elles peuvent coexister avec des pages publiques générées, mais les équipes doivent examiner les états de chargement, la navigation, l’accessibilité et le contenu disponible avant l’exécution du code côté client. Il ne faut pas supposer qu’un contenu est publiquement découvrable simplement parce qu’une route du navigateur finit par afficher les bonnes informations.

Aucune désignation de rendu ne garantit la rapidité ou la visibilité dans les moteurs de recherche. Les résultats dépendent de la conception de la page, de JavaScript, des ressources, des sources de données, de la mise en cache, de l’hébergement et de la qualité de l’implémentation. Gatsby offre plusieurs options architecturales aux équipes ; il ne supprime pas la nécessité de les mesurer.

Images et production de contenu

Les images font souvent partie du même pipeline de contenu que le texte et les enregistrements structurés. Les plugins Gatsby peuvent importer les fichiers image, les transformer et relier les ressources traitées aux requêtes des pages. Les composants peuvent ensuite afficher les données d’image sélectionnées dans un modèle de page.

Un flux éditorial utile sépare les responsabilités :

• Les éditeurs gèrent les titres, le corps du contenu, les métadonnées et les références d’images dans la source choisie.
• Les plugins sources importent ces enregistrements et les ressources référencées.
• La couche de données de Gatsby relie les nœuds de contenu aux données d’image requises.
• Les requêtes demandent uniquement les champs et les variantes d’image nécessaires à un modèle.
• Les composants fournissent les légendes, le texte alternatif, les dimensions et le comportement de mise en page.
• La compilation de production vérifie que les enregistrements, les ressources et les routes sont résolus ensemble.

Le traitement des images peut améliorer la cohérence, mais il représente toujours un travail de compilation. Les équipes doivent tester le nombre et la taille réels des ressources, vérifier l’incidence des modifications sur les nouvelles compilations et préserver le texte alternatif pertinent provenant de la source éditoriale. Un plugin ne peut pas décider si une image est informative, décorative ou décrite de manière appropriée.

Dans quels cas Gatsby peut être bien adapté

Gatsby est particulièrement pertinent lorsqu’un projet utilise déjà React et doit assembler du contenu provenant de plusieurs systèmes. Son graphe de données peut fournir une couche cohérente entre ces sources et les modèles de page qui les utilisent.

Parmi les situations courantes qui méritent une évaluation figurent :

• Les sites de documentation ou éditoriaux qui combinent des fichiers, des images et une plateforme de contenu.
• Les sites marketing dotés de composants React réutilisables et d’enregistrements de pages structurés.
• Les projets de publication multisource qui tirent parti d’une interface de requête unique.
• Les sites Gatsby existants construits autour des API de page, de GraphQL et de plugins établis.
• Les grandes collections de contenu dans lesquelles certaines pages peuvent être candidates au DSG.
• Les sites combinant des pages publiques générées avec des sections rendues au moment de la requête ou côté client.

Gatsby peut être moins directement adapté lorsqu’un projet possède une seule source de contenu simple, ne tire aucun avantage d’un graphe normalisé ou nécessite une architecture d’application principalement centrée sur les opérations au moment de la requête et côté client. Il s’agit d’un jugement architectural, pas d’un verdict sur la qualité du framework.

Compromis liés à la compilation et au déploiement

La génération statique déplace le travail en amont du déploiement. Gatsby peut devoir récupérer les données sources, construire son schéma, exécuter les requêtes, créer les pages, traiter les images, regrouper le code et écrire le résultat. La durée et les ressources requises dépendent du projet réel.

Une évaluation représentative doit consigner :

Domaine de test	Éléments à vérifier
Volume de contenu	Nombre de pages, nombre de nœuds, relations et tailles réalistes des enregistrements
Fiabilité des sources	Authentification, limites de débit, échecs et récupération reproductible
Requêtes	Stabilité du schéma, coût des requêtes et erreurs après des modifications du contenu
Images	Volume de traitement, utilisation de la mémoire, taille du résultat et métadonnées éditoriales
Rendu	Résultat SSG, premières requêtes DSG, réponses SSR et chargement des routes côté client
Déploiement	Prise en charge de chaque mode choisi, comportement de mise en cache et récupération après un échec

Une petite démonstration ne permet pas d’établir le comportement d’un catalogue complet. Les équipes doivent tester les compilations complètes, les modifications incrémentales lorsqu’elles sont prises en charge, les indisponibilités des sources de contenu ainsi que les pages situées aux extrêmes et dans la norme du jeu de données.

Le DSG peut déplacer une partie du travail hors de la compilation initiale, tandis que le SSR déplace le travail vers les requêtes. Il s’agit de changements de calendrier et de responsabilité opérationnelle, pas d’améliorations gratuites des performances. L’hébergeur choisi doit prendre en charge le comportement Gatsby requis, et l’équipe doit comprendre ce qui se passe lors d’une requête à froid ou d’une défaillance en amont.

Gatsby, Astro et les autres solutions

Gatsby et Astro peuvent tous deux figurer dans les évaluations de sites web axés sur le contenu, mais ils organisent les projets différemment. Gatsby place au centre React, sa couche de données GraphQL, ses plugins sources et ses API de génération de pages. Astro doit être évalué selon sa propre architecture documentée plutôt que considéré par défaut comme une solution plus rapide ou plus récente.

Gatsby mérite une attention particulière lorsqu’une équipe veut utiliser React dans toute l’interface, doit interroger plusieurs sources de contenu normalisées, dépend d’intégrations Gatsby ou maintient une base de code Gatsby établie. Un autre framework peut être plus simple lorsque ce graphe et ce cycle de vie des plugins ajouteraient de la structure sans résoudre un véritable problème de contenu.

Une comparaison utile consiste à créer la même portion représentative avec chaque candidat : une source de contenu, une page complexe, une liste, la gestion des images, la navigation et le mode de déploiement prévu. Comparez la compréhension des développeurs, le comportement de compilation, le résultat dans le navigateur, l’accessibilité, les exigences d’hébergement et la responsabilité de la maintenance. Évitez de déclarer un vainqueur universel à partir de modèles par défaut.

Fondateur et ressources officielles de la communauté

Dans une séance officielle de questions-réponses de la communauté Gatsby publiée le 2 avril 2020, Kyle Mathews était présenté comme « Founder @ GatsbyJS ». Cette attribution datée décrit son rôle historique dans cette source ; elle ne doit pas être interprétée comme une affirmation concernant la direction actuelle de Gatsby.

La documentation de Gatsby oriente les développeurs vers différents canaux communautaires officiels selon leurs besoins :

• Discord est présenté comme un espace où demander de l’aide à la communauté des développeurs.
• Les discussions GitHub permettent d’échanger sur le projet et ses fonctionnalités.
• La documentation relative aux contributions explique comment participer au projet.
• Le dépôt gatsbyjs/gatsby, qui est maintenu, contient le code source du framework, les packages, les tickets et l’historique des contributions.

Ces ressources aident les lecteurs à vérifier la documentation, à poser des questions d’implémentation et à examiner le travail public sur le projet. Leur existence ne doit pas être transformée en affirmations non étayées concernant les délais de réponse, la longévité des packages ou les projets futurs.

Ce que les équipes doivent décider avant d’adopter Gatsby

1. Cartographier le contenu. Recensez chaque source, les relations entre les enregistrements, la fréquence des mises à jour et les pages qui utilisent chaque champ. Cela permet de déterminer si la couche GraphQL normalisée de Gatsby résout un véritable problème de coordination.

2. Attribuer un mode de rendu aux pages représentatives. Confirmez quelles pages peuvent être statiques, lesquelles peuvent être différées, lesquelles nécessitent getServerData et lesquelles sont volontairement rendues côté client. Vérifiez que la cible de déploiement prend en charge la combinaison obtenue.

3. Auditer l’ensemble concret des dépendances. Vérifiez les plugins sources, les plugins de transformation, les thèmes, les modèles de démarrage et les outils d’image nécessaires par rapport à la version de Gatsby du projet. Créez un prototype des intégrations incertaines avant d’en faire des dépendances architecturales.

4. Tester une charge de travail représentative de la production. Gatsby offre un framework cohérent pour React et le contenu, mais sa pertinence dépend de son adéquation avec les données, les pages, les intégrations et le modèle d’hébergement de l’équipe, et non de promesses générales concernant la vitesse, le classement dans les moteurs de recherche ou une mise à l’échelle sans effort.