gatsbyjs.com

Worum geht es bei Gatsby?

Gatsby ist ein React-Framework zum Erstellen von Websites aus Komponenten und strukturierten Inhalten. Es kann Daten aus Dateien, Content-Management-Systemen, APIs und anderen Diensten erfassen, diese Daten über eine GraphQL-Schicht organisieren und damit Seiten mit statischem, verzögertem, serverseitigem oder clientseitigem Rendering erstellen.

Gatsby ist das Framework. gatsbyjs.com ist seine offizielle Website und zentrale Dokumentationsplattform. Diese Unterscheidung ist wichtig, weil die Architektur, Pakete und das Repository des Frameworks Gegenstand dieses Leitfadens sind, während das Projekt seine Dokumentation auf der Domain veröffentlicht.

Ein Gatsby-Projekt führt üblicherweise mehrere Bereiche in einem Workflow zusammen:

• React-Komponenten definieren die Benutzeroberfläche und wiederverwendbare Seitenelemente.
• Quell-Plugins importieren Inhalte und Daten aus lokalen oder entfernten Systemen.
• Gatsby normalisiert bezogene Datensätze als Knoten in seiner Datenschicht.
• GraphQL-Abfragen wählen die Felder aus, die Seiten und Komponenten benötigen.
• Seiten-APIs und Vorlagen wandeln Daten in Routen um.
• Rendering-Einstellungen bestimmen, wann jede Seite erzeugt wird.

Das Verhältnis zwischen Gatsby und React

React stellt das Komponentenmodell von Gatsby bereit. Entwickler setzen Layouts, Navigation, Vorlagen und interaktive Funktionen aus React-Komponenten zusammen, während Gatsby das umgebende Framework für Routing, Datenbeschaffung, Seitenerstellung, Asset-Verarbeitung und die Produktionsausgabe bereitstellt.

Gatsby ist daher weder ein Ersatz für React noch lediglich eine Komponentenbibliothek. Es ist ein auf React aufbauendes Website-Framework mit klaren Konventionen. Teams können vertrautes JSX, die Zusammenstellung von Komponenten, Props, State und browserseitige Interaktionen einsetzen und zugleich Gatsby-spezifische APIs für Daten und Rendering verwenden.

Was Gatsby rund um React ergänzt

Bereich	React bietet	Gatsby ergänzt
Benutzeroberfläche	Komponenten und State	Seitenkonventionen, Layouts und Build-Integration
Daten	Auswahlmöglichkeiten für die Datenabfrage auf Anwendungsebene	Eine normalisierte Datenschicht und einen GraphQL-Abfrage-Workflow
Routen	Bausteine für eine Anwendung	Dateibasierte Seiten, programmatische Seitenerstellung und rein clientseitige Routen
Ausgabe	Im Browser gerenderte Benutzeroberflächen	Statisches, verzögertes und zum Anfragezeitpunkt ausgeführtes Seiten-Rendering
Integrationen	Ein allgemeines JavaScript-Ökosystem	Gatsby-Plugins, Themes, Starter und Framework-Lebenszyklus-APIs

Diese Struktur kann für ein React-Team geeignet sein, das eine inhaltsreiche öffentliche Website erstellt. Sie kann unnötig sein, wenn ein kleines Projekt nur wenig Content-Integration benötigt oder seine Anforderungen hauptsächlich denen einer clientseitig gerenderten Anwendung entsprechen.

Die Datenschicht und GraphQL

Die Datenschicht von Gatsby soll unterschiedlichen Inhaltsquellen eine gemeinsame Abfrageschnittstelle bereitstellen. Quell-Plugins rufen Datensätze ab und erstellen Gatsby-Knoten. Gatsby stellt diese Knoten anschließend über ein GraphQL-Schema bereit, das Seiten und Komponenten abfragen können.

Eine Website könnte Markdown-Dateien, Bilder, ein Headless-Content-System und ausgewählte Servicedaten kombinieren. Statt jede Seite mit dem ursprünglichen Antwortformat jeder Quelle vertraut machen zu müssen, kann Gatsby die relevanten Datensätze über einen gemeinsamen Graphen bereitstellen.

Ein typischer Content-Pfad sieht folgendermaßen aus:

1. Eine Datei, ein Dienst oder eine Content-Plattform enthält das ursprüngliche Material.
2. Ein Quell-Plugin importiert dieses Material während des Datenbeschaffungsprozesses von Gatsby.
3. Gatsby stellt die importierten Datensätze als Knoten dar und erstellt ein Schema.
4. GraphQL-Abfragen fordern die Felder an, die eine Seite oder Komponente benötigt.
5. Eine Vorlage verwendet das Abfrageergebnis, um die Seite zu erzeugen.
6. Gatsby rendert die Seite entsprechend dem ausgewählten Rendering-Modus.

GraphQL ist für den Workflow von Gatsby mit bezogenen Daten zentral, ersetzt aber nicht jeden gewöhnlichen React-Wert. Komponenten-Props, lokaler State, Browserereignisse und clientseitige Anfragen können weiterhin außerhalb des Build-Graphen existieren. Entscheidend ist die Frage, ob das gemeinsame Schema von Gatsby die Inhalte vereinfacht, die zu Seiten zusammengesetzt werden müssen.

Die Datenschicht verursacht auch Arbeit. Teams müssen das Verhalten der Quellen, Knotenbeziehungen, Schemaänderungen und Abhängigkeiten von Abfragen verstehen. Ein Graph, der mehrere Systeme vereinheitlicht, kann wertvoll sein, doch seine Build-Kosten und sein Wartungsaufwand sollten mit repräsentativen Inhalten getestet und nicht aus einer Starter-Website abgeleitet werden.

Quell-Plugins und das umfassendere Erweiterungsmodell

Quell-Plugins verbinden Gatsby mit Daten. Sie können lokale Dateien lesen oder Content-Systeme und Dienste integrieren und anschließend Knoten erstellen, die Teil der GraphQL-Schicht werden. Dadurch unterscheiden sie sich von Plugins, die Verarbeitung, Analysen, Styling, Bildunterstützung oder anderes Lebenszyklusverhalten hinzufügen.

Gatsby verpackt wiederverwendbare Arbeit in drei miteinander verbundenen Formen:

• Plugins ergänzen eine Quelle, Transformation, Integration oder Framework-Funktion.
• Themes bündeln wiederverwendbare Gatsby-Konfigurationen und -Funktionen, die Websites erweitern können.
• Starter stellen ein Ausgangsprojekt bereit, das Entwickler kopieren und anpassen.

Ein Starter kann die Einrichtung verkürzen, doch seine Abhängigkeiten und Konventionen gehen in die Verantwortung des übernehmenden Teams über. Ein Theme kann Funktionen über mehrere Websites hinweg konsistent halten, doch Teams sollten verstehen, was es steuert. Ein Plugin kann individuellen Integrationscode vermeiden, wobei seine Kompatibilität und Wartung einzeln bewertet werden müssen.

Die Existenz einer großen Plugin-Kategorie beweist nicht, dass ein bestimmtes Paket die Gatsby-Version, Datenquelle oder das Bereitstellungsmodell eines Teams unterstützt. Bei einer praktischen Bewertung sollten die konkret benötigten Pakete ermittelt, ihre Dokumentation und Repository-Aktivität geprüft und die Pakete innerhalb der vorgesehenen Architektur getestet werden.

Rendering-Optionen in Gatsby

Gatsby wurde anfangs stark mit der statischen Website-Generierung verbunden, doch seine Dokumentation definiert inzwischen mehrere Rendering-Optionen. Diese können pro Seite ausgewählt werden, sodass ein öffentlicher Artikel, ein großes Archiv, eine von der Anfrage abhängige Route und ein Anwendungsbereich unterschiedliche Produktionsmodelle verwenden können.

Rendering-Option	Wann die Seite erzeugt wird	Geeignete Fragestellung
Static Site Generation (SSG)	Während des Builds	Sind die für die Seite erforderlichen Inhalte vor der Bereitstellung verfügbar?
Deferred Static Generation (DSG)	Wenn eine verzögerte Seite erstmals angefordert wird	Kann diese Seite vom ersten Build ausgeschlossen werden und unterstützt der Host Gatsby DSG?
Server-Side Rendering (SSR)	Zum Anfragezeitpunkt mithilfe von getServerData	Erfordert die Antwort Daten oder Kontext zum Anfragezeitpunkt?
Clientseitige Route	Im Browser für einen Anwendungspfad	Ist dieser Abschnitt bewusst anwendungsartig gestaltet und was ist verfügbar, bevor JavaScript vollständig ausgeführt wurde?

Statische und verzögerte Seiten

SSG erzeugt HTML und zugehörige Assets während des Builds. Es ist eine naheliegende Option für Inhalte, deren Eingaben im Voraus bekannt sind. Generierte Dateien können unkompliziert verteilt werden, doch eine große Seitenanzahl, aufwendige Abfragen, zahlreiche Inhaltsquellen oder umfangreiche Bildverarbeitung können die Build-Anforderungen erhöhen.

DSG verschiebt ausgewählte Seiten bis zu ihrer ersten Anfrage. Dadurch kann sich die Anzahl der beim ersten Build erstellten Seiten reduzieren, insbesondere wenn eine Website einen langen Bestand selten angeforderter Inhalte besitzt. DSG erfordert außerdem eine Bereitstellungsumgebung, die das verzögerte Generierungsverhalten von Gatsby implementiert; es ist nicht gleichbedeutend damit, lediglich statische Dateien auf einen beliebigen Host hochzuladen.

Rendering zum Anfragezeitpunkt und im Browser

SSR erzeugt mithilfe der Gatsby-API getServerData zum Anfragezeitpunkt eine Antwort. Damit können Seiten ausgeliefert werden, deren Ausgabe von aktuellen Informationen zum Anfragezeitpunkt abhängt. Es führt jedoch Serverausführung, Entscheidungen zur Zwischenspeicherung, Fehlerbehandlung und Infrastrukturanforderungen ein, die eine rein statische Seite vermeidet.

Clientseitige Routen unterstützen Anwendungsbereiche, die im Browser verarbeitet werden. Sie können gemeinsam mit generierten öffentlichen Seiten bestehen, doch Teams sollten Ladezustände, Navigation, Barrierefreiheit und die verfügbaren Inhalte prüfen, bevor clientseitiger Code ausgeführt wird. Öffentliche Auffindbarkeit sollte nicht allein deshalb vorausgesetzt werden, weil eine Browserroute schließlich die richtigen Informationen anzeigt.

Keine Rendering-Bezeichnung garantiert Geschwindigkeit oder Sichtbarkeit in Suchmaschinen. Die Ergebnisse hängen vom Seitendesign, JavaScript, Assets, Datenquellen, Caching, Hosting und der Qualität der Implementierung ab. Gatsby stellt Teams mehrere Architekturmöglichkeiten bereit; es beseitigt nicht die Notwendigkeit, diese zu messen.

Bilder und Content-Produktion

Bilder befinden sich häufig in derselben Content-Pipeline wie Text und strukturierte Datensätze. Gatsby-Plugins können Bilddateien beziehen, transformieren und verarbeitete Assets mit Seitenabfragen verbinden. Komponenten können die ausgewählten Bilddaten anschließend als Teil einer Seitenvorlage rendern.

Ein sinnvoller redaktioneller Workflow trennt die Verantwortlichkeiten:

• Redakteure verwalten Titel, Fließtext, Metadaten und Bildreferenzen in der gewählten Quelle.
• Quell-Plugins importieren diese Datensätze und die referenzierten Assets.
• Die Datenschicht von Gatsby verbindet Content-Knoten mit den erforderlichen Bilddaten.
• Abfragen fordern nur die Felder und Bildvarianten an, die eine Vorlage benötigt.
• Komponenten stellen Bildunterschriften, Alternativtexte, Abmessungen und Layoutverhalten bereit.
• Der Produktions-Build überprüft, dass Datensätze, Assets und Routen gemeinsam aufgelöst werden.

Bildverarbeitung kann die Konsistenz verbessern, bleibt jedoch Build-Arbeit. Teams sollten die tatsächliche Anzahl und Größe der Assets testen, prüfen, wie sich Änderungen auf erneute Builds auswirken, und aussagekräftige Alternativtexte aus der redaktionellen Quelle bewahren. Ein Plugin kann nicht entscheiden, ob ein Bild informativ, dekorativ oder angemessen beschrieben ist.

Wo Gatsby gut geeignet sein kann

Gatsby ist besonders relevant, wenn ein Projekt bereits React verwendet und Inhalte aus mehreren Systemen zusammenführen muss. Sein Datengraph kann eine konsistente Schicht zwischen diesen Quellen und den Seitenvorlagen bereitstellen, die sie verwenden.

Zu den häufigen Situationen, die eine Bewertung wert sind, gehören:

• Dokumentations- oder redaktionelle Websites, die Dateien, Bilder und eine Content-Plattform kombinieren.
• Marketing-Websites mit wiederverwendbaren React-Komponenten und strukturierten Seitendatensätzen.
• Veröffentlichungsprojekte mit mehreren Quellen, die von einer gemeinsamen Abfrageschnittstelle profitieren.
• Bestehende Gatsby-Websites, die auf Seiten-APIs, GraphQL und etablierten Plugins aufbauen.
• Große Inhaltssammlungen, bei denen ausgewählte Seiten für DSG infrage kommen können.
• Websites, die generierte öffentliche Seiten mit Bereichen kombinieren, die zum Anfragezeitpunkt oder clientseitig gerendert werden.

Gatsby kann weniger direkt geeignet sein, wenn ein Projekt eine einzige einfache Inhaltsquelle besitzt, nicht von einem normalisierten Graphen profitiert oder eine Anwendungsarchitektur benötigt, die hauptsächlich auf Vorgängen zum Anfragezeitpunkt und auf der Clientseite basiert. Das ist eine architektonische Beurteilung und kein Urteil über die Qualität des Frameworks.

Abwägungen bei Build und Bereitstellung

Die statische Generierung verlagert Arbeit in die Zeit vor der Bereitstellung. Gatsby muss möglicherweise Quelldaten abrufen, sein Schema konstruieren, Abfragen ausführen, Seiten erstellen, Bilder verarbeiten, Code bündeln und die Ausgabe schreiben. Dauer und Ressourcenanforderungen hängen vom tatsächlichen Projekt ab.

Eine repräsentative Bewertung sollte Folgendes erfassen:

Testbereich	Was überprüft werden sollte
Umfang der Inhalte	Seitenanzahl, Knotenanzahl, Beziehungen und realistische Datensatzgrößen
Zuverlässigkeit der Quellen	Authentifizierung, Ratenbegrenzungen, Ausfälle und reproduzierbarer Abruf
Abfragen	Schemastabilität, Abfragekosten und Fehler nach Inhaltsänderungen
Bilder	Verarbeitungsvolumen, Speichernutzung, Ausgabegröße und redaktionelle Metadaten
Rendering	SSG-Ausgabe, erste DSG-Anfragen, SSR-Antworten und Laden clientseitiger Routen
Bereitstellung	Unterstützung aller ausgewählten Modi, Caching-Verhalten und Wiederherstellung nach Fehlern

Eine kleine Demonstration kann nicht zeigen, wie sich ein vollständiger Katalog verhalten wird. Teams sollten vollständige Builds, inkrementelle Änderungen, sofern unterstützt, Ausfälle von Inhaltsquellen sowie Seiten sowohl am üblichen als auch am extremen Ende des Datensatzes testen.

DSG kann Arbeit aus dem ersten Build heraus verlagern, während SSR Arbeit auf Anfragen verschiebt. Das sind Änderungen des Zeitpunkts und der betrieblichen Verantwortung, keine kostenlosen Leistungsverbesserungen. Der gewählte Host muss das erforderliche Gatsby-Verhalten unterstützen, und das Team sollte verstehen, was bei einer kalten Anfrage oder einem Ausfall eines vorgelagerten Systems geschieht.

Gatsby, Astro und andere Alternativen

Gatsby und Astro können beide bei Bewertungen inhaltsorientierter Websites berücksichtigt werden, organisieren Projekte jedoch unterschiedlich. Gatsby stellt React, seine GraphQL-Datenschicht, Quell-Plugins und APIs zur Seitengenerierung in den Mittelpunkt. Astro sollte anhand seiner eigenen dokumentierten Architektur bewertet und nicht standardmäßig als schnellere oder neuere Antwort betrachtet werden.

Gatsby verdient eine nähere Betrachtung, wenn ein Team React in der gesamten Benutzeroberfläche verwenden möchte, mehrere normalisierte Inhaltsquellen abfragen muss, auf Gatsby-Integrationen angewiesen ist oder eine etablierte Gatsby-Codebasis pflegt. Ein anderes Framework kann einfacher sein, wenn dieser Graph und der Plugin-Lebenszyklus zusätzliche Struktur schaffen würden, ohne ein tatsächliches Content-Problem zu lösen.

Ein sinnvoller Vergleich erstellt in jedem Kandidaten denselben repräsentativen Ausschnitt: eine Inhaltsquelle, eine komplexe Seite, eine Auflistung, Bildverarbeitung, Navigation und den vorgesehenen Bereitstellungsmodus. Vergleichen Sie das Verständnis der Entwickler, das Build-Verhalten, die Browserausgabe, Barrierefreiheit, Hosting-Anforderungen und die Wartungsverantwortung. Vermeiden Sie es, anhand von Standardvorlagen einen universellen Gewinner zu erklären.

Gründer und offizielle Community-Ressourcen

In einer offiziellen Gatsby-Community-Fragerunde, die am 2. April 2020 veröffentlicht wurde, wurde Kyle Mathews als „Gründer @ GatsbyJS“ bezeichnet. Diese datierte Zuschreibung beschreibt seine historische Rolle in dieser Quelle; sie sollte nicht als Aussage über die aktuelle Führung von Gatsby verstanden werden.

Die Dokumentation von Gatsby verweist Entwickler für unterschiedliche Bedürfnisse auf offizielle Community-Kanäle:

• Discord wird als Ort aufgeführt, an dem die Community um Hilfe bei der Entwicklung gebeten werden kann.
• GitHub Discussions unterstützt Diskussionen über das Projekt und seine Funktionen.
• Die Dokumentation zu Beiträgen erläutert Möglichkeiten, sich am Projekt zu beteiligen.
• Das gepflegte Repository gatsbyjs/gatsby enthält den Quellcode des Frameworks, Pakete, Issues und den Beitragsverlauf.

Diese Ressourcen helfen Lesern, die Dokumentation zu überprüfen, Fragen zur Implementierung zu stellen und öffentliche Projektarbeit einzusehen. Ihre Existenz sollte nicht in unbelegte Aussagen über Antwortzeiten, die Langlebigkeit von Paketen oder zukünftige Pläne umgedeutet werden.

Was Teams vor der Einführung von Gatsby entscheiden sollten

1. Inhalte abbilden. Ermitteln Sie jede Quelle, die Beziehungen zwischen Datensätzen, die Aktualisierungshäufigkeit und welche Seiten jedes Feld verwenden. Dadurch wird deutlich, ob die normalisierte GraphQL-Schicht von Gatsby ein relevantes Koordinationsproblem löst.

2. Einen Rendering-Modus zuweisen für repräsentative Seiten. Klären Sie, welche Seiten statisch sein können, welche möglicherweise verzögert werden können, welche getServerData benötigen und welche bewusst clientseitig sind. Überprüfen Sie, dass das Bereitstellungsziel die resultierende Kombination unterstützt.

3. Die konkreten Abhängigkeiten prüfen. Prüfen Sie erforderliche Quell-Plugins, Transformations-Plugins, Themes, Starter und Bildwerkzeuge anhand der Gatsby-Version des Projekts. Erstellen Sie Prototypen für unsichere Integrationen, bevor diese zu architektonischen Abhängigkeiten werden.

4. Eine produktionsnahe Arbeitslast testen. Gatsby bietet ein zusammenhängendes React- und Content-Framework, doch seine Eignung ergibt sich aus der Übereinstimmung mit den Daten, Seiten, Integrationen und dem Hosting-Modell des Teams und nicht aus allgemeinen Versprechen über Geschwindigkeit, Suchmaschinenrankings oder mühelose Skalierung.