Kodėl Gatsby vis dar aktualus 2024-aisiais
Kai prieš kelerius metus pirmą kartą išgirdau apie Gatsby, atrodė, kad tai dar vienas React framework’as, kuris greitai dings iš radaro. Bet štai – jis ne tik neišnyko, bet ir toliau lieka vienu iš populiariausių static site generatorių. Taip, žinau, dabar visi kalba apie Next.js, Astro ir kitus naujokus, bet Gatsby turi savo nišą ir ją užpildo puikiai.
Gatsby iš esmės yra React-based framework’as, kuris generuoja statinius HTML failus. Skamba paprasta, bet po gaubtu slypi GraphQL duomenų sluoksnis, galingas plugin’ų ekosistema ir optimizacijos, kurias rankiniu būdu įgyvendinti užtruktų amžinybę. Jei kada nors kūrėte portfolio, blog’ą ar dokumentacijos puslapį, tikrai susidūrėte su dilema: WordPress? Custom sprendimas? SPA? Gatsby čia siūlo kompromisą tarp greičio, kūrėjo patirties ir galutinio rezultato.
Kas man patinka labiausiai – tai kad Gatsby neprievartauja. Galite pradėti nuo paprasto starter’io ir palaipsniui pridėti sudėtingumo. O kai reikia SEO, greičio ar prieinamumo – visa tai jau įkepinta į framework’ą.
Kaip Gatsby veikia po gaubtu
Pirmą kartą paleidus gatsby develop, gali atrodyti, kad vyksta kažkas panašaus į Next.js. Bet skirtumas fundamentalus. Gatsby build metu iš tikrųjų generuoja visus galimus HTML failus iš anksto. Tai reiškia, kad jūsų serveris (ar CDN) tiesiog atiduoda gatavus failus – jokio server-side rendering’o, jokių duomenų bazių užklausų.
Štai kaip tai veikia praktiškai: jūs rašote React komponentus, apibrėžiate duomenų šaltinius (Markdown failai, CMS, API), o Gatsby build proceso metu:
- Surenka visus duomenis per GraphQL
- Paleidžia React komponentus su tais duomenimis
- Sugeneruoja statinius HTML failus kiekvienam route’ui
- Optimizuoja paveikslėlius, CSS, JavaScript
- Sukuria prefetch strategijas greičiau navigacijai
Rezultatas? Pirmas puslapio įkėlimas greitesnis nei daugelio SPA, o vėliau navigacija tarp puslapių vyksta beveik akimirksniu, nes Gatsby po gaubtu naudoja React Router ir prefetch’ina kitus puslapius.
Vienas dalykas, kuris man asmeniškai kėlė klausimų pradžioje – kodėl GraphQL? Atrodo kaip overkill’as paprastam blog’ui. Bet kai pradedi dirbti su keliais duomenų šaltiniais (pvz., Markdown failai + Contentful + REST API), GraphQL sluoksnis tampa išganymu. Visi duomenys prieinami per vieną vientisą API, su type safety ir autocomplete.
Praktinis projekto setup’as nuo nulio
Gerai, užtenka teorijos. Sukurkime realų projektą. Tarkime, norime padaryti tech blog’ą su straipsniais Markdown formatu ir dinamiškai generuojamais puslapiais.
Pradedame standartiškai:
npm init gatsby
CLI paklaus kelių klausimų – pasirinkite TypeScript (jei esate normalus žmogus), styling sprendimą (aš dažniausiai einu su styled-components arba CSS modules), ir ar norite CMS integracijos. Pradžiai galite praleisti CMS – pridėsime vėliau jei reikės.
Po kelių minučių turėsite veikiantį Gatsby projektą. Struktūra bus maždaug tokia:
src/
pages/ # Automatiškai tampa route'ais
components/ # React komponentai
templates/ # Template'ai dinaminiams puslapiams
gatsby-config.js # Pagrindinis config'as
gatsby-node.js # Build-time logika
Dabar įdomi dalis – pridėkime galimybę skaityti Markdown failus. Tam reikės dviejų plugin’ų:
npm install gatsby-source-filesystem gatsby-transformer-remark
gatsby-config.js faile sukonfiguruojame:
plugins: [
{
resolve: 'gatsby-source-filesystem',
options: {
name: 'posts',
path: `${__dirname}/content/posts`,
},
},
'gatsby-transformer-remark',
]
Dabar sukurkite content/posts/ direktoriją ir įmeskite kelis Markdown failus su frontmatter:
---
title: "Mano pirmas Gatsby straipsnis"
date: "2024-01-15"
slug: "pirmas-straipsnis"
---
Čia eina turinys...
GraphQL užklausos ir duomenų gavimas
Vienas iš Gatsby privalumų – GraphiQL playground, prieinamas http://localhost:8000/___graphql. Čia galite eksperimentuoti su užklausomis realiu laiku.
Pavyzdžiui, norint gauti visus blog post’us:
query {
allMarkdownRemark(sort: {frontmatter: {date: DESC}}) {
nodes {
frontmatter {
title
date
slug
}
excerpt
}
}
}
Šią užklausą galite naudoti tiesiog React komponente su useStaticQuery hook’u arba per page query. Skirtumas – useStaticQuery negali priimti kintamųjų, tinka tik statinėms užklausoms.
Praktinis patarimas: pradžioje GraphQL sintaksė gali atrodyti keista, ypač jei ateinat iš REST pasaulio. Bet pasitikėkite – po savaitės jau rašysite užklausas neatidarę dokumentacijos. O autocomplete IDE tikrai padeda.
Dinaminis puslapių generavimas
Gerai, turime Markdown failus, GraphQL užklausas veikia. Bet kaip sukurti atskirą puslapį kiekvienam straipsniui? Čia ateina gatsby-node.js.
Šis failas leidžia hook’intis į Gatsby build procesą. Naudosime createPages API:
exports.createPages = async ({ graphql, actions }) => {
const { createPage } = actions
const result = await graphql(`
query {
allMarkdownRemark {
nodes {
frontmatter {
slug
}
}
}
}
`)
result.data.allMarkdownRemark.nodes.forEach(node => {
createPage({
path: `/blog/${node.frontmatter.slug}`,
component: path.resolve('./src/templates/blog-post.js'),
context: {
slug: node.frontmatter.slug,
},
})
})
}
Dabar sukurkite src/templates/blog-post.js template’ą:
export const query = graphql`
query($slug: String!) {
markdownRemark(frontmatter: {slug: {eq: $slug}}) {
html
frontmatter {
title
date
}
}
}
`
const BlogPost = ({ data }) => {
const post = data.markdownRemark
return (
{post.frontmatter.title}
)
}
Atkreipkite dėmesį – GraphQL užklausoje naudojame $slug kintamąjį, kuris ateina iš context objecto createPage funkcijoje.
Paveikslėlių optimizacija ir gatsby-plugin-image
Jei dirbate su bet kokiu content-heavy projektu, paveikslėliai bus jūsų didžiausia problema. Gatsby turi puikų sprendimą – gatsby-plugin-image.
Šis plugin’as automatiškai:
- Generuoja skirtingų dydžių versijas
- Konvertuoja į WebP/AVIF formatą
- Prideda lazy loading
- Sukuria blur-up placeholder’ius
- Optimizuoja pagal viewport dydį
Naudojimas paprastas:
import { StaticImage } from 'gatsby-plugin-image'
Jei paveikslėliai ateina iš GraphQL (pvz., iš Markdown frontmatter), naudokite GatsbyImage komponentą su dynamic image data.
Vienas dalykas, kuris gali suklaidinti – StaticImage reikalauja, kad src būtų statinis string’as, ne kintamasis. Tai dėl to, kad Gatsby build metu turi žinoti, kuriuos paveikslėlius optimizuoti. Jei reikia dinamiškumo, naudokite gatsby-source-filesystem su GraphQL.
Plugin’ų ekosistema ir dažniausios integracijos
Gatsby stiprybė – plugin’ai. Yra jų šimtai, ir daugelis išsprendžia problemas, su kuriomis susidurtumėte bet kuriame projekte.
Štai mano asmeninis „must-have” sąrašas:
gatsby-plugin-manifest – generuoja web app manifest’ą, prideda favicon’us, leidžia padaryti PWA. Setup’as trivialus, rezultatas – profesionaliau atrodantis projektas.
gatsby-plugin-sitemap – automatiškai generuoja sitemap.xml. Jei rūpi SEO (o turėtų), tai no-brainer.
gatsby-plugin-google-gtag – Google Analytics integracija. Yra ir kitų analytics sprendimų, bet šis veikia iš dėžės.
gatsby-plugin-feed – RSS feed’as. Taip, RSS dar gyvas, ir jei darote blog’ą, žmonės tikrai naudoja.
gatsby-source-contentful (arba Sanity, Strapi, kt.) – jei dirbate su headless CMS. Gatsby puikiai integruojasi su visais pagrindiniais CMS sprendimais.
Vienas patarimas dėl plugin’ų – neskubėkite pridėti visko iš karto. Pradėkite su minimaliu setup’u ir pridėkite funkcionalumą pagal poreikį. Kiekvienas plugin’as prideda build time, o kai projektas auga, tai tampa jaučiama.
Performance optimizacijos ir deployment
Gatsby iš dėžės duoda gerą performance, bet yra keletas dalykų, kuriuos galite padaryti dar geriau.
Pirma – code splitting. Gatsby tai daro automatiškai, bet galite padėti su dynamic import’ais:
const HeavyComponent = React.lazy(() => import('./HeavyComponent'))
Antra – prefetching strategija. Gatsby default’u prefetch’ina visus link’us, kurie matomi viewport’e. Tai super greita navigacija, bet jei turite šimtus link’ų puslapyje, gali būti per daug. Galite kontroliuoti per gatsby-config.js:
module.exports = {
flags: {
FAST_DEV: true,
PRESERVE_FILE_DOWNLOAD_CACHE: true,
},
}
Trečia – incremental builds. Jei naudojate Gatsby Cloud arba Netlify, galite enable’inti incremental builds, kurie rebuild’ina tik pasikeitusias dalis. Tai gali sumažinti build laiką nuo 10 minučių iki 30 sekundžių.
Dėl deployment’o – Gatsby puikiai veikia su:
- Netlify (mano asmeninis favoritas, turi puikią Gatsby integraciją)
- Vercel (taip pat puiku, nors labiau orientuota į Next.js)
- Gatsby Cloud (oficialus sprendimas, bet mokamas)
- GitHub Pages (nemokamas, bet ribotesnis)
- AWS S3 + CloudFront (jei norite full control)
Netlify setup’as paprastas kaip du kartus du – sujunkite GitHub repo, nurodykite build komandą (gatsby build), ir publish direktoriją (public/). Viskas. Kiekvienas push į main branch’ą automatiškai deploy’ins naują versiją.
Ką daryti kai projektas auga ir tampa lėtas
Štai kur Gatsby kartais gauna kritikos – dideli projektai gali turėti ilgus build laikus. Jei turite tūkstančius puslapių, build’as gali trukti 15-30 minučių ar net ilgiau.
Keletas strategijų kaip su tuo kovoti:
Deferred Static Generation (DSG) – naujesnis Gatsby feature’as, leidžiantis atidėti kai kurių puslapių generavimą iki pirmo request’o. Puikiai tinka puslapiams, kurie retai lankami:
export async function config() {
return {
defer: true
}
}
Partial Hydration – ne visi komponentai turi būti interactive. Galite naudoti gatsby-plugin-no-javascript tam tikroms dalims, jei jos tik statinės.
Build cache’inimas – įsitikinkite, kad CI/CD sistema cache’ina .cache ir public direktorijas tarp build’ų.
Duomenų šaltinių optimizacija – jei traukiate duomenis iš external API, įsitikinkite, kad naudojate pagination, filtravimą, ir traukiate tik tai ko reikia.
Vienas realus pavyzdys iš praktikos – dirbau projekte su ~5000 blog post’ų. Build laikas buvo 25 minutės. Po optimizacijų (DSG, geresnės GraphQL užklausos, incremental builds) nukrito iki 3 minučių normaliam update’ui ir ~10 minučių full rebuild’ui.
Ar Gatsby vis dar verta mokytis dabar
Tiesą sakant, Gatsby ekosistema šiek tiek sulėtėjo pastaraisiais metais. Next.js paėmė daug dėmesio, Astro atėjo su naujomis idėjomis, Remix irgi žaidžia toje pačioje aikštelėje. Bet Gatsby vis dar turi savo vietą.
Jei darote content-heavy projektą, kur SEO yra kritinis, ir nereikia daug server-side logikos – Gatsby puikus pasirinkimas. Plugin’ų ekosistema, paveikslėlių optimizacija, ir developer experience vis dar top tier. Dokumentacija išsami, community aktyvus (nors ne toks kaip Next.js), ir yra daugybė realių production projektų ant Gatsby.
Kita vertus, jei darote aplikaciją su daug dinamikos, authentication, real-time features – galbūt Next.js ar Remix būtų geresnis pasirinkimas. Gatsby stipriausia statinio content’o srityje.
Mano asmeninė nuomonė – Gatsby vis dar verta mokytis, ypač jei jau mokate React. Daugelis konceptų (component architecture, GraphQL, build-time optimization) persikeliami į kitus framework’us. O jei kada nors reikės padaryti greitą, SEO-friendly website’ą – Gatsby leis tai padaryti per savaitgalį, ne mėnesį.
Taigi, ar verta? Priklauso nuo use case’o. Bet jei skaitote šį straipsnį, tikėtina kad jūsų use case’as Gatsby teritorijoje. Tad drąsiai eksperimentuokite, pradėkite nuo mažo projekto, ir pamatysite ar jums prie širdies. Worst case – išmoksite React ir GraphQL geriau. Best case – turėsite naują įrankį toolbox’e, kuris išspręs realias problemas.