Headless CMS: Gatsby JS z WordPress

Powszechnie wiadomo, że WordPress obejmuje około jedną trzecią z 1 miliona najlepszych witryn internetowych na świecie z ponad 50% udziałem w rynku systemów zarządzania treścią. Jeszcze w 2016 roku WordPress zdecydował się na wprowadzenie REST API, aby zapewnić innym aplikacjom lepszy dostęp do treści w bazie danych WordPressa. W rezultacie, dając programistom możliwość wykorzystania WordPressa jako bezgłowego CMS.

To nieuchronnie sugerowało, że inżynierowie nie będą już ograniczać się do korzystania z konwencjonalnej warstwy prezentacji (frontend) WordPressa, ale mogą teraz wykorzystywać dowolną aplikację frontendową do dostarczania swoich danych. W związku z tym większość tego bloga będzie badać związek WordPressa i Gatsby.js w odniesieniu do działania Headless CMS.

Krótka historia CMS

Gdy robimy krok wstecz, aby zrozumieć rewolucję Headless CMS, myślę, że warto przypomnieć historię systemów zarządzania treścią (CMS). Tradycyjnie we wczesnych latach 90. statyczne strony internetowe były głównym sposobem wykonywania witryn internetowych, w których webmaster bezpośrednio edytował pliki HTML i przesyłał je na serwer za pośrednictwem FTP. W końcu w połowie lat 90. technologia internetowa zaczęła ewoluować, a treść stała się bardziej dynamiczna, co doprowadziło do pojawienia się pierwszych monolitycznych systemów zarządzania treścią.

Zasadniczo monolityczny CMS to aplikacja, która zawiera wszystko, co jest wymagane do edycji i publikowania treści w Internecie. Pierwszy z takich systemów ograniczał się do takich przedsiębiorstw jak EpiServer, jednak później pojawiły się odmiany open-source, takie jak WordPress, Drupal i Joomla. Reszta to już historia, ponieważ WordPress z czasem zyskał największy udział w rynku.

Jednak później, podczas rewolucji dotyczącej smartfonów, urządzenia mobilne zaczęły wpływać na sposób konsumpcji i dostarczania treści internetowych. Było to wyzwanie dla tradycyjnych monolitycznych systemów CMS zaprojektowanych do dostarczania treści internetowych na laptopy i komputery stacjonarne.

Aby to złagodzić, narodził się responsywny design, który zaowocował układami stron internetowych dostosowanymi do rozmiaru ekranu. W konsekwencji dało to również możliwość oddzielenia zarządzania treścią od warstwy wyświetlania. W tym miejscu wkraczają nasze Headless CMS.

Bezgłowe systemy CMS

Jak wspomniano wcześniej, Headless CMS to taki, który nie ma warstwy prezentacji. W rezultacie treść jest dostarczana za pośrednictwem interfejsu API (RESTful lub GraphQL) do oddzielnej aplikacji frontendowej, która następnie ją prezentuje. API udostępnia treści na dowolnym kanale i urządzeniu przy użyciu różnych narzędzi i języków programowania o wyższym poziomie bezpieczeństwa i skalowalności.

Zasadniczo CMS jest oddzielony od problemów związanych z frontendem, co z kolei pozwala programistom na tworzenie bogatych doświadczeń dla użytkowników końcowych przy użyciu najlepszej dostępnej technologii. Tryb „bezgłowy” lub „odłączony” jest obecnie obsługiwany przez większość systemów CMS, co utorowało drogę witrynom Gatsby.

Tak więc, aby wykorzystać bezgłowy CMS, musisz najpierw zbudować swoją witrynę lub aplikację, a następnie użyć interfejsu API CMS, aby podłączyć zawartość.

Wykonanie WordPress Headless CMS

Jeśli chodzi o chronologię wydarzeń udostępnionych powyżej, widzieliśmy, jak WordPress w końcu wprowadził bezgłowy CMS. WordPress zawiera API (interfejs programowania aplikacji), który pozwala na rozszerzenie go o wtyczki (zasadniczo jako „strukturę aplikacji”). W szczególności osiąga się to za pośrednictwem interfejsu API REST, jak to zrobimy później.

Jednak jedną z kluczowych koncepcji API WordPressa są hooki. Zasadniczo haki umożliwiają wtyczkom zmianę podstawowej funkcjonalności WordPressa. W praktyce hooki działają w taki sposób, że gdy wystąpi określone zdarzenie w WordPressie (na przykład ładowanie strony lub post-edycja), WordPress wywołuje określony hook w celu uruchomienia funkcji.

W szczególności haki są podzielone na „Akcje” i „Filtry”. Akcje mogą być wykorzystane do uruchomienia pewnych funkcji PHP w określonych zdarzeniach, chociaż funkcje nie muszą niczego zwracać. Filtry mogą być wykorzystywane do uruchamiania funkcji, przez które WordPress przekazuje dane podczas niektórych zdarzeń, przy czym te funkcje pobierają dane jako parametr i zwracają zmodyfikowaną wersję danych.

WordPress i REST API

Reprezentacyjny transfer stanu (REST) ​​jest oparty na protokole HTTP i zapewnia jednolitą semantykę interfejsu do tworzenia, odczytu, aktualizacji i usuwania danych (CRUD).

Ogólnie rzecz biorąc, wykonanie REST API w WordPress umożliwia programistom zdalny dostęp do danych w bazie danych WordPress poprzez wysyłanie i odbieranie obiektów JSON (JavaScript Object Notation). W związku z tym zapewnia to programistom możliwość tworzenia, odczytywania, aktualizowania i usuwania danych WordPress z innych aplikacji, które nie są zaprojektowane z WordPress. Na przykład aplikacje internetowe JavaScript lub natywne aplikacje mobilne.

Jednak w miarę pogłębiania wiedzy na temat relacji Headless WordPress CMS z interfejsami API REST i Gatsby, musimy zwrócić uwagę na kilka podstawowych koncepcji interfejsu API WordPress:

• Trasy i punkty końcowe: Trasy to ścieżki, do których można uzyskać dostęp za pośrednictwem wywołania HTTP, podczas gdy punkt końcowy jest metodą HTTP (taką jak get, post, put lub delete) zamapowaną na tę trasę.
• Żądanie: Gdy zainicjujesz żądanie HTTP do zarejestrowanej trasy REST, WordPress automatycznie utworzy obiekt żądania. Dane podane w zapytaniu określą jaką odpowiedź otrzymasz z powrotem.
• Odpowiedź: Obiekt odpowiedzi to dane, które otrzymujesz z powrotem po wysłaniu żądania. Może zawierać żądane dane lub komunikaty o błędach.
• Schemat: schemat odwołuje się do struktury danych w punkcie końcowym. Każdy punkt końcowy może mieć nieco lub znacząco różną strukturę zwracanych danych. W związku z tym schemat określi wszystkie możliwe właściwości, które punkt końcowy może zwrócić i wszystkie możliwe parametry, które może otrzymać.
• Klasy kontrolerów: Klasy kontrolerów umożliwiają programistom zarządzanie i rejestrowanie punktów końcowych i tras, jednocześnie umożliwiając im obsługę żądań, wykorzystywanie schematów i generowanie odpowiedzi.

Ramy React

Wchodząc teraz w sedno relacji Gatsby.js i WordPressa, aby uzyskać więcej kontekstu, musimy rozszyfrować ten technologiczny krajobraz z bardziej historycznych podstaw. React jest kluczem do tej historii, ponieważ jest najszybciej rozwijającą się biblioteką/frameworkiem JavaScript. Rozsławione przez Facebooka (głównych programistów), inne duże strony internetowe wykorzystują React do swoich frontendów, takie jak: Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace i Tesla.

W konsekwencji, ponieważ React jest w praktyce biblioteką (ponieważ wciąż brakuje godnych uwagi cech pełnoprawnego frameworka), oznacza to, że można na nim zaprojektować inne „frameworki”. W rezultacie jednym z nich jest Gatsby.js.

Przedstawiamy Gatsby

Według strony nadrzędnej Gatsby.js jest darmową platformą JavaScript o otwartym kodzie źródłowym opartą na React, która pomaga programistom tworzyć szybkie strony internetowe i aplikacje. Zasadniczo Gatsby.js generuje statyczne strony HTML z aplikacji do wstępnego załadowania, a następnie działa jako jednostronicowa aplikacja React (SPA).

Atrybuty Gatsby.js

W tych okolicznościach Gatsby wykorzystuje zasady progresywnej aplikacji internetowej (PWA), aby pobrać tylko elementy wymagane w pierwszej kolejności, a następnie wczytać resztę aplikacji w tle. Ponadto, aby zapewnić ładowanie tylko wymaganych danych, Gatsby wykorzystuje język zapytań GraphQL (również Facebooka) do ładowania danych ze źródła. Utrzymuje również wyjątkową optymalizację obrazu.

Wszystkie te połączone możliwości dają programistom narzędzia niezbędne do tworzenia najszybszych możliwych stron internetowych i aplikacji internetowych, ponieważ ładują tylko krytyczny kod HTML, CSS, dane i JavaScript. Tak więc po załadowaniu strony Gatsby wstępnie pobiera zasoby dla powiązanych stron, dzięki czemu poruszanie się po witrynie jest dość szybkie.

Ponadto, ponieważ strony są generowane podczas kompilacji, przed umieszczeniem online, nie potrzebujesz już wydajnych serwerów PHP i możesz obsługiwać pliki statyczne (HTML, JS i CSS bezpośrednio z pamięci zasobnika). Dodatkowo, ponieważ Gatsby jest zasilany przez React, będziesz w stanie ładnie ustrukturyzować wszystko za pomocą komponentów. Ten modułowy aspekt umożliwia programistom łatwe ponowne wykorzystanie komponentów.

Inne ważne funkcje Gatsby po wyjęciu z pudełka to:

• Generator stron statycznych
• Dostęp offline
• Wstępne pobieranie linkowanych stron
• Buforowanie strony
• Brak pobierania obcego kodu
• Eksportuj jako kod
• Gorące przeładowanie zawartości
• Kod przeładowania na gorąco
• Komponentyzacja
• Jednokierunkowe wiązanie danych
• Zapytania o dane w deklaratywnym interfejsie API (GraphQL)
• Deklaratywny interfejs użytkownika
• Progresywne ładowanie obrazu
• Responsywne ładowanie obrazu
• Inlining krytycznego CSS
• Samodzielne hostowanie czcionek
• Bezserwerowe
• Rurociągi aktywów
• Rozszerzenia CSS (SaSS)
• Zaawansowana składnia JavaScript
• Ekosystem komponentów React

Wtyczki Gatsby

Zasadniczo wtyczki Gatsby to zasadniczo pakiety Node.js, które korzystają z interfejsu API Gatsby. Wtyczki te mogą dodawać źródła danych, przekształcać dane do innych formatów i dodawać usługi stron trzecich. Chociaż Gatsby.org utrzymuje bibliotekę wtyczek, która zawiera wiele już stworzonych wtyczek stworzonych przez główny zespół Gatsby lub strony trzecie. Idealnie, aby zainstalować wtyczkę do projektu Gatsby, programiści używają menedżera pakietów węzłów (NPM) na swoim terminalu UNIX i uruchamiają polecenie npm install.

Jak GraphQL Comes odnosi się do Gatsby'ego.

GraphQL kręci się wokół idei, że możesz opisać do API dokładnie te dane, których dokładnie chcesz, a otrzymasz dokładnie takie dane. W rezultacie jest bardziej wydajny niż REST. W tym celu Gatsby wykorzystuje Webpack i GraphQL. Co ważniejsze, z GraphQL jako językiem zapytań, wszystko jest definiowane po stronie klienta wykonującego zapytanie, przy czym klient nie jest świadomy niedociągnięć aplikacji.

Ta unikalna implementacja umożliwia programistom podłączenie dowolnego źródła danych do Gatsby. Na przykład posty na blogu mogą pochodzić z plików Markdown, arkuszy Google, a nawet z innej witryny WordPress. W związku z tym zapewnia zwiększoną elastyczność przy dostarczaniu treści.

Mechanizm Gatsby-WordPress (wtyczki źródłowe)

Gdy dalej rozpakowujemy tę relację, musimy zrozumieć wtyczki źródłowe. Wtyczki źródłowe to specjalne wtyczki działające w systemie danych Gatsby. Jak sama nazwa wskazuje, pozyskują dane z różnych lokalizacji, lokalnych lub zdalnych. W konsekwencji dane są następnie przekształcane w to, co Gatsby nazywa węzłami i polami węzłów. Zasadniczo pola węzłów reprezentują pojedynczą część danych w jednym węźle, a ostatecznie dostęp do tych węzłów można uzyskać za pomocą zapytania GraphQL.

W tym samym zakresie, za pośrednictwem wtyczek źródłowych, Gatsby obsługuje dziesiątki bezgłowych opcji CMS, zapewniając zespołom inżynieryjnym i merytorycznym wygodę i znajomość preferowanego interfejsu administratora, a także ulepszone wrażenia programistyczne i korzyści wydajnościowe wynikające z używania Gatsby, GraphQL i React do budowania nakładka.

Wtyczka „Gatsby-source-WordPress” jest tworzona i utrzymywana przez główny zespół Gatsby i pobiera dane z samodzielnie hostowanych witryn WordPress lub WordPress.com. Obejmuje również uwierzytelnianie OAuth w API Word-Press.com, a także umożliwia programistom wysyłanie zapytań do responsywnych obrazów.

Zasadniczo ta wtyczka obsługuje wszystkie podmioty w WordPress REST API, takie jak posty, strony, tagi, kategorie, media, typy, użytkownicy, statusy, taksonomie, metadane witryny i niestandardowe typy postów. Ponadto obsługiwane są również encje Advanced Custom Fields (ACF) oraz informacje o języku Polylang i WPML, a także inne meta posty zarejestrowane w interfejsie API REST.

Dzięki tej wtyczce programiści mogą wybrać trasy do pobrania, chociaż domyślnie pobiera ona wszystkie punkty końcowe wpjson. Tak więc programiści mogą pobierać dane z WordPressa za pomocą GraphQL wykorzystującego powyższy mechanizm.

W praktyce narzędzie „Gatsby-source-WordPress” zapewnia ślimak dla wszystkich postów i innych podmiotów. I tak, wszystko, co inżynier musi zrobić, to stworzyć stronę wywołującą funkcję 'createPage'. Jest to wykonywane w pliku Gatsby-node.js, zwykle najpierw uruchamiając zapytanie o źródło danych, a następnie wywołując „createPage” dla każdego znalezionego węzła, a następnie ustawiając plik szablonu, który ma być używany jako komponent.

CI/CD i automatyzacja wydawania aplikacji.

Podczas wdrażania bezgłowego systemu CMS WordPress z Gatsby, sposób wdrożenia jest bardzo krytyczny. Zazwyczaj takie wykonania wymagają zautomatyzowania wdrażania aplikacji przy użyciu automatyzacji wersji aplikacji (ARA).

Ogólnie rzecz biorąc, ARA obejmuje podstawowe funkcje:

• Wdrażanie danych, kodu aplikacji i artefaktów.
• Wdrażanie określonych konfiguracji dla każdego środowiska
• Projektowanie przepływu pracy procesów w celu automatyzacji zadań i etapów wdrażania.
• Wreszcie modelowanie środowiska i/lub udostępnianie plików binarnych

Ponieważ Gatsby tworzy witryny statyczne, konieczne jest skonfigurowanie potoku ARA, aby po aktualizacji treści w WordPressie można było ją odpowiednio zaktualizować w witrynie Gatsby. Zazwyczaj ciągłe wdrażanie jest wyzwalane tylko wtedy, gdy zmienia się kod, jednak w tym przypadku pożądane jest wyzwalanie go, gdy ulegną zmianie dane. W tym celu zalecamy korzystanie z Netlify ponieważ posiada niesamowite wbudowane możliwości ciągłego wdrażania i jest przyjazny dla użytkownika w konfiguracji.

Zapytania z WordPressa za pomocą GraphQL i gatsby-source-WordPress

Na przykład gatsby-source-WordPress działa w taki sposób, że najpierw pobierze wszystko z punktu końcowego za pomocą REST. Następnie na podstawie tych danych wygeneruje wewnętrzne API GraphQl. Następnie przejdzie przez Twoje zapytania i zbierze dane z tego wewnętrznego interfejsu API GraphQL. Tak więc, w zasadzie, twoja kompilacja kończy się tylko danymi, o które prosiłeś i niczym więcej.

Zalety programowania Headless WordPress z Gatsby.js

Ponieważ omówiliśmy program Headless WordPress z Gatsby, możemy teraz przeanalizować zalety tego rodzaju technicznego podejścia. To powinno zasadniczo kierować twoją decyzją o tym, czy adoptować Gatsby, czy nie!

• Pierwszą korzyścią jest możliwość posiadania statycznej, wstępnie wyrenderowanej witryny. Jest to najskuteczniejszy sposób renderowania strony internetowej, a ponieważ Gatsby wykorzystuje GraphQL do wykonania minimalnej potrzebnej ilości danych, zapewnia to dodatkową wydajność na czas po początkowym załadowaniu.
• Lepsza widoczność SEO: strony statyczne są łatwe do odczytania przez wyszukiwarki, ponieważ wszystko jest wstępnie renderowane i indeksowane. Jest to pozytywne, w przeciwieństwie do innych mechanizmów headless, w których renderowanie stron za pomocą JavaScript jest problemem związanym z optymalizacją pod kątem wyszukiwarek (SEO).
• Stosunkowo szybkie tempo rozwoju: W porównaniu do innych podejść bezgłowych, Gatsby ma jeden ujednolicony, łatwy do zrozumienia sposób pobierania danych, niezależnie od źródła. To sprawia, że ​​rozwój jest dość uproszczony, ponieważ możesz skupić się na swojej rzeczywistej witrynie i pozwolić Gatsby'emu wykonać większość ciężkich prac.
• Tańszy hosting: możesz hostować swoją aplikację Gatsby w dowolnym miejscu, ponieważ obsługuje ona tylko statyczne pliki, zmniejszając w ten sposób koszty hostingu. Dodatkowo, ponieważ WordPress jest wywoływany tylko podczas procesu kompilacji, a nigdy podczas sesji użytkownika, może być również hostowany na niedrogim rozwiązaniu hostingowym.
• Zwiększone bezpieczeństwo: Ogólnie rzecz biorąc, statyczne generatory witryn są niezwykle bezpieczne, ponieważ nie mają bezpośredniego połączenia z bazą danych, zależnościami, danymi użytkownika ani innymi poufnymi informacjami.
• Bez wtyczek: z perspektywy osoby nie będącej programistą WordPress jest dość łatwy w obsłudze ze względu na dostępne wtyczki. Ogranicza to jednak implementację niestandardowych funkcjonalności. Niestety, zbyt wiele wtyczek może spowolnić witrynę, ponieważ staje się ona ciężka i trudniejsza do renderowania. Egzekucja Gatsby zasadniczo omija wszystkie te wąskie gardła.

Więcej aspektów, które mogą zmotywować Cię do rozważenia Gatsby z WordPress:

• Łatwy w zarządzaniu panel administracyjny WordPress.
• Gotowy do użycia system logowania i autoryzacji użytkownika.
• Za pomocą edytora Gatsby i Gutenberg możesz zbudować narzędzie do tworzenia witryn Gatsby typu „przeciągnij i upuść”.

Wady programowania Headless WordPress z Gatsby.js

• Ograniczenia aktualizacji: gdy zawartość zmienia się od zera, ustawia ograniczenia dotyczące częstotliwości aktualizacji witryny. Ponadto uruchomienie kompilacji Gatsby może zająć do 10 minut, jeśli witryna zawiera dużo danych, co może stanowić problem w przypadku witryn, które często się aktualizują.
• Regularne aktualizacje: Ponadto, ponieważ Gatsby jest statycznym generatorem witryn, nie można go po prostu „edytować”, ponieważ nawet niewielka zmiana tekstu będzie wymagać nowego wdrożenia. Tak więc, jeśli masz stronę, która wymaga wielu dynamicznych codziennych zmian treści, może to stać się czasochłonne i uciążliwe.
• Opóźnienia: zazwyczaj musisz poczekać kilka minut, aby zobaczyć zmiany w swoich treściach w miarę ich udostępniania.
• Brak podglądów: w przeciwieństwie do tradycyjnych aplikacji WordPress, w Gatsby nie masz żadnego podglądu. Niestety, był to największy problem, jaki twórcy treści znaleźli w Gatsby. Będziesz musiał wszystko skompilować, prawdopodobnie za pomocą potoków Gitlab CI/CD, które kompilują witrynę i umieszczają wszystko w Internecie.
• Stroma krzywa uczenia się: Ogólnie rzecz biorąc, jeśli chcesz pracować jednocześnie z Gatsby i WordPressem, musisz stosunkowo dobrze znać języki PHP i JavaScript. Ponieważ Gatsby łączy React i GraphQL, dla wielu może to być stroma krzywa uczenia się.

Końcowe przemyślenia.

Podsumowując, dzięki wydajności i zaletom biznesowym coraz więcej firm wdraża Gatsby jako część swojego stosu technologicznego. Chociaż ważne jest, aby pamiętać, że łącząc Gatsby z WordPress, WP staje się tylko backendem, co oznacza, że ​​stracisz niektóre jego funkcje i możliwości.

Co więcej, programiści doświadczeni w programowaniu WordPress uznają Gatsby za doskonałe narzędzie z jego nowoczesną wydajnością, skalowalnością, bezpieczeństwem i szybkością programowania. Wszystko to przy jednoczesnym zachowaniu znanego interfejsu użytkownika do tworzenia treści oferowanego przez WordPress.

Jednak przed uruchomieniem tej technologii należy zawsze wziąć pod uwagę specyfikację i cele projektu. Na przykład, jeśli nacisk kładzie się na skalowalność, wydajność, szybkość rozwoju, długi cykl życia, Gatsby zrobi to. Jeśli jednak nacisk kładziony jest na większą elastyczność i narzędzia dla twórców treści, którzy nie są programistami, z treścią aktualizowaną co sekundę lub minutę, możesz rozważyć alternatywne podejście.