Gatsby łączy witryny React z ustrukturyzowaną treścią i elastycznym renderowaniem
Czym jest Gatsby?
Gatsby to framework React do tworzenia witryn z komponentów i ustrukturyzowanej treści. Może gromadzić dane z plików, systemów zarządzania treścią, interfejsów API i innych usług, porządkować je za pomocą warstwy GraphQL oraz wykorzystywać do tworzenia stron z renderowaniem statycznym, odroczonym, po stronie serwera lub po stronie klienta.
Gatsby jest frameworkiem. gatsbyjs.com to jego oficjalna witryna i centrum dokumentacji. To rozróżnienie jest istotne, ponieważ przedmiotem tego przewodnika są architektura frameworka, jego pakiety i repozytorium, natomiast domena jest miejscem, w którym projekt publikuje dokumentację.
Projekt Gatsby zazwyczaj łączy kilka obszarów w jeden proces pracy:
- Komponenty React definiują interfejs i elementy stron wielokrotnego użytku.
- Wtyczki źródłowe importują treść i dane z systemów lokalnych lub zdalnych.
- Gatsby normalizuje pobrane rekordy do postaci węzłów w swojej warstwie danych.
- Zapytania GraphQL wybierają pola potrzebne stronom i komponentom.
- Interfejsy API stron i szablony przekształcają dane w trasy.
- Ustawienia renderowania określają, kiedy każda strona jest tworzona.
Związek Gatsby z React
React zapewnia model komponentów Gatsby. Programiści tworzą układy, nawigację, szablony i funkcje interaktywne z komponentów React, a Gatsby dostarcza otaczający je framework do obsługi tras, pobierania danych, tworzenia stron, przetwarzania zasobów i generowania wyników produkcyjnych.
Gatsby nie jest więc ani zamiennikiem React, ani jedynie biblioteką komponentów. Jest opiniotwórczym frameworkiem witryn zbudowanym wokół React. Zespoły mogą korzystać ze znanych mechanizmów JSX, kompozycji komponentów, właściwości, stanu i interakcji po stronie przeglądarki, używając jednocześnie interfejsów API właściwych dla Gatsby do obsługi danych i renderowania.
Co Gatsby dodaje do React
| Obszar | Co zapewnia React | Co dodaje Gatsby |
|---|---|---|
| Interfejs | Komponenty i stan | Konwencje stron, układy i integrację z procesem kompilacji |
| Dane | Wybór sposobu pobierania danych na poziomie aplikacji | Znormalizowaną warstwę danych i proces zapytań GraphQL |
| Trasy | Elementy konstrukcyjne aplikacji | Strony oparte na plikach, programowe tworzenie stron i trasy wyłącznie po stronie klienta |
| Wynik | Interfejsy renderowane w przeglądarce | Statyczne, odroczone i wykonywane w czasie żądania renderowanie stron |
| Integracje | Ogólny ekosystem JavaScript | Wtyczki, motywy, projekty startowe i interfejsy API cyklu życia frameworka Gatsby |
Taka struktura może odpowiadać zespołowi React tworzącemu publiczną witrynę z dużą ilością treści. Może być zbędna, gdy mały projekt wymaga niewielu integracji treści lub gdy jego wymagania dotyczą przede wszystkim aplikacji renderowanej po stronie klienta.
Warstwa danych i GraphQL
Warstwa danych Gatsby została zaprojektowana tak, aby zapewniać wspólny interfejs zapytań dla różnych źródeł treści. Wtyczki źródłowe pobierają rekordy i tworzą węzły Gatsby. Następnie Gatsby udostępnia te węzły poprzez schemat GraphQL, do którego mogą wysyłać zapytania strony i komponenty.
Witryna może łączyć pliki Markdown, obrazy, bezgłowy system treści oraz wybrane dane usług. Zamiast wymagać, aby każda strona rozumiała pierwotny format odpowiedzi każdego źródła, Gatsby może udostępnić odpowiednie rekordy za pośrednictwem wspólnego grafu.
Typowa ścieżka treści wygląda następująco:
- Plik, usługa lub platforma treści przechowuje oryginalny materiał.
- Wtyczka źródłowa importuje ten materiał podczas procesu pobierania danych przez Gatsby.
- Gatsby przedstawia zaimportowane rekordy jako węzły i tworzy schemat.
- Zapytania GraphQL pobierają pola wymagane przez stronę lub komponent.
- Szablon wykorzystuje wynik zapytania do utworzenia strony.
- Gatsby renderuje stronę zgodnie z wybranym trybem renderowania.
GraphQL ma kluczowe znaczenie w procesie obsługi danych źródłowych Gatsby, ale nie zastępuje każdej zwykłej wartości React. Właściwości komponentów, stan lokalny, zdarzenia przeglądarki i żądania po stronie klienta nadal mogą istnieć poza grafem czasu kompilacji. Warto ustalić, czy wspólny schemat Gatsby upraszcza treść, którą trzeba złożyć w strony.
Warstwa danych wiąże się również z dodatkową pracą. Zespoły muszą rozumieć zachowanie źródeł, relacje między węzłami, zmiany schematu i zależności zapytań. Graf ujednolicający kilka systemów może być wartościowy, ale koszt jego kompilacji i obciążenie związane z utrzymaniem należy sprawdzić na reprezentatywnej treści, zamiast wnioskować na podstawie witryny startowej.
Wtyczki źródłowe i szerszy model rozszerzeń
Wtyczki źródłowe łączą Gatsby z danymi. Mogą odczytywać lokalne pliki lub integrować systemy treści i usługi, a następnie tworzyć węzły uczestniczące w warstwie GraphQL. Odróżnia je to od wtyczek dodających przetwarzanie, analitykę, stylizację, obsługę obrazów lub inne zachowania cyklu życia.
Gatsby udostępnia rozwiązania wielokrotnego użytku w trzech powiązanych formach:
- Wtyczki dodają źródło, transformację, integrację lub funkcję frameworka.
- Motywy zawierają konfigurację i funkcjonalność Gatsby wielokrotnego użytku, które witryny mogą rozszerzać.
- Projekty startowe zapewniają początkowy projekt, który programiści kopiują i dostosowują.
Projekt startowy może skrócić konfigurację, ale jego zależności i konwencje stają się odpowiedzialnością zespołu, który go przyjmuje. Motyw może utrzymywać spójność funkcjonalności między witrynami, ale zespoły powinny rozumieć, czym steruje. Wtyczka może wyeliminować potrzebę pisania niestandardowego kodu integracyjnego, choć jej zgodność i utrzymanie trzeba oceniać indywidualnie.
Istnienie dużej kategorii wtyczek nie dowodzi, że konkretny pakiet obsługuje używaną przez zespół wersję Gatsby, źródło danych lub model wdrożenia. Praktyczna ocena powinna wskazać dokładnie wymagane pakiety, sprawdzić ich dokumentację i aktywność repozytoriów oraz przetestować je w proponowanej architekturze.
Opcje renderowania w Gatsby
Początkowo Gatsby był silnie kojarzony z generowaniem witryn statycznych, ale jego dokumentacja definiuje obecnie kilka opcji renderowania. Można wybierać je dla poszczególnych stron, dzięki czemu publiczny artykuł, obszerne archiwum, trasa zależna od żądania i obszar aplikacji mogą korzystać z różnych modeli produkcyjnych.
| Opcja renderowania | Kiedy strona jest tworzona | Odpowiednie pytanie |
|---|---|---|
| Static Site Generation (SSG) | Podczas kompilacji | Czy wymagana treść strony jest dostępna przed wdrożeniem? |
| Deferred Static Generation (DSG) | Przy pierwszym żądaniu odroczonej strony | Czy tę stronę można wyłączyć z początkowej kompilacji i czy hosting obsługuje Gatsby DSG? |
| Server-Side Rendering (SSR) | W czasie żądania, z użyciem getServerData |
Czy odpowiedź wymaga danych lub kontekstu dostępnych w czasie żądania? |
| Trasa po stronie klienta | W przeglądarce, dla ścieżki aplikacji | Czy ta sekcja ma celowo charakter aplikacji i co jest dostępne przed zakończeniem wykonywania JavaScript? |
Strony statyczne i odroczone
SSG tworzy HTML i powiązane zasoby podczas kompilacji. Jest naturalną opcją dla treści, której dane wejściowe są znane z wyprzedzeniem. Wygenerowane pliki mogą być łatwe do dystrybucji, ale duża liczba stron, kosztowne zapytania, liczne źródła treści lub intensywne przetwarzanie obrazów mogą zwiększyć wymagania procesu kompilacji.
DSG odracza wybrane strony do momentu ich pierwszego żądania. Może to zmniejszyć liczbę stron tworzonych podczas początkowej kompilacji, zwłaszcza gdy witryna ma długi ogon rzadko odwiedzanej treści. Wymaga również środowiska wdrożeniowego implementującego odroczone generowanie Gatsby; nie jest równoważne przesłaniu wyłącznie plików statycznych na dowolny hosting.
Renderowanie w czasie żądania i w przeglądarce
SSR generuje odpowiedź w czasie żądania za pomocą interfejsu API getServerData Gatsby. Może obsługiwać strony, których wynik zależy od bieżących informacji dostępnych w czasie żądania, ale wprowadza wykonywanie kodu na serwerze, decyzje dotyczące buforowania, obsługę awarii i wymagania infrastrukturalne, których unika strona całkowicie statyczna.
Trasy po stronie klienta obsługują w przeglądarce sekcje aplikacyjne. Mogą współistnieć z wygenerowanymi stronami publicznymi, ale zespoły powinny zbadać stany ładowania, nawigację, dostępność i treść dostępną przed uruchomieniem kodu po stronie klienta. Nie należy zakładać publicznej wykrywalności tylko dlatego, że trasa przeglądarki ostatecznie wyświetla właściwe informacje.
Żadna etykieta renderowania nie gwarantuje szybkości ani widoczności w wyszukiwarkach. Wyniki zależą od projektu strony, JavaScript, zasobów, źródeł danych, buforowania, hostingu i jakości implementacji. Gatsby zapewnia zespołom kilka opcji architektonicznych, ale nie eliminuje potrzeby ich pomiaru.
Obrazy i tworzenie treści
Obrazy często znajdują się w tym samym potoku treści co tekst i ustrukturyzowane rekordy. Wtyczki Gatsby mogą pobierać pliki obrazów, przekształcać je i łączyć przetworzone zasoby z zapytaniami stron. Komponenty mogą następnie renderować wybrane dane obrazów jako część szablonu strony.
Przydatny proces redakcyjny rozdziela obowiązki:
- Redaktorzy zarządzają tytułami, treścią główną, metadanymi i odwołaniami do obrazów w wybranym źródle.
- Wtyczki źródłowe importują te rekordy i wskazane zasoby.
- Warstwa danych Gatsby łączy węzły treści z wymaganymi danymi obrazów.
- Zapytania pobierają tylko pola i warianty obrazów potrzebne szablonowi.
- Komponenty zapewniają podpisy, tekst alternatywny, wymiary i zachowanie układu.
- Kompilacja produkcyjna sprawdza, czy rekordy, zasoby i trasy są poprawnie rozwiązywane razem.
Przetwarzanie obrazów może poprawić spójność, ale nadal jest pracą wykonywaną podczas kompilacji. Zespoły powinny przetestować rzeczywistą liczbę i rozmiar zasobów, potwierdzić wpływ zmian na ponowne kompilacje oraz zachować znaczący tekst alternatywny ze źródła redakcyjnego. Wtyczka nie może zdecydować, czy obraz ma charakter informacyjny, dekoracyjny albo czy został odpowiednio opisany.
Gdzie Gatsby może dobrze się sprawdzić
Gatsby jest szczególnie odpowiedni, gdy projekt już korzysta z React i musi składać treść z kilku systemów. Jego graf danych może zapewnić spójną warstwę między tymi źródłami a korzystającymi z nich szablonami stron.
Typowe sytuacje warte oceny obejmują:
- Witryny dokumentacyjne lub redakcyjne łączące pliki, obrazy i platformę treści.
- Witryny marketingowe z komponentami React wielokrotnego użytku i ustrukturyzowanymi rekordami stron.
- Projekty publikacyjne korzystające z wielu źródeł, którym pomaga jeden interfejs zapytań.
- Istniejące witryny Gatsby oparte na interfejsach API stron, GraphQL i sprawdzonych wtyczkach.
- Duże zbiory treści, w których wybrane strony mogą być kandydatami do DSG.
- Witryny łączące wygenerowane strony publiczne z sekcjami działającymi w czasie żądania lub po stronie klienta.
Gatsby może być mniej bezpośrednim wyborem, gdy projekt ma jedno proste źródło treści, nie korzysta ze znormalizowanego grafu lub potrzebuje architektury aplikacji skupionej głównie na operacjach wykonywanych w czasie żądania i po stronie klienta. Jest to ocena architektoniczna, a nie werdykt dotyczący jakości frameworka.
Kompromisy związane z kompilacją i wdrożeniem
Generowanie statyczne przenosi pracę na okres przed wdrożeniem. Gatsby może potrzebować pobrać dane źródłowe, zbudować schemat, wykonać zapytania, utworzyć strony, przetworzyć obrazy, spakować kod i zapisać wynik. Czas trwania i wymagania dotyczące zasobów zależą od rzeczywistego projektu.
Reprezentatywna ocena powinna uwzględniać:
| Obszar testów | Co sprawdzić |
|---|---|
| Skala treści | Liczbę stron, liczbę węzłów, relacje i realistyczne rozmiary rekordów |
| Niezawodność źródeł | Uwierzytelnianie, limity żądań, awarie i powtarzalne pobieranie |
| Zapytania | Stabilność schematu, koszt zapytań i błędy po zmianach treści |
| Obrazy | Skalę przetwarzania, użycie pamięci, rozmiar wyniku i metadane redakcyjne |
| Renderowanie | Wynik SSG, pierwsze żądania DSG, odpowiedzi SSR i ładowanie tras po stronie klienta |
| Wdrożenie | Obsługę każdego wybranego trybu, zachowanie buforowania i odzyskiwanie po awarii |
Mała demonstracja nie może ustalić, jak zachowa się pełny katalog. Zespoły powinny testować czyste kompilacje, zmiany przyrostowe tam, gdzie są obsługiwane, awarie źródeł treści oraz strony znajdujące się zarówno na typowych, jak i skrajnych krańcach zbioru danych.
DSG może przenieść pracę poza początkową kompilację, natomiast SSR przenosi ją na czas żądań. Są to zmiany czasu wykonania i odpowiedzialności operacyjnej, a nie bezpłatne ulepszenia wydajności. Wybrany hosting musi obsługiwać wymagane zachowanie Gatsby, a zespół powinien rozumieć, co dzieje się podczas zimnego żądania lub awarii systemu nadrzędnego.
Gatsby, Astro i inne alternatywy
Zarówno Gatsby, jak i Astro mogą pojawić się w ocenach witryn opartych na treści, ale inaczej organizują projekty. Gatsby stawia w centrum React, własną warstwę danych GraphQL, wtyczki źródłowe oraz interfejsy API generowania stron. Astro należy oceniać na podstawie jego własnej udokumentowanej architektury, a nie domyślnie traktować jako szybszą lub nowszą odpowiedź.
Gatsby zasługuje na dokładniejsze rozważenie, gdy zespół chce używać React w całym interfejsie, musi wykonywać zapytania do kilku znormalizowanych źródeł treści, polega na integracjach Gatsby lub utrzymuje istniejącą bazę kodu Gatsby. Inny framework może być prostszy, gdy taki graf i cykl życia wtyczek dodawałyby strukturę, nie rozwiązując rzeczywistego problemu z treścią.
Przydatne porównanie polega na zbudowaniu tego samego reprezentatywnego fragmentu w każdym rozwiązaniu: jednego źródła treści, jednej złożonej strony, listy, obsługi obrazów, nawigacji i zamierzonego trybu wdrożenia. Należy porównać zrozumiałość dla programistów, zachowanie kompilacji, wynik w przeglądarce, dostępność, wymagania hostingowe i odpowiedzialność za utrzymanie. Nie należy ogłaszać uniwersalnego zwycięzcy na podstawie domyślnych szablonów.
Założyciel i oficjalne zasoby społeczności
W oficjalnej sesji pytań i odpowiedzi społeczności Gatsby opublikowanej 2 kwietnia 2020 roku Kyle Mathews został określony jako „Założyciel @ GatsbyJS”. To datowane przypisanie opisuje jego historyczną rolę w tym źródle; nie należy odczytywać go jako twierdzenia dotyczącego obecnego kierownictwa Gatsby.
Dokumentacja Gatsby kieruje programistów do oficjalnych kanałów społeczności przeznaczonych do różnych potrzeb:
- Discord jest wymieniany jako miejsce, w którym można poprosić społeczność o pomoc programistyczną.
- GitHub Discussions służy do dyskusji o projekcie i funkcjach.
- Dokumentacja współtworzenia wyjaśnia sposoby uczestnictwa w projekcie.
- Utrzymywane repozytorium gatsbyjs/gatsby zawiera kod źródłowy frameworka, pakiety, zgłoszenia i historię współtworzenia.
Zasoby te pomagają czytelnikom weryfikować dokumentację, zadawać pytania dotyczące implementacji i przeglądać publiczne prace nad projektem. Ich istnienia nie należy przekształcać w niepoparte twierdzenia dotyczące czasu odpowiedzi, długowieczności pakietów czy przyszłych planów.
Co zespoły powinny ustalić przed przyjęciem Gatsby
Sporządź mapę treści. Określ każde źródło, relacje między rekordami, częstotliwość aktualizacji oraz strony korzystające z poszczególnych pól. Pozwoli to stwierdzić, czy znormalizowana warstwa GraphQL Gatsby rozwiązuje istotny problem koordynacyjny.
Przypisz tryb renderowania do reprezentatywnych stron. Potwierdź, które strony mogą być statyczne, które mogą być odroczone, które wymagają
getServerData, a które celowo działają po stronie klienta. Sprawdź, czy docelowe środowisko wdrożeniowe obsługuje wynikającą z tego kombinację.Sprawdź konkretny zestaw zależności. Zweryfikuj wymagane wtyczki źródłowe, wtyczki transformujące, motywy, projekty startowe i narzędzia do obrazów pod kątem wersji Gatsby używanej w projekcie. Przygotuj prototyp niepewnych integracji, zanim staną się zależnościami architektonicznymi.
Przetestuj obciążenie przypominające produkcyjne. Gatsby oferuje spójny framework React i treści, ale jego przydatność wynika ze zgodności z danymi, stronami, integracjami i modelem hostingu zespołu, a nie z ogólnych obietnic dotyczących szybkości, pozycji w wyszukiwarkach czy bezproblemowego skalowania.
Prawidłowa odpowiedź nie gwarantuje bezpieczeństwa. Pomiary opisują pojedynczą obserwację w określonym czasie.