DE{CODE}: Headless 101 dla programistów WordPress

Programowanie bez głowy może być potężniejsze i jeszcze przyjemniejsze niż tradycyjne tworzenie WordPressa. Jednak przy tak wielu nowych wyborach w tym powstającym stosie, jaki jest najlepszy sposób na rozpoczęcie? Te warsztaty przeprowadzą konstruktorów przez proces instalacji i optymalizacji projektu WordPress pod kątem headless, aż do stworzenia szablonu pierwszej strony w oddzielonym interfejsie.

Slajdy sesji

Transkrypcja pełnego tekstu

GRACE ERIXON : Witamy w Headless 101 dla programistów WordPress. Nazywam się Grace Erixon i jestem zastępcą rzecznika programistów w WP Engine. Dołącza do mnie Steve z Haus. Dzisiaj przedstawimy krótkie wprowadzenie do tego, czym jest bezgłowy WordPress i jak możesz zacząć z niego korzystać.

Aby więc zrozumieć, czym jest bezgłowa architektura witryny WordPress, ważne jest, aby upewnić się, że wszyscy wiemy, jak wygląda tradycyjna architektura WordPress. Tradycyjnie CMS, taki jak WordPress, obsługiwałby zarówno interfejs, jak i zaplecze strony internetowej.

W tradycyjnej architekturze wydawca tworzy i zarządza treścią, taką jak posty na blogu i strony w WordPress. Deweloper pisze kod, aby kontrolować wygląd i działanie witryny za pomocą interfejsu API motywu PHP i WordPress. Następnie WordPress generuje stronę HTML, która jest wysyłana do odwiedzającego.

W tej połączonej architekturze CMS WordPress zapewnia wydawcom możliwości zarządzania treścią. Jest również odpowiedzialny za udostępnianie stron HTML odwiedzającym witrynę. Bezgłowy CMS wykorzystuje oddzieloną architekturę, w której front-end i back-end są zarządzane oddzielnie. W architekturze bezgłowej wydawca nadal tworzy i zarządza treścią w WordPress, tak samo jak w tradycyjnej architekturze WordPress.

Deweloper pisze kod kontrolujący wygląd i działanie witryny w JavaScript, a także używa WPGraphQL lub API REST do pobierania danych z WordPress. Framework taki jak Faust.js, Next.js, Nuxt.js lub SvelteKit jest często używany do zasilania tej aplikacji frontendowej. Następnie frontowa aplikacja JavaScript generuje i obsługuje strony HTML, które są wysyłane do osoby odwiedzającej witrynę.

W przeciwieństwie do tradycyjnej architektury, WordPress nie jest już odpowiedzialny za generowanie stron HTML. Tak więc interakcja w celu wymiany treści między zapleczem WordPress a aplikacją JavaScript frontonu odbywa się za pośrednictwem warstwy API. Dwie opcje warstwy API to WordPress REST API lub WPGraphQL.

Interfejs API REST jest dostarczany w pakiecie z WordPress. Jednak wzorzec dostępu do danych, którego wymaga, może być powolny, ponieważ REST wymaga, aby każdy zasób miał własny punkt końcowy. Na przykład zrekonstruowanie w pełni modelowanego postu wymagałoby wielu podróży w obie strony. Jeśli chciałbyś uzyskać treść, autora i kategorię posta, wymagałoby to trzech oddzielnych wywołań API.

Natomiast WPGraphQL pozwala nam poprosić o treść, autora i kategorię posta w jednym żądaniu. Z tego powodu WPGraphQL jest naszą preferowaną warstwą API. WPGraphQL to darmowa wtyczka, która zapewnia rozszerzalny schemat GraphQL i interfejs API dla Twojej witryny WordPress. WPGraphQL jest szybszy niż interfejs API REST, ponieważ pobiera dokładnie te dane, o które jest proszony, i skutkuje mniejszą liczbą funkcji wykonywanych poprzez optymalizację zapytań, mniej pobierania danych, bardziej wydajne ładowanie danych i uwzględnienie wielu zasobów w jednym żądaniu.

Bezgłowa architektura daje programistom swobodę wyboru dowolnego stosu technologii front-end, przy czym najpopularniejsze są frameworki JavaScript. Niektóre z najpopularniejszych front-endowych frameworków JavaScript to React, Vue.js i Svelte. Cały czas pojawiają się nowe frameworki, więc ta lista nie jest wyczerpująca.

Wiele z tych frameworków JavaScript jest używanych w połączeniu z metaframeworkami, które dodają rozwiązania dla rzeczy takich jak routing, renderowanie po stronie serwera i inne. React jest używany w połączeniu z Next.js, Vue.js jest używany w połączeniu z Nuxt.js, a Svelte jest używany w połączeniu ze SvelteKit. Gatsby to kolejny popularny metaframework.

WP Engine opracował Faust.js, framework JavaScript zbudowany na bazie React i Next.js. Faust został stworzony specjalnie do obsługi bezgłowych aplikacji internetowych WordPress. Obsługuje uwierzytelnianie i podgląd postów od razu po wyjęciu z pudełka, zapewnia wygodne wbudowane haki React do uzyskiwania dostępu do danych WordPress i nie tylko.

Rozmawialiśmy więc o tym, co oznacza bezgłowa architektura WordPressa i jakich technologii byś użył. Ale omówmy szybko, dlaczego w ogóle wybrałeś bez głowy. WordPress sam w sobie jest ciężkim CMS-em i używa PHP, który nie jest szybkim językiem. Bezgłowy WordPress używa języków zastępczych za pośrednictwem JavaScript i ładuje tylko niezbędne pliki za pośrednictwem wywołań API. Jest znacznie lżejszy, więc Twoja witryna ładuje się szybciej.

Bezgłowy WordPress minimalizuje również ryzyko dla twoich treści, ponieważ twoje dane są oddzielone od dostarczania front-endu. Jest mniej narażony na ataki sieciowe. Główną korzyścią jest to, że bezobsługowa architektura WordPress pozwala wydawcom nadal czerpać korzyści z wspaniałego doświadczenia związanego z publikowaniem, które zapewnia WordPress, a jednocześnie umożliwia programistom i odwiedzającym witrynę korzystanie z możliwości technicznych, jakie oferują nowoczesne aplikacje JavaScript.

Teraz zagłębimy się w kod prawdziwej witryny bez głowy. Nagrałem wcześniej przewodnik po nowej, bezgłowej witrynie WordPress Atlas Blueprints. Nowa funkcja Blueprints w Atlasie zapewnia naprawdę łatwy sposób na uruchomienie kompletnej, bezgłowej witryny WordPress. Zawierają kod startowy, wtyczki, modele treści i strukturę strony, aby Twoja aplikacja mogła szybciej działać.

Utwórzmy więc nową witrynę Blueprint, abyśmy mogli zagłębić się w kod. Z wnętrza pulpitu nawigacyjnego WP Engine przejdziemy do Atlasu. Kliknij Utwórz aplikację. Wybierz opcję Rozpocznij od planu. A potem wybierzemy plan, którego chcemy użyć. Mam zamiar wybrać projekt portfela.

Następnie połączysz swoje konto WP Engine z kontem GitHub i sklonujesz ten plan do nowego repozytorium. Budowa zajmie kilka sekund. Na koniec po prostu wybierz nazwę właśnie utworzonego repozytorium, region, w którym się znajdujesz, a następnie kliknij Utwórz aplikację.

Teraz, jeśli klikniesz adres URL Atlasu, możemy sprawdzić, jak wygląda nasza bezgłowa witryna WordPress. Nas szczególnie interesuje strona Posty. Jak widać, witryna pobiera wszystkie najnowsze posty na tę stronę naszego bloga. Każdy post ma również swoją indywidualną stronę widoku. Ale skąd pochodzą te wszystkie dane?

Jeśli wrócimy do pulpitu nawigacyjnego WP Engine, zobaczymy przycisk WP Admin. Oto zaplecze naszej bezgłowej witryny WordPress. Jeśli kliknę Posty, zobaczysz tę samą listę, którą pobierała aplikacja internetowa. Teraz możemy otworzyć repozytorium GitHub, do którego sklonowano nasz plan. Sklonujmy to repozytorium do naszego lokalnego środowiska.

Następnie otworzę to repozytorium w Visual Studio Code, moim ulubionym edytorze kodu. Drążąc w katalogu projektu, plik strony blogu można znaleźć w SRC, pages, posts, Index.js. Ten projekt jest zbudowany przy użyciu React, Next.js, Faust.js i WPGraphQL. Jeśli nie jesteś zaznajomiony z Reactem, a nawet JavaScriptem, na początku może to wyglądać na zagmatwane.

W pierwszej sekcji plik po prostu importuje rzeczy, których potrzebuje ze źródeł wewnętrznych i zewnętrznych. W drugiej sekcji, która definiuje pola prepass węzłów post, znajduje się lista wszystkich potrzebnych nam danych. Przeprowadzenie tego przez prepass gwarantuje, że dane są dostępne wtedy, gdy ich potrzebujemy i nie występują żadne żądania kaskadowe.

Następnie mamy funkcję strony. Na początku wystarczy zebrać potrzebne dane do kilku różnych zmiennych, a mianowicie ogólnych ustawień i podzielonej na strony listy postów. Tagi wewnątrz instrukcji return to kod, który zostanie wizualnie wyrenderowany na stronie internetowej. Najpierw mamy komponent dla nagłówka. Następnie wewnątrz tego głównego komponentu mamy komponent nagłówka wpisu, który wyświetla duży tytuł z napisem Najnowsze posty u góry strony.

Na koniec przechodzimy do komponentu post, który jako parametr przyjmuje listę postów z podziałem na strony. Przyjrzyjmy się, co komponent post robi z tymi informacjami. Tutaj przechodzi przez każdy post zawarty na liście otrzymanych postów. Dla każdego postu wyświetla widok podobny do karty na stronie ostatniego posta. Ten pierwszy składa się z wyróżnionego komponentu graficznego otoczonego linkiem do strony indywidualnego posta na blogu, nagłówka tytułu posta oraz komponentu informacji o poście składającego się z daty i autora posta.

Wracając do pliku Index.js, który wyświetla wszystkie posty, kończymy to, wyświetlając komponent Załaduj więcej na dole strony, aby pobrać więcej postów, jeśli jest to wymagane, oraz stopkę. Ostatnia funkcja, getStaticProps, to statyczna funkcja generowania witryny Next.js, która każe jej wstępnie wyrenderować tę stronę w czasie kompilacji przy użyciu rekwizytów zwróconych przez tę funkcję. I to wszystko.

Dzięki Blueprints za obsługę konfiguracji Headless dla nas. Łatwo było rozbić to, co trafia na stronę postu, aby uzyskać dane z zaplecza WordPress za pomocą WPGraphQL i wyświetlić posty za pomocą komponentów React. Dziękuję za zainteresowanie. Możesz mnie znaleźć na Twitterze @graceerixon.

Sprawdź developers.wpengine.com, aby uzyskać więcej treści na temat Headless WordPress. Mamy samouczek, jak zbudować od podstaw swoją pierwszą witrynę Headless WordPress za pomocą Faust.js, a teraz pracujemy nad serią treści Headless 101. Możesz uzyskać wszystkie narzędzia oferowane przez Atlas, jeśli zarejestrujesz bezpłatne konto Sandbox. Teraz przekażę to Steve'owi, aby porozmawiał więcej o tym, dlaczego Haus wybrał Headless WordPress do swojego projektu leoburnett.com.

STEVE SCAVO: Dzięki, Grace. Cześć, jestem Steve Scavo, CTO w Haus. Jesteśmy kreatywnym studiem technologicznym i agencją z Los Angeles w Kalifornii. Ta prelekcja nosi odpowiedni tytuł Headless 101 dla programistów WordPress. Mówiąc szczerze, nie jestem z zawodu programistą WordPress, ale myślę, że to część piękna architektury bez głowy.

Mogliśmy więc z łatwością nazwać to Headless 101 dla programistów innych niż WordPress, którzy muszą wykorzystać WordPress. To mógł być równie trafny tytuł. To właśnie jest piękne w bezgłowych. Jak zobaczysz, wygrana jest korzystna dla wszystkich stron.

Dlaczego więc bez głowy? Jest tak wiele ważnych powodów, o których moglibyśmy mówić, ale myślę, że mówienie o rzeczywistych przykładach produkcji i rzeczywistych przykładach tego, kiedy błyszczy, jest naprawdę pomocne. I chciałbym zaprezentować projekt, który zrobiliśmy dla Leo Burnetta, używając headless pod bezgłową architekturą. Dla kontekstu Leo Burnett jest znaną agencją reklamową z Chicago, ale ma wiele biur na całym świecie. Mają więc dużo treści, dużo pracy.

Stara strona działała na jednym motywie WordPress. To było naprawdę fragmentaryczne, trochę powolne, nie działało dobrze. Aktualizacja była trudna i nie do końca prezentowała taki prestiż i branding, jaki chciał przekazać Leo Burnett. Tak więc zabraliśmy się do pracy z perspektywy projektowania. I wybraliśmy headless, aby naprawdę zmodernizować ich stos.

Chcieliśmy po prostu, aby wydawał się żywy i świeży oraz miał tego rodzaju możliwości, których potrzebujemy, aby naprawdę stworzyć wspaniałe wrażenia użytkownika i interfejs użytkownika. Chcieliśmy zwiększyć ich moc wydawniczą. Chcieliśmy zwiększyć tempo, w jakim mogą publikować treści. Chcieliśmy przywrócić tożsamość marki i mieć interfejs użytkownika oraz interakcję, styl strony internetowej, który naprawdę emanował Leo Burnettem i wszystkimi tymi małymi akcentami oraz pewnymi punktami redakcyjnymi, typograficznymi i interakcyjnymi, które chcieli przekazać.

A my chcieliśmy przygotować bazę kodu i stronę na przyszłość. Nie chcieliśmy tylko, aby witryna była aktualna przez następne 12 miesięcy. Chcielibyśmy, żeby to było ważne przez następną dekadę, być może. I myślę, że ta bezgłowa architektura, ten bezgłowy stos naprawdę to robi.

Tak więc jednym z początkowych problemów z headless jest to, że zawsze jest wiele decyzji dotyczących hostingu, wdrażania i infrastruktury, i zawsze był to ogromny problem. Tak więc te decyzje dotyczące stosu zawsze pozostawiano programiście. I polujesz w kółko i zastanawiasz się, OK, jakiej innej firmy, może aplikacji CI/CD, potrzebujesz użyć? Czy będziemy to hostować na AWS? Jak to zrobimy? Jakie usługi? A potem wdrażasz tego rodzaju potencjalnie – te rozwiązania ad hoc wokół tego przepływu.

Cóż, platforma Atlas i WordPress Engine Atlas naprawdę to rozwiązuje. To tutaj wchodzi w grę. Zdecydowaliśmy się na Atlas z tych wszystkich powodów, a oni mają tę zarządzaną infrastrukturę usług. Standaryzują rurociąg CI/CD. Naprawdę nie musisz o tym myśleć.

Istnieją migracje danych między środowiskami, które zasadniczo sprowadzają się do przepływu jednego kliknięcia. W przeszłości zawsze stanowiło to duży problem z przejściem od kontroli jakości do etapu produkcji. Zasadniczo WordPress Engine i platforma Atlas sprowadziły to do jednego kliknięcia.

A potem jest tylko zmęczenie związane z mikrousługami i DevOps. Jest tylko duże obciążenie poznawcze związane z tym, o czym musisz myśleć i wspierać oraz być tego świadomym jako programista i utrzymywać go w ruchu. To wszystko rzeczy, które platforma Atlas naprawdę wyjmuje z ręki i rozwiązuje w korzystny sposób.

Porozmawiajmy więc o dynamice, którą moim zdaniem headless naprawdę promuje i naprawdę podkreśla. Pierwszy filar tutaj – jest ich trzech. Pierwszym filarem jest doświadczenie programisty. Pozwala nam wybrać odpowiednie narzędzie do pracy. A kiedy mówię my, mam na myśli programistów.

Pozwala nam wybrać stos, w którym chcemy pisać kod. I to jest dla nas to, co jest w Haus, czyli Next.js i React. Next.js to po prostu wspaniały framework oparty na kilku naprawdę fajnych konwencjach dotyczących routingu, wydajności i architektury aplikacji. Chcieliśmy również wdrożyć system projektowania, a nie tylko system projektowania wizualnego, ale skodyfikowany system projektowania. To jest coś, co sprawia, że ​​nasza aplikacja jest spójna, sprawdzona i piękna.

Interakcje są spójne. Pozwala nam to budować nowe strony i funkcje w tym ekosystemie również w przyszłości, a także zachować to i zachować tę spójność. Pozwala nam również pisać kod deklaratywny i ekspresyjny, a React popiera to jako bibliotekę. Ale wierzymy również w ten styl pisania jako zespół. Pozwala nam wybrać ten stos dla nas na froncie, podczas gdy być może tradycyjna witryna WordPress oparta na motywach, tak naprawdę nie mamy tego samego luksusu.

Potrzebujemy również dużo kreatywnej przestrzeni nad głową. Odwiedzając stronę leoburnett.com, można zobaczyć piękne przejścia między stronami. Są – nie jesteśmy związani z tradycyjnym stosem WordPress dotyczącym tego, jak rzeczy powinny być renderowane. WordPress nie jest już odpowiedzialny za renderowanie frontendu.

Nasza przestrzeń nad głową jest praktycznie nieograniczona. Możemy wybrać nasze biblioteki animacji. Możemy wybrać sposób, w jaki nasze komponenty będą ze sobą współdziałać. To ogromna korzyść po stronie DX.

Doświadczenie administratora jest lepsze i myślę, że zoptymalizowaliśmy to, ponieważ nigdy nie odeszliśmy od ich dawnej znajomości. Nie ma przełączania zaplecza. Przeszliśmy z WordPressa na WordPressa. Nie musieliśmy eksportować danych i pisać skryptów, aby przejść do innego zastrzeżonego systemu. Znajomość jest więc ogromna. Chcieliśmy utrzymać ten rodzaj przepływu dla obecnych administratorów leoburnett.com.

Adopcja i dokumentacja – jeśli spędzasz pięć minut w sieci, prawdopodobnie dotknąłeś zaplecza WordPressa, a tego po prostu nie można przecenić. Leo Burnett ma również wiele bardzo specyficznych punktów zawartości i niestandardowych pól. WordPress oferuje to i daje tę moc, ale udało nam się zaimplementować wtyczkę Advanced Custom Fields, która jest naprawdę fajną konwencją dotyczącą dostosowywania interfejsu administratora, aby był naprawdę przyjazny i użyteczny. Więc to była wygrana w doświadczeniu administratora.

Teraz, oczywiście, trzecim filarem jest doświadczenie użytkownika. To jest naprawdę ważne. Użytkownicy, myślę, że podobnie jak uważamy, że aplikacje internetowe w Haus powinny działać jak aplikacje natywne, nie powinno być żadnych porzuceń. Myślę, że użytkownicy naprawdę to doceniają.

Są bezszwowe. Są responsywni. Po prostu dobrze się czują. I myślę, że chcieliśmy, aby Leo Burnett i wszystkie nasze aplikacje wyglądały w ten sposób. Możliwość wyboru stosu, który chcemy na froncie, pozwala nam to zrobić.

Aplikacje natywne są z natury oddzielone od infrastruktury treści zaplecza, podobnie jak nasze aplikacje internetowe. I to właśnie promuje Atlas. To właśnie ogólnie promuje architektura bez głowy. Promuje również wydajność. Możemy uniwersalnie renderować nasz interfejs użytkownika. Oznacza to, że początkowe obciążenie jest po stronie serwera. A potem klient przejmuje kontrolę.

Jest tu wiele korzyści. Jednym z nich jest uszczęśliwianie wyszukiwarek. Są to treści po stronie serwera. To jest szybkie. Pozwala nam to również na praktycznie natychmiastowe wstępne renderowanie następnej strony i wysyłanie żądań w oparciu o to, co znajduje się w widocznym obszarze za jednym razem.

W przypadku Leo Burnett, jeśli chodzi o interfejs API treści, który zdecydowaliśmy się wykorzystać, skonfigurowaliśmy punkt końcowy GraphQL. Oznacza to, że powracają mniejsze ładunki. Wyraźnie definiujemy dokładnie treść, której potrzebujemy. Po renderowaniu po stronie serwera do renderowania po stronie klienta jest mniej nawodnienia.

Oznacza to mniej kodu przesyłanego przez sieć, mniej odpowiedzi, krótsze czasy odpowiedzi. To zdecydowanie wygrana i sugerowałbym, że jeśli zamierzasz przejść do przepływu pracy Atlas lub bezgłowego przepływu pracy, przyjrzyj się uważnie korzystaniu z interfejsu API GraphQL w porównaniu z czymś w rodzaju interfejsu API REST.

A z perspektywy użytkownika widzi on świeże, aktualne treści. Jest to proces publikowania zoptymalizowany pod kątem wyświetlania podglądu treści. Jest zoptymalizowany pod kątem szybkiego pobierania treści po stronie testowania i podglądu, a następnie promowania ich do produkcji. Administratorzy Leo Burnett są bardzo zadowoleni z łatwości aktualizacji treści, co cieszy użytkowników.

Jaki jest wynik? To tak jakby wszystko poukładać. Inspiruje programistów, produktywnych administratorów i zadowolonych użytkowników. To jest triada i nadzieja, do której, jak sądzę, naprawdę dążą wszystkie zespoły twórców stron internetowych.

Kiedy programiści są zainspirowani, używają zoptymalizowanego zestawu narzędzi. Po prostu dobrze się czuje. Są szczęśliwi. Piszą lepszy kod.

Administratorzy wiedzą, że tworzą piękny ekosystem. To jest szybkie. Wysyła szybko. A użytkownicy widzą tę zaktualizowaną zawartość i doświadczają nowoczesnego, pięknego, dobrze działającego, zoptymalizowanego interfejsu.

Myślę, że podsumowując – tylko kilka końcowych myśli, o których chciałbym, abyście pamiętali. Myślę, że w briefie jako takim zawsze brakuje języka. Myślę, że zbyt często rozmawiamy tylko o tym, hej, zbuduj mi piękną stronę internetową. Zbuduj mi niesamowitą stronę internetową. Chcę, żeby to wyglądało i sprawiało wrażenie — i przeprowadziliśmy wszystkie te recenzje z klientami.

I wszyscy są podekscytowani, a potem pojawia się V1 i zostaje uruchomiona. A potem ludzie, którzy muszą przejąć tę witrynę, są jak, zrobiłeś mi bałagan. Jak o to zadbać? Czy to jakiś przepływ ad hoc, który sobie wymyśliłeś?

Nie chcesz budować pięknej strony internetowej i przekazywać ciężaru. W Haus jesteśmy bardzo dumni z tego, że tego nie robimy. I myślę, że wspaniałe w Atlasie i Atlasie jako platformie jest to, że to rozwiązuje.

Daje ci pewność, że dostarczasz ekosystem i system publikowania w Internecie, który ma sens z punktu widzenia infrastruktury i wdrażania kodu. Daje to udokumentowany dowód zespołowi IT i zespołowi inżynierów lub zespołowi marketingowemu, że wiesz, co robisz i że dzięki tej nowej stronie internetowej, którą dla nich zbudowałeś, są teraz w dobrych rękach.

Ponieważ pamiętaj, nie tylko budujemy stronę internetową. Ustanawiamy system publikowania treści, a jego zrozumienie i zaakceptowanie od pierwszego dnia ma kluczowe znaczenie. I znowu w tym miejscu do gry wkracza Atlas.

Mam więc nadzieję, że ten mały smakołyk pomoże ci strategicznie wyobrazić sobie swój bezgłowy stos w przyszłości. Jeśli chcesz iść w tym kierunku, gorąco zachęcam do zapoznania się z Atlasem. Mam nadzieję, że sesja się podobała i bardzo dziękuję.