gatsbyjs.com

Di cosa tratta Gatsby?

Gatsby è un framework React per creare siti web a partire da componenti e contenuti strutturati. Può raccogliere dati da file, sistemi di gestione dei contenuti, API e altri servizi; organizzare tali dati attraverso un livello GraphQL; e utilizzarli per creare pagine con rendering statico, differito, lato server o lato client.

Gatsby è il framework. gatsbyjs.com è il suo sito web ufficiale e il centro della documentazione. Questa distinzione è importante perché l’architettura, i pacchetti e il repository del framework sono gli argomenti di questa guida, mentre il dominio è il luogo in cui il progetto pubblica la propria documentazione.

Un progetto Gatsby riunisce comunemente diversi aspetti in un unico flusso di lavoro:

• I componenti React definiscono l’interfaccia e gli elementi riutilizzabili delle pagine.
• I plugin sorgente importano contenuti e dati da sistemi locali o remoti.
• Gatsby normalizza i record acquisiti trasformandoli in nodi nel proprio livello dati.
• Le query GraphQL selezionano i campi necessari a pagine e componenti.
• Le API per le pagine e i template trasformano i dati in route.
• Le impostazioni di rendering determinano quando viene prodotta ciascuna pagina.

Il rapporto tra Gatsby e React

React fornisce il modello a componenti di Gatsby. Gli sviluppatori compongono layout, navigazione, template e funzionalità interattive a partire da componenti React, mentre Gatsby fornisce il framework circostante per routing, acquisizione dei dati, creazione delle pagine, elaborazione delle risorse e output di produzione.

Gatsby non è quindi né un sostituto di React né una semplice libreria di componenti. È un framework per siti web con convenzioni definite, costruito attorno a React. I team possono applicare JSX, composizione dei componenti, props, stato e interazione lato browser già familiari, utilizzando al contempo API specifiche di Gatsby per dati e rendering.

Cosa aggiunge Gatsby a React

Ambito	Cosa fornisce React	Cosa aggiunge Gatsby
Interfaccia	Componenti e stato	Convenzioni per le pagine, layout e integrazione con il processo di build
Dati	Scelte di recupero dei dati a livello di applicazione	Un livello dati normalizzato e un flusso di lavoro basato su query GraphQL
Route	Elementi di base per un’applicazione	Pagine basate su file, creazione programmatica delle pagine e route solo client
Output	Interfacce renderizzate nel browser	Rendering statico, differito e al momento della richiesta
Integrazioni	Un ecosistema JavaScript generale	Plugin, temi, starter e API del ciclo di vita del framework Gatsby

Questa struttura può essere adatta a un team React che crea un sito web pubblico ricco di contenuti. Può essere superflua quando un piccolo progetto prevede poche integrazioni di contenuti o quando i suoi requisiti sono principalmente quelli di un’applicazione renderizzata lato client.

Il livello dati e GraphQL

Il livello dati di Gatsby è progettato per offrire alle diverse fonti di contenuto un’interfaccia di interrogazione comune. I plugin sorgente recuperano i record e creano nodi Gatsby. Gatsby rende quindi tali nodi disponibili attraverso uno schema GraphQL che pagine e componenti possono interrogare.

Un sito potrebbe combinare file Markdown, immagini, un sistema di contenuti headless e dati selezionati da servizi. Invece di richiedere a ogni pagina di comprendere il formato di risposta originale di ciascuna fonte, Gatsby può esporre i record pertinenti attraverso un grafo condiviso.

Un tipico percorso dei contenuti si presenta così:

1. Un file, un servizio o una piattaforma di contenuti conserva il materiale originale.
2. Un plugin sorgente importa tale materiale durante il processo di acquisizione dei dati di Gatsby.
3. Gatsby rappresenta i record importati come nodi e crea uno schema.
4. Le query GraphQL richiedono i campi necessari a una pagina o a un componente.
5. Un template utilizza il risultato della query per produrre la pagina.
6. Gatsby renderizza la pagina secondo la modalità di rendering selezionata.

GraphQL è centrale nel flusso di lavoro dei dati acquisiti di Gatsby, ma non sostituisce ogni normale valore React. Le props dei componenti, lo stato locale, gli eventi del browser e le richieste lato client possono continuare a esistere al di fuori del grafo creato durante la build. La domanda utile è se lo schema condiviso di Gatsby semplifichi i contenuti che devono essere assemblati nelle pagine.

Il livello dati introduce anche del lavoro. I team devono comprendere il comportamento delle fonti, le relazioni tra nodi, le modifiche allo schema e le dipendenze delle query. Un grafo che unifica più sistemi può essere utile, ma il costo di build e l’onere di manutenzione dovrebbero essere verificati con contenuti rappresentativi, anziché dedotti da un sito starter.

Plugin sorgente e modello di estensione più ampio

I plugin sorgente collegano Gatsby ai dati. Possono leggere file locali o integrare sistemi e servizi di contenuti, quindi creare nodi che partecipano al livello GraphQL. Ciò li distingue dai plugin che aggiungono elaborazione, analisi, stili, supporto per le immagini o altri comportamenti del ciclo di vita.

Gatsby organizza il lavoro riutilizzabile in tre forme correlate:

• I plugin aggiungono una fonte, una trasformazione, un’integrazione o una funzionalità del framework.
• I temi racchiudono configurazioni e funzionalità Gatsby riutilizzabili che i siti possono estendere.
• Gli starter forniscono un progetto iniziale che gli sviluppatori possono copiare e adattare.

Uno starter può abbreviare la configurazione, ma le sue dipendenze e convenzioni diventano responsabilità del team che lo adotta. Un tema può mantenere coerenti le funzionalità tra più siti, ma i team dovrebbero capire cosa controlla. Un plugin può evitare codice di integrazione personalizzato, anche se compatibilità e manutenzione devono essere valutate singolarmente.

L’esistenza di un’ampia categoria di plugin non dimostra che un determinato pacchetto supporti la versione di Gatsby, la fonte dati o il modello di distribuzione di un team. Una valutazione pratica dovrebbe identificare i pacchetti esatti richiesti, esaminarne la documentazione e l’attività del repository e testarli all’interno dell’architettura proposta.

Opzioni di rendering in Gatsby

Gatsby è nato con una forte associazione alla generazione di siti statici, ma la sua documentazione ora definisce diverse opzioni di rendering. Queste possono essere selezionate per pagina, consentendo a un articolo pubblico, un archivio di grandi dimensioni, una route dipendente dalla richiesta e un’area applicativa di utilizzare modelli di produzione differenti.

Opzione di rendering	Quando viene prodotta la pagina	Domanda appropriata da porre
Generazione di siti statici (SSG)	Durante la build	Il contenuto necessario alla pagina è disponibile prima della distribuzione?
Generazione statica differita (DSG)	Quando una pagina differita viene richiesta per la prima volta	Questa pagina può essere esclusa dalla build iniziale e l’host supporta Gatsby DSG?
Rendering lato server (SSR)	Al momento della richiesta, utilizzando getServerData	La risposta richiede dati o contesto disponibili al momento della richiesta?
Route lato client	Nel browser per un percorso applicativo	Questa sezione è intenzionalmente simile a un’applicazione e cosa è disponibile prima che JavaScript termini?

Pagine statiche e differite

SSG produce HTML e risorse correlate durante la build. È un’opzione naturale per contenuti i cui input sono noti in anticipo. I file generati possono essere semplici da distribuire, ma un elevato numero di pagine, query costose, numerose fonti di contenuto o un’elaborazione intensiva delle immagini possono aumentare le esigenze della build.

DSG rimanda la produzione delle pagine selezionate fino alla loro prima richiesta. Ciò può ridurre il numero di pagine create durante la build iniziale, soprattutto quando un sito ha una lunga coda di contenuti richiesti raramente. Richiede inoltre un ambiente di distribuzione che implementi il comportamento di generazione differita di Gatsby; non equivale a caricare soltanto file statici su un host qualsiasi.

Rendering al momento della richiesta e nel browser

SSR genera una risposta al momento della richiesta attraverso l’API getServerData di Gatsby. Può servire pagine il cui output dipende da informazioni correnti disponibili al momento della richiesta, ma introduce esecuzione sul server, decisioni sulla cache, gestione degli errori e requisiti infrastrutturali che una pagina puramente statica evita.

Le route lato client supportano sezioni applicative gestite nel browser. Possono coesistere con pagine pubbliche generate, ma i team dovrebbero esaminare gli stati di caricamento, la navigazione, l’accessibilità e i contenuti disponibili prima dell’esecuzione del codice lato client. La reperibilità pubblica non dovrebbe essere data per scontata soltanto perché una route del browser finisce per mostrare le informazioni corrette.

Nessuna etichetta di rendering garantisce velocità o visibilità nei motori di ricerca. I risultati dipendono dal design della pagina, da JavaScript, dalle risorse, dalle fonti dati, dalla cache, dall’hosting e dalla qualità dell’implementazione. Gatsby offre ai team diverse opzioni architetturali; non elimina la necessità di misurarle.

Immagini e produzione dei contenuti

Le immagini spesso rientrano nello stesso flusso di contenuti del testo e dei record strutturati. I plugin Gatsby possono acquisire file di immagini, trasformarli e collegare le risorse elaborate alle query delle pagine. I componenti possono quindi renderizzare i dati delle immagini selezionati come parte di un template di pagina.

Un flusso editoriale utile separa le responsabilità:

• Gli editor gestiscono titoli, contenuto del corpo, metadati e riferimenti alle immagini nella fonte scelta.
• I plugin sorgente importano tali record e le risorse a cui fanno riferimento.
• Il livello dati di Gatsby collega i nodi dei contenuti ai dati delle immagini richiesti.
• Le query richiedono soltanto i campi e le varianti di immagini necessari a un template.
• I componenti forniscono didascalie, testo alternativo, dimensioni e comportamento del layout.
• La build di produzione verifica che record, risorse e route si risolvano insieme.

L’elaborazione delle immagini può migliorare la coerenza, ma rimane comunque un’attività della build. I team dovrebbero verificare il numero e le dimensioni reali delle risorse, confermare in che modo le modifiche influiscano sulle nuove build e preservare il testo alternativo significativo proveniente dalla fonte editoriale. Un plugin non può decidere se un’immagine sia informativa, decorativa o descritta adeguatamente.

Dove Gatsby può essere adatto

Gatsby è particolarmente pertinente quando un progetto utilizza già React e deve assemblare contenuti provenienti da diversi sistemi. Il suo grafo dei dati può fornire un livello coerente tra tali fonti e i template di pagina che le utilizzano.

Le situazioni comuni che vale la pena valutare includono:

• Siti di documentazione o editoriali che combinano file, immagini e una piattaforma di contenuti.
• Siti di marketing con componenti React riutilizzabili e record strutturati delle pagine.
• Progetti di pubblicazione con più fonti che traggono vantaggio da un’unica interfaccia di interrogazione.
• Siti Gatsby esistenti costruiti attorno ad API per le pagine, GraphQL e plugin consolidati.
• Grandi raccolte di contenuti in cui alcune pagine potrebbero essere candidate per DSG.
• Siti che combinano pagine pubbliche generate con sezioni al momento della richiesta o lato client.

Gatsby può essere una soluzione meno diretta quando un progetto ha una sola fonte di contenuti semplice, non trae vantaggio da un grafo normalizzato o necessita di un’architettura applicativa incentrata principalmente su operazioni al momento della richiesta e lato client. Si tratta di una valutazione architetturale, non di un giudizio sulla qualità del framework.

Compromessi di build e distribuzione

La generazione statica sposta il lavoro prima della distribuzione. Gatsby potrebbe dover recuperare i dati dalle fonti, costruire il proprio schema, eseguire query, creare pagine, elaborare immagini, raggruppare il codice e scrivere l’output. La durata e i requisiti di risorse dipendono dal progetto reale.

Una valutazione rappresentativa dovrebbe registrare:

Area di test	Cosa verificare
Dimensione dei contenuti	Numero di pagine, numero di nodi, relazioni e dimensioni realistiche dei record
Affidabilità delle fonti	Autenticazione, limiti di frequenza, errori e recupero ripetibile
Query	Stabilità dello schema, costo delle query ed errori dopo le modifiche ai contenuti
Immagini	Volume di elaborazione, utilizzo della memoria, dimensioni dell’output e metadati editoriali
Rendering	Output SSG, prime richieste DSG, risposte SSR e caricamento delle route client
Distribuzione	Supporto per ogni modalità scelta, comportamento della cache e ripristino dagli errori

Una piccola dimostrazione non può stabilire come si comporterà un catalogo completo. I team dovrebbero testare build pulite, modifiche incrementali dove supportate, indisponibilità delle fonti di contenuto e pagine situate sia nella parte comune sia agli estremi dell’insieme di dati.

DSG può spostare il lavoro dalla build iniziale, mentre SSR lo sposta sulle richieste. Si tratta di cambiamenti nella tempistica e nella responsabilità operativa, non di miglioramenti gratuiti delle prestazioni. L’host scelto deve supportare il comportamento Gatsby richiesto e il team dovrebbe capire cosa accade durante una richiesta a freddo o un errore a monte.

Gatsby, Astro e altre alternative

Gatsby e Astro possono entrambi comparire nelle valutazioni di siti web basati sui contenuti, ma organizzano i progetti in modo diverso. Gatsby rende centrali React, il proprio livello dati GraphQL, i plugin sorgente e le API per la generazione delle pagine. Astro dovrebbe essere valutato in base alla propria architettura documentata, anziché essere considerato automaticamente una risposta più veloce o più recente.

Gatsby merita maggiore considerazione quando un team vuole utilizzare React in tutta l’interfaccia, deve interrogare più fonti di contenuti normalizzate, si affida alle integrazioni Gatsby o mantiene una base di codice Gatsby consolidata. Un altro framework può essere più semplice quando quel grafo e il ciclo di vita dei plugin aggiungerebbero struttura senza risolvere un reale problema di contenuti.

Un confronto utile realizza la stessa sezione rappresentativa in ciascun candidato: una fonte di contenuti, una pagina complessa, un elenco, la gestione delle immagini, la navigazione e la modalità di distribuzione prevista. Confrontate la comprensione da parte degli sviluppatori, il comportamento della build, l’output nel browser, l’accessibilità, i requisiti di hosting e la responsabilità della manutenzione. Evitate di dichiarare un vincitore universale sulla base dei template predefiniti.

Fondatore e risorse ufficiali della comunità

In una sessione ufficiale di domande e risposte della comunità Gatsby pubblicata il 2 aprile 2020, Kyle Mathews è stato identificato come “Fondatore @ GatsbyJS”. Tale attribuzione datata descrive il suo ruolo storico in quella fonte; non dovrebbe essere interpretata come un’affermazione sull’attuale leadership di Gatsby.

La documentazione di Gatsby indirizza gli sviluppatori verso canali ufficiali della comunità per esigenze differenti:

• Discord è indicato come un luogo in cui chiedere assistenza alla comunità degli sviluppatori.
• GitHub Discussions supporta le discussioni sul progetto e sulle funzionalità.
• La documentazione per contribuire illustra i modi per partecipare al progetto.
• Il repository gatsbyjs/gatsby, mantenuto attivamente, contiene il codice sorgente del framework, i pacchetti, le segnalazioni e la cronologia dei contributi.

Queste risorse aiutano i lettori a verificare la documentazione, porre domande sull’implementazione ed esaminare il lavoro pubblico del progetto. La loro esistenza non dovrebbe essere trasformata in affermazioni non supportate sui tempi di risposta, sulla longevità dei pacchetti o sui piani futuri.

Cosa dovrebbero decidere i team prima di adottare Gatsby

1. Mappare i contenuti. Identificate ogni fonte, le relazioni tra i record, la frequenza di aggiornamento e quali pagine utilizzano ciascun campo. Ciò rivela se il livello GraphQL normalizzato di Gatsby risolve un problema significativo di coordinamento.

2. Assegnare una modalità di rendering alle pagine rappresentative. Confermate quali pagine possono essere statiche, quali potrebbero essere differite, quali richiedono getServerData e quali sono deliberatamente lato client. Verificate che la destinazione di distribuzione supporti la combinazione risultante.

3. Controllare l’insieme concreto delle dipendenze. Verificate i plugin sorgente, i plugin di trasformazione, i temi, gli starter e gli strumenti per le immagini richiesti rispetto alla versione di Gatsby del progetto. Create prototipi delle integrazioni incerte prima di renderle dipendenze architetturali.

4. Testare un carico di lavoro simile a quello di produzione. Gatsby offre un framework coerente per React e i contenuti, ma la sua idoneità deriva dall’allineamento con dati, pagine, integrazioni e modello di hosting del team, non da promesse generiche su velocità, posizionamento nei motori di ricerca o scalabilità senza sforzo.