gatsbyjs.com

Waar gaat Gatsby over?

Gatsby is een React-framework voor het bouwen van websites met componenten en gestructureerde content. Het kan gegevens verzamelen uit bestanden, contentmanagementsystemen, API's en andere diensten; deze gegevens organiseren via een GraphQL-laag; en ze gebruiken om pagina's te maken met statische, uitgestelde, server-side of client-side rendering.

Gatsby is het framework. gatsbyjs.com is de officiële website en documentatiehub. Dat onderscheid is belangrijk omdat de architectuur, pakketten en repository van het framework het onderwerp van deze gids zijn, terwijl het domein de plek is waar het project zijn documentatie publiceert.

Een Gatsby-project brengt doorgaans verschillende aandachtspunten samen in één workflow:

• React-componenten definiëren de interface en herbruikbare pagina-elementen.
• Bronplug-ins importeren content en gegevens uit lokale of externe systemen.
• Gatsby normaliseert records uit bronnen tot nodes in zijn gegevenslaag.
• GraphQL-query's selecteren de velden die pagina's en componenten nodig hebben.
• Pagina-API's en templates zetten gegevens om in routes.
• Renderinginstellingen bepalen wanneer elke pagina wordt geproduceerd.

Hoe Gatsby zich verhoudt tot React

React levert het componentmodel van Gatsby. Ontwikkelaars stellen lay-outs, navigatie, templates en interactieve functies samen uit React-componenten, terwijl Gatsby het omringende framework levert voor routering, gegevensbronnen, pagina-aanmaak, assetverwerking en productie-uitvoer.

Gatsby is daarom geen vervanging voor React en ook niet slechts een componentbibliotheek. Het is een eigenzinnig websiteframework dat rond React is gebouwd. Teams kunnen vertrouwde JSX, componentsamenstelling, props, state en interactie aan de browserzijde toepassen, terwijl ze Gatsby-specifieke API's voor gegevens en rendering gebruiken.

Wat Gatsby aan React toevoegt

Aandachtspunt	React levert	Gatsby voegt toe
Interface	Componenten en state	Paginaconventies, lay-outs en buildintegratie
Gegevens	Keuzes voor ophalen op applicatieniveau	Een genormaliseerde gegevenslaag en workflow met GraphQL-query's
Routes	Bouwstenen voor een applicatie	Bestandsgebaseerde pagina's, programmatische pagina-aanmaak en routes die alleen aan de clientzijde bestaan
Uitvoer	In de browser gerenderde interfaces	Statische, uitgestelde en tijdens verzoeken gerenderde pagina's
Integraties	Een algemeen JavaScript-ecosysteem	Gatsby-plug-ins, thema's, starters en lifecycle-API's van het framework

Deze structuur kan geschikt zijn voor een React-team dat een contentrijke openbare website bouwt. Ze kan overbodig zijn wanneer een klein project weinig contentintegratie heeft of wanneer de vereisten voornamelijk die van een client-gerenderde applicatie zijn.

De gegevenslaag en GraphQL

De gegevenslaag van Gatsby is ontworpen om verschillende contentbronnen een gemeenschappelijke queryinterface te geven. Bronplug-ins halen records op en maken Gatsby-nodes. Gatsby stelt deze nodes vervolgens beschikbaar via een GraphQL-schema dat pagina's en componenten kunnen bevragen.

Een site kan Markdown-bestanden, afbeeldingen, een headless contentsysteem en geselecteerde servicegegevens combineren. In plaats van elke pagina de oorspronkelijke antwoordindeling van iedere bron te laten begrijpen, kan Gatsby de relevante records via een gedeelde graaf beschikbaar stellen.

Een gebruikelijk contentpad ziet er als volgt uit:

1. Een bestand, dienst of contentplatform bevat het oorspronkelijke materiaal.
2. Een bronplug-in importeert dat materiaal tijdens het proces waarmee Gatsby gegevens uit bronnen ophaalt.
3. Gatsby vertegenwoordigt de geïmporteerde records als nodes en bouwt een schema.
4. GraphQL-query's vragen de velden op die een pagina of component nodig heeft.
5. Een template gebruikt het queryresultaat om de pagina te produceren.
6. Gatsby rendert de pagina volgens de geselecteerde renderingmodus.

GraphQL staat centraal in Gatsby's workflow voor gegevens uit bronnen, maar vervangt niet elke gewone React-waarde. Componentprops, lokale state, browsergebeurtenissen en client-side verzoeken kunnen nog steeds buiten de graaf voor buildtijd bestaan. De nuttige vraag is of het gedeelde schema van Gatsby de content vereenvoudigt die tot pagina's moet worden samengesteld.

De gegevenslaag brengt ook werk met zich mee. Teams moeten inzicht hebben in het gedrag van bronnen, relaties tussen nodes, schemawijzigingen en queryafhankelijkheden. Een graaf die meerdere systemen verenigt kan waardevol zijn, maar de buildkosten en onderhoudslast ervan moeten worden getest met representatieve content in plaats van te worden afgeleid uit een startersite.

Bronplug-ins en het bredere uitbreidingsmodel

Bronplug-ins verbinden Gatsby met gegevens. Ze kunnen lokale bestanden lezen of contentsystemen en diensten integreren en vervolgens nodes maken die deelnemen aan de GraphQL-laag. Dit onderscheidt ze van plug-ins die verwerking, analytics, styling, ondersteuning voor afbeeldingen of ander lifecycle-gedrag toevoegen.

Gatsby verpakt herbruikbaar werk in drie verwante vormen:

• Plug-ins voegen een bron, transformatie, integratie of frameworkmogelijkheid toe.
• Thema's verpakken herbruikbare Gatsby-configuratie en -functionaliteit die sites kunnen uitbreiden.
• Starters bieden een oorspronkelijk project dat ontwikkelaars kopiëren en aanpassen.

Een starter kan de configuratie verkorten, maar de afhankelijkheden en conventies ervan worden de verantwoordelijkheid van het team dat hem overneemt. Een thema kan functionaliteit consistent houden tussen sites, maar teams moeten begrijpen wat het beheert. Een plug-in kan aangepaste integratiecode voorkomen, hoewel de compatibiliteit en het onderhoud ervan afzonderlijk moeten worden beoordeeld.

Het bestaan van een grote categorie plug-ins bewijst niet dat een bepaald pakket de Gatsby-versie, gegevensbron of het implementatiemodel van een team ondersteunt. Een praktische beoordeling moet de exact benodigde pakketten identificeren, hun documentatie en repositoryactiviteit inspecteren en ze binnen de voorgestelde architectuur testen.

Renderingopties in Gatsby

Gatsby werd aanvankelijk sterk geassocieerd met het genereren van statische sites, maar de documentatie definieert nu verschillende renderingkeuzes. Deze kunnen per pagina worden geselecteerd, waardoor een openbaar artikel, een groot archief, een route die afhankelijk is van het verzoek en een applicatiegedeelte verschillende productiemodellen kunnen gebruiken.

Renderingoptie	Wanneer de pagina wordt geproduceerd	Geschikte vraag om te stellen
Static Site Generation (SSG)	Tijdens de build	Is de vereiste content van de pagina vóór implementatie beschikbaar?
Deferred Static Generation (DSG)	Wanneer een uitgestelde pagina voor het eerst wordt opgevraagd	Kan deze pagina van de oorspronkelijke build worden uitgesloten en ondersteunt de host Gatsby DSG?
Server-Side Rendering (SSR)	Tijdens het verzoek, met getServerData	Vereist het antwoord gegevens of context die tijdens het verzoek beschikbaar zijn?
Client-side route	In de browser voor een applicatiepad	Is dit gedeelte bewust applicatieachtig en wat is beschikbaar voordat JavaScript klaar is?

Statische en uitgestelde pagina's

SSG produceert HTML en gerelateerde assets tijdens de build. Het is een natuurlijke optie voor content waarvan de invoer vooraf bekend is. Gegenereerde bestanden kunnen eenvoudig te distribueren zijn, maar een groot aantal pagina's, kostbare query's, talrijke contentbronnen of intensieve afbeeldingsverwerking kunnen de buildvereisten verhogen.

DSG stelt geselecteerde pagina's uit tot hun eerste verzoek. Dit kan het aantal pagina's verminderen dat tijdens de oorspronkelijke build wordt gemaakt, vooral wanneer een site een lange staart van zelden opgevraagde content heeft. Het vereist ook een implementatieomgeving die het gedrag voor uitgestelde generatie van Gatsby implementeert; het is niet hetzelfde als alleen statische bestanden naar een willekeurige host uploaden.

Rendering tijdens verzoeken en in de browser

SSR genereert tijdens het verzoek een antwoord via Gatsby's getServerData-API. Het kan pagina's leveren waarvan de uitvoer afhankelijk is van actuele informatie tijdens het verzoek, maar introduceert serveruitvoering, beslissingen over caching, foutafhandeling en infrastructuurvereisten die een volledig statische pagina vermijdt.

Client-side routes ondersteunen applicatiegedeelten die in de browser worden afgehandeld. Ze kunnen naast gegenereerde openbare pagina's bestaan, maar teams moeten laadstatussen, navigatie, toegankelijkheid en de beschikbare content voordat client-side code wordt uitgevoerd onderzoeken. Openbare vindbaarheid mag niet worden aangenomen alleen omdat een browserroute uiteindelijk de juiste informatie toont.

Geen enkel renderinglabel garandeert snelheid of zichtbaarheid in zoekmachines. Resultaten zijn afhankelijk van paginaontwerp, JavaScript, assets, gegevensbronnen, caching, hosting en implementatiekwaliteit. Gatsby biedt teams verschillende architectuuropties; het neemt de noodzaak om ze te meten niet weg.

Afbeeldingen en contentproductie

Afbeeldingen bevinden zich vaak in dezelfde contentpijplijn als tekst en gestructureerde records. Gatsby-plug-ins kunnen afbeeldingsbestanden als bron gebruiken, ze transformeren en verwerkte assets verbinden met paginaquery's. Componenten kunnen vervolgens de geselecteerde afbeeldingsgegevens renderen als onderdeel van een paginatemplate.

Een nuttige redactionele workflow scheidt verantwoordelijkheden:

• Redacteuren beheren titels, hoofdcontent, metadata en afbeeldingsverwijzingen in de gekozen bron.
• Bronplug-ins importeren deze records en de assets waarnaar ze verwijzen.
• De gegevenslaag van Gatsby verbindt contentnodes met de vereiste afbeeldingsgegevens.
• Query's vragen alleen de velden en afbeeldingsvarianten op die een template nodig heeft.
• Componenten leveren bijschriften, alternatieve tekst, afmetingen en lay-outgedrag.
• De productiebuild verifieert dat records, assets en routes gezamenlijk worden opgelost.

Afbeeldingsverwerking kan de consistentie verbeteren, maar blijft buildwerk. Teams moeten het werkelijke aantal en de werkelijke grootte van assets testen, bevestigen hoe wijzigingen rebuilds beïnvloeden en betekenisvolle alternatieve tekst uit de redactionele bron behouden. Een plug-in kan niet bepalen of een afbeelding informatief of decoratief is, of passend is beschreven.

Waar Gatsby goed kan passen

Gatsby is met name relevant wanneer een project React al gebruikt en content uit verschillende systemen moet samenvoegen. De gegevensgraaf kan een consistente laag vormen tussen deze bronnen en de paginatemplates die ze gebruiken.

Veelvoorkomende situaties die het beoordelen waard zijn, zijn onder meer:

• Documentatie- of redactionele sites die bestanden, afbeeldingen en een contentplatform combineren.
• Marketingsites met herbruikbare React-componenten en gestructureerde paginarecords.
• Publicatieprojecten met meerdere bronnen die profiteren van één queryinterface.
• Bestaande Gatsby-sites die rond pagina-API's, GraphQL en gevestigde plug-ins zijn gebouwd.
• Grote contentverzamelingen waarin geselecteerde pagina's kandidaten voor DSG kunnen zijn.
• Sites die gegenereerde openbare pagina's combineren met gedeelten tijdens verzoeken of aan de clientzijde.

Gatsby kan een minder directe keuze zijn wanneer een project één eenvoudige contentbron heeft, niet profiteert van een genormaliseerde graaf of een applicatiearchitectuur nodig heeft die voornamelijk gericht is op handelingen tijdens verzoeken en aan de clientzijde. Dat is een architectonisch oordeel, geen uitspraak over de kwaliteit van het framework.

Afwegingen rond build en implementatie

Statische generatie verplaatst werk naar vóór de implementatie. Gatsby moet mogelijk brongegevens ophalen, zijn schema opbouwen, query's uitvoeren, pagina's maken, afbeeldingen verwerken, code bundelen en uitvoer schrijven. De duur en benodigde middelen zijn afhankelijk van het echte project.

Een representatieve beoordeling moet het volgende vastleggen:

Testgebied	Wat te verifiëren
Contentschaal	Aantal pagina's, aantal nodes, relaties en realistische recordgroottes
Betrouwbaarheid van bronnen	Authenticatie, frequentielimieten, storingen en herhaalbaar ophalen
Query's	Schemastabiliteit, querykosten en fouten na contentwijzigingen
Afbeeldingen	Verwerkingsvolume, geheugengebruik, uitvoergrootte en redactionele metadata
Rendering	SSG-uitvoer, eerste DSG-verzoeken, SSR-antwoorden en het laden van clientroutes
Implementatie	Ondersteuning voor elke gekozen modus, cachinggedrag en herstel na storingen

Een kleine demonstratie kan niet vaststellen hoe een volledige catalogus zich zal gedragen. Teams moeten schone builds, incrementele wijzigingen waar ondersteund, uitval van contentbronnen en pagina's aan zowel de gebruikelijke als uiterste kanten van de gegevensverzameling testen.

DSG kan werk uit de oorspronkelijke build verplaatsen, terwijl SSR werk naar verzoeken verplaatst. Dat zijn wijzigingen in timing en operationele verantwoordelijkheid, geen gratis prestatieverbeteringen. De gekozen host moet het vereiste Gatsby-gedrag ondersteunen en het team moet begrijpen wat er gebeurt tijdens een koud verzoek of een storing bij een upstreambron.

Gatsby, Astro en andere alternatieven

Gatsby en Astro kunnen beide voorkomen in beoordelingen voor contentgestuurde websites, maar ze organiseren projecten op verschillende manieren. Gatsby stelt React, zijn GraphQL-gegevenslaag, bronplug-ins en API's voor paginageneratie centraal. Astro moet op basis van zijn eigen gedocumenteerde architectuur worden beoordeeld in plaats van standaard als een sneller of nieuwer antwoord te worden behandeld.

Gatsby verdient nadere overweging wanneer een team React in de hele interface wil gebruiken, verschillende genormaliseerde contentbronnen moet bevragen, afhankelijk is van Gatsby-integraties of een gevestigde Gatsby-codebase onderhoudt. Een ander framework kan eenvoudiger zijn wanneer die graaf en de plug-in-lifecycle structuur zouden toevoegen zonder een echt contentprobleem op te lossen.

Een nuttige vergelijking bouwt in elke kandidaat hetzelfde representatieve onderdeel: één contentbron, één complexe pagina, een overzicht, afbeeldingsverwerking, navigatie en de beoogde implementatiemodus. Vergelijk het begrip bij ontwikkelaars, buildgedrag, browseruitvoer, toegankelijkheid, hostingvereisten en onderhoudsverantwoordelijkheid. Wijs geen universele winnaar aan op basis van standaardtemplates.

Oprichter en officiële communitybronnen

In een officiële Gatsby-community-Q&A die op 2 april 2020 werd gepubliceerd, werd Kyle Mathews aangeduid als “Oprichter @ GatsbyJS.” Deze gedateerde toeschrijving beschrijft zijn historische rol in die bron; ze mag niet worden gelezen als een bewering over het huidige leiderschap van Gatsby.

De documentatie van Gatsby verwijst ontwikkelaars voor verschillende behoeften naar officiële communitykanalen:

• Discord wordt vermeld als plek om de community om hulp voor ontwikkelaars te vragen.
• GitHub Discussions ondersteunt discussies over het project en functies.
• De documentatie over bijdragen legt uit hoe mensen aan het project kunnen deelnemen.
• De onderhouden gatsbyjs/gatsby-repository bevat de broncode van het framework, pakketten, issues en bijdragegeschiedenis.

Deze bronnen helpen lezers documentatie te verifiëren, implementatievragen te stellen en openbaar projectwerk te inspecteren. Hun bestaan mag niet worden omgezet in ongefundeerde beweringen over reactietijden, de levensduur van pakketten of toekomstplannen.

Wat teams moeten beslissen voordat ze Gatsby adopteren

1. Breng de content in kaart. Identificeer elke bron, de relaties tussen records, de updatefrequentie en welke pagina's elk veld gebruiken. Dit maakt duidelijk of Gatsby's genormaliseerde GraphQL-laag een betekenisvol coördinatieprobleem oplost.

2. Wijs een renderingmodus toe aan representatieve pagina's. Bevestig welke pagina's statisch kunnen zijn, welke mogelijk kunnen worden uitgesteld, welke getServerData vereisen en welke bewust client-side zijn. Verifieer dat het implementatiedoel de resulterende combinatie ondersteunt.

3. Controleer de concrete verzameling afhankelijkheden. Controleer vereiste bronplug-ins, transformatieplug-ins, thema's, starters en afbeeldingstools aan de hand van de Gatsby-versie van het project. Maak prototypes van onzekere integraties voordat ze architectonische afhankelijkheden worden.

4. Test een werklast die op productie lijkt. Gatsby biedt een samenhangend React- en contentframework, maar de geschiktheid ervan komt voort uit de aansluiting op de gegevens, pagina's, integraties en het hostingmodel van het team, niet uit algemene beloften over snelheid, zoekposities of moeiteloze schaalbaarheid.