Naciśnij to: WPGraphQL i Faust.js

Witamy w Press This, podcaście społeczności WordPress z WMR. Każdy odcinek zawiera gości z całej społeczności i dyskusje na temat największych problemów, przed którymi stoją programiści WordPress. Poniżej znajduje się transkrypcja oryginalnego nagrania.

Obsługiwane przez RedCircle

Doc Pop : Słuchasz Press This, podcastu społeczności WordPress w WMR. Co tydzień zwracamy uwagę na członków społeczności WordPress. Jestem twoim gospodarzem, Doc Pop. Wspieram społeczność WordPress poprzez moją rolę w WP Engine i mój wkład w TorqueMag.Io, gdzie robię podcasty i rysuję kreskówki oraz filmy instruktażowe. Sprawdź to.

Możesz subskrybować Press This w Red Circle, iTunes, Spotify lub pobierać odcinki bezpośrednio na wmr.fm.

W tym odcinku Press This mówimy o Headless WordPress, GraphQL i Faust.js. Jak te narzędzia mogą być używane razem i jaki rodzaj kosztów może być związany z Headless WordPress. Spróbujemy w pewnym sensie zagłębić się w to, a dzisiaj dołączają do mnie dwaj wspaniali goście, mam Jasona Bahla, głównego inżyniera oprogramowania w WP Engine z siedzibą w Denver w Kolorado, gdzie utrzymuje WPGraphQL . Mamy też Chrisa Weigmana, kierownika technicznego pracującego nad Faust.js. Zwykle lubię zaczynać te pokazy od pytania gości o ich historie pochodzenia WordPressa, ale pomyślałem, że tutaj trochę zmienię.

Jason, czy możesz nam powiedzieć, czym jest WPgraphQL i jaka jest jego historia w wordPress Origin.

Jason Bahl: O tak, WPGraphQL to darmowa wtyczka WordPress o otwartym kodzie źródłowym, która wprowadza interfejs API GraphQL do Twojej witryny WordPress, a GraphQL to język zapytań graficznych. Dzięki temu programiści mogą pobierać treści do i z WordPressa za pomocą języka zapytań graficznych.

Wtyczka powstała, kilka lat temu pracowałem w gazecie i dużo dystrybuowaliśmy treści. Mieliśmy sieć składającą się z około 54 witryn w całych Stanach Zjednoczonych i musieliśmy przenosić treści z jednej strony na drugą. Wiesz, kiedy opublikowano wiadomość, różne gazety mogły subskrybować treści z innych gazet.

I tak, kiedy miały miejsce różne zdarzenia, musieliśmy przenieść dane w tej sieci i używaliśmy API REST WordPressa, aby wykonać wiele z tego przenoszenia danych. I mieliśmy z tym pewne problemy techniczne i takie jak rzeczywista wydajność techniczna, ale także doświadczenie programisty. Dowiedziałem się o GraphQL, prawdziwym języku zapytań do wykresów, który został udostępniony przez Facebooka w 2015 roku.

Znalazłem więc tę technologię, wykonałem kilka prototypów, przedstawiłem ją moim współpracownikom, a następnie przenieśliśmy naszą syndykację kontaktów z REST do GraphQL. Potem kontynuowałem pracę nad projektem jako projekt społecznościowy, wiedząc, że frameworki JavaScript stają się na topie i prawdopodobnie byłby to główny przypadek użycia GraphQL, podobnie jak komunikacja serwer-serwer nie jest głównym przypadkiem użycia. Zaspokoiło to nasze potrzeby, ale widziałem szerszą wizję tego, więc dalej nad tym pracowałem jako projekt open source dla społeczności.

D.P.: No fajnie. Chris, czy możesz opowiedzieć nam podobną historię o tym, czym jest Faust i jak do tego doszło?

Chris Weigman: Sure Faust jest, ostatnio, naprawdę w tym tygodniu, oficjalnie udostępniony publicznie, ponownie udostępniony do publicznej platformy do tworzenia bezgłowych witryn WordPress przy użyciu GraphQL. Rozwój rozpoczął się na nim w 2020 roku i był to rodzaj nieoficjalnego projektu WP Engine, a to trzeci główny punkt zwrotny.

Zaczęli to jako rozszerzenie DevRel, zaczęli czynić go trochę bardziej oficjalnym i przestawili się na coś, co nazywa się GQty i bardzo JavaScript, mentalność pierwszego dewelopera. A potem, kiedy przejąłem zespół 1 grudnia ubiegłego roku, zdaliśmy sobie sprawę, że to nie jest nasz rynek docelowy.

Powinniśmy byli tworzyć dla programistów WordPress. Zaczęliśmy więc ponownie go przebudowywać i dopiero niedawno udało się go ponownie wydać.

DP: Jason, niedawno napisałeś na Twitterze, że uruchomiłeś nowy wpgraphql.com na Faust.js. Poprzednia strona, jak sądzę, była bezgłowym WordPressem. Czy możesz po prostu powiedzieć nam o tej zmianie, którą wprowadziłeś i wiesz, jakie ulepszenia mówisz?

J.B.: Tak. Więc wpgraphql.com jest stroną bezgłową od wielu lat. Korzystam więc z wielu źródeł danych. Mam więc dużo treści w WordPress, na przykład wszystkie posty na blogu są w WordPress.

Część dokumentacji istnieje również w WordPressie. A potem pewna dokumentacja istnieje w plikach przeceny w repozytorium GitHub. Najdłużej korzystałem z Gatsby'ego, może przez jakieś trzy lata, korzystałem z Gatsby'ego, który jest frameworkiem JavaScript, który w swej istocie ma swoją warstwę danych, w której można pobierać dane z wielu źródeł.

Więc korzystałem z tego, pobierało dane z GitHub, pobierało dane z WordPressa również przy użyciu WPGraphQL i pozwalało mi używać tych danych do budowania moich szablonów. Więc używałem tego przez kilka lat. W warstwie danych jest wiele problemów, z których chciałem się wydostać.

Chciałem więc użyć Next, na którym zbudowany jest Faust. To kolejny framework JavaScript, ale chyba brakowało wielu elementów. Dalej, a wiele z tych frameworków JavaScript ma pomysł, że twoje front-endowe frameworki powinny definiować cały routing, prawda? Ale jeśli używasz CMS, Twój CMS definiuje routing.

Jest więc wiele technicznych problemów związanych z tym, aby te rzeczy działały ładnie, gdzie na przykład twój front-end ma opinię na jakiś temat, a twój back-end ma inną opinię. Tak więc jednym z problemów, które próbowałem rozwiązać, było sprawienie, aby mój interfejs rozpoznał, że określony adres URL był określonym typem rzeczy, a następnie wyrenderował szablon reprezentujący tę rzecz.

Na przykład post na blogu ma inny szablon niż dokument, archiwum użytkownika lub cokolwiek innego. Chciałem więc, aby mój front-end miał możliwość wysłania adresu URL do CMS, odzyskania danych, ale wiedział, jaki szablon zwrócić. W WordPress nazywa się to hierarchią szablonów. Kiedy więc zespołowi Fausta udało się rozwiązać ten problem, pomyślałem: no tak, przechodzę do Fausta.

Więc tak, jestem w stanie wykorzystać niektóre koncepcje, które istnieją w rdzeniu WordPress, takie jak motywy PHP, i używać ich w trybie headless, dzięki czemu mogę korzystać z zalet React i dowolnego JavaScript, którego chcę użyć na froncie, aby szablonować mój site, ale wciąż znane koncepcje ze świata WordPressa.

DP: Chris, wspominałeś, że Faust przeszedł pewne zmiany. Jakie to były zmiany? Wiesz, Jason o nich wspominał. Jakie zmiany umożliwiły tę poprawę?

CW: Zawsze koncentruje się na WPGraphQL. Tak naprawdę chodziło o wszystko inne. Na przykład ostatnia główna wersja Fausta wykorzystywała bibliotekę pod spodem do interakcji z GraphQL o nazwie GQty, która na papierze brzmiała naprawdę fajnie. Pomysł wywodzący się z zespołu Fausta w tamtym czasie, po prostu abstrakcyjny, ludzie nie powinni wiedzieć, jak budować te złożone zapytania.

Te ramy powinny to dla ciebie streścić. Na papierze wyglądało to naprawdę dobrze, w praktyce z powodu całej złożoności danych WordPress. Nawet jeden typ postu może mieć tak wiele odmian. Może mieszasz to z kategorią, może z różnymi rzeczami. GQty po prostu nie mógł go zasilić.

Co więcej, kiedy został zbudowany z wersją GQty, tak naprawdę nie zwrócono uwagi na problem z routingiem, o którym mówił Jason. Kto zajmuje się trasowaniem? WordPress chce obsługiwać routing na podstawie zawartości, jest to system zarządzania treścią, więc cały routing i WordPress są w dużej mierze oparte na treści.

Next.js to framework frontendowy, więc cały routing jest oparty na tym, że jest to zupełnie inny paradygmat oparty na routingu. To, co mogłoby być /Blog on Next, może nie mieć nic wspólnego z treścią bloga. To idzie do zestawu szablonów. To będzie część aplikacji, która może zbudować bloga.

Podczas gdy /Blog na WordPress może równie dobrze oznaczać, to są wszystkie posty na blogu. I ten paradygmat podczas budowania, jeśli chcesz, aby WordPress był bardzo solidnym frontendem lub CMS-em obsługującym headless, musieliśmy sobie poradzić z tym routingiem. Kolejna zmiana, kiedy to zrobiliśmy, jak powiedziałem w przypadku wersji GQty, naszym celem byli programiści JavaScript, którzy musieli używać WordPress, co wydaje się szlachetne, dopóki nie zdasz sobie sprawy, że to WP Engine.

Mamy do czynienia z agencjami, które od lat budowały na WordPressie, które teraz z różnych powodów, o których możemy powiedzieć później, przechodzą na bezgłową rzecz. Wiedzą, jak rozwijać WordPress. Rozumieją, jak działają routingi szablonów WordPress i szablony, takie rzeczy.

Musimy udoskonalić te funkcje, aby programiści WordPress mogli łatwiej korzystać z GraphQL. I to właśnie było celem Fausta. Hierarchia szablonów po prostu odbudowuje to, co zrobił WordPress. Teraz, jeśli chcesz użyć routingu Next, istnieją sposoby na zastąpienie go w aplikacji, aby nic nie stracić.

Ale dla ludzi, którzy używają WordPressa jako prawdziwego systemu zarządzania treścią, zdolnego do kierowania treścią przez zarządzanie treścią, Faust poradzi sobie z tym znacznie lepiej? Czy to ma sens?

DP : Tak. Absolutnie. Wiesz, myślę, że to dobre miejsce na krótką przerwę. Słuchasz Press This, podcastu społeczności WordPress z Chrisem Weigmanem i Jasonem Bahlem. Wrócimy, aby porozmawiać o WordPress i headless. Bądźcie czujni.

DP: Wracamy z Press This. I wiesz, Chris, tuż przed tą przerwą wspomniałeś o czymś, wspomniałeś o coraz większej liczbie firm, które wchodzą w bezgłowy, i wiem, że WP Engine przeprowadził wiele badań pokazujących, że tak jest. Zastanawiam się, bezgłowy zdecydowanie ma reputację czegoś, myślę, że przedsiębiorczość, kiedy myślę bezgłowy, czy myślę poprawnie. Czy to jest to, co jest bez głowy? Czy jest to tylko narzędzie dla przedsiębiorstw, czy jest to narzędzie, z którego będzie korzystać więcej witryn?

CW: Tak i nie. W dużej mierze bezgłowy, zwłaszcza w przypadku WordPressa w tej chwili, złożoność związana z tym oznacza, że ​​​​prawdopodobnie masz pełny zespół budujący to, czego potrzebujesz.

To nie jest ktoś, kto po prostu używa WordPressa od razu po wyjęciu z pudełka, że ​​po prostu chcesz mieć osobistego bloga. Może to zrobić, ale jak dotąd jest to znacznie cięższa winda, aby móc to zrobić. To samo z Contentful, to samo ze wszystkimi innymi systemami CMS. Jeśli po prostu chciałeś czegoś prostego, czegoś, co wiesz, typ treści, który jest w sieci od lat, bezgłowy, to prawdopodobnie więcej pracy, niż chcesz sobie z tym poradzić.

Czy to stricte przedsiębiorczość? Spójrz, nie. Gatsby pracuje nad tym problemem od lat. Masz później kolejny podcast, Doktorze z Mastodontem. To społeczność, z którą jestem związana od wielu lat. Większość ludzi używa odmian bezgłowych CMS-ów, zwłaszcza Gatsby'ego, ale jest też Hugo. Jest wiele różnych, tego typu technologii na bardzo oddolnym poziomie.

Więc kończysz z użytkownikami oddolnymi i kończysz z użytkownikami korporacyjnymi dla ciężkich witryn, podczas gdy WordPress tradycyjnie wydaje się upadać ze wszystkimi innymi pomiędzy. To osoba, która nie chce zajmować się plikami przeceny i kodem, tak jak mógłby to zrobić użytkownik Gatsby, lub wiesz, po prostu Gatsby po wyjęciu z pudełka.

Ale nie jest to również ktoś, kto ma cały 10-osobowy zespół budujący swoją markę osobistą lub osobistego bloga. To usuwa WordPressa z tego środka i bardzo łatwo rozszerza go na oba końce. Teraz możesz łatwo budować między GraphQL, masz wszystkie dane i masz stale rosnący zestaw sposobów obsługi tych danych.

A Faust znacznie ułatwia wykorzystanie tego i czegoś, co można zbudować w ciągu jednego dnia zamiast miesiąca.

DP: Jason, Chris wspomniał o czymś, o czym chciałbym usłyszeć twoje zdanie. Słyszałem, że może to nie jest dobre dla małych zespołów, małych blogerów, takich jak ja, co oczywiście ma sens, nie potrzebuję WordPressa bez głowy, ale lubię , zastanawiam się, czy bezgłowy WordPress będzie mnie kosztował więcej, ponieważ będę musiał mieć programistę iOS i programistę WordPress? Czy jest droższy, czy w jakiś sposób bardziej opłacalny?

JB: Pewnie zależy od tego, co produkujesz. Jeśli robisz, jak wspomniałeś iOS, jeśli robisz natywną aplikację mobilną, mam na myśli, że niezależnie od tego wiążą się z tym koszty i nie ma naprawdę dobrego sposobu, aby to zrobić, jeśli używasz danych z WordPress, inne niż robienie tego bez głowy, bo wiesz, natywna aplikacja nie renderuje php, więc musiałbyś to zrobić bez głowy.

Ale jeśli tworzysz teraz dla sieci w tradycyjnym WordPressie, możesz znaleźć motyw, znasz albo darmowy motyw, albo znajdź motyw na rynku, pobierz go, zainstaluj i jesteś ruszać na wyścigi. Większość ludzi zamierza dostosować go w taki czy inny sposób.

Więc zwykle będziesz mieć koszt programisty, niezależnie od tego, czy robisz to sam, czy ktoś inny. Jedną z rzeczy, które różnią się od tradycyjnego motywu PHP bezgłowego WordPressa, jest to, że na przykład kiedy uruchomiłem nową stronę wpgraphql.com, mogłem korzystać z tej samej instancji WordPressa, która zasilała moją witrynę Gatsby.

Dostałem dane, dane wychodziły i trafiały na stronę Gatsby, mogłem kontynuować publikowanie treści w CMS, jednocześnie opracowując mój kolejny interfejs. W przypadku tradycyjnego programowania WordPress zazwyczaj musisz przeprowadzić migrację swojej witryny do środowiska przejściowego.

Aktywuj nowy motyw w tym środowisku, zbuduj tam swój motyw, zajmij się czymś w rodzaju okresu zamrożenia treści, w którym mówisz swoim twórcom treści: „Hej, dzisiaj nie możesz publikować treści, ponieważ zamierzamy przeprowadzić migrację, a potem my” ponownie ustawię nową instancję WordPress, instancję na żywo”. A potem musisz się tam zalogować i zacząć prawidłowo tworzyć swoje treści.

Bezgłowy WordPress, udało mi się odbudować moją witrynę na zupełnie innym stosie frontendu bez zakłócania czegokolwiek w mojej rzeczywistej instancji WordPress, to oddzielenie danych i prezentacji, prawda? Mogłem więc iść, gdybym chciał jutro zbadać kolejną gorącą technologię, na przykład gdybym mógł skupić się na Svelte zamiast na Next i nie musiałbym niczego zmieniać w WordPressie.

Więc w niektórych przypadkach może to być faktycznie tańsze, ponieważ cały ten proces uruchamiania innego serwera, zmuszania zespołu do zaprzestania pisania treści, a następnie przeniesienia się do innej instancji WordPressa, a następnie rozpoczęcia publikowania tam, przeprowadzania migracji delta i tym podobnych rzeczy, to też kosztuje.

Inną interesującą rzeczą jest to, że ekosystem JavaScript jest naprawdę dostępny. Wspólnym napędem, moim zdaniem, jednym z powszechnych motywatorów do poruszania się bez głowy, są architektury oparte na komponentach. W ekosystemie React i VUE dostępne są różnego rodzaju biblioteki komponentów, które umożliwiają ponowne wykorzystanie komponentów w różnych projektach.

Dzięki temu agencje mogą tworzyć wspólne komponenty, których używają w projektach, i aktualizować je w centralnym miejscu, a następnie instalować je w wielu projektach. W przypadku WordPress nie jest to takie proste, ponieważ części szablonu PHP i WordPress są zwykle bardzo ściśle powiązane z projektem, do którego należą.

Gdzie z headless możesz mieć pakiet MPM, który ma te komponenty, a wiele projektów może aktualizować ten pakiet i czerpać korzyści jednocześnie przy mniejszym wysiłku. Myślę więc, że w tej chwili powiedziałbym, że prawdopodobnie jest to bardziej kosztowne i wymaga więcej pracy, ale myślę, że narzędzia takie jak Faust, które do niedawna nie istniały, zmniejszają ogólny wysiłek wymagany do budowania bez głowy.

I myślę, że w niezbyt odległej przyszłości budowanie bez głowy może być tańsze niż bez głowy.

DP: Chris, czy masz coś, co chciałbyś dodać do tego, o czym agencje mogą pomyśleć pod względem kosztów bezgłowego WordPressa?

CW: Myślę, że Jason naprawdę trafił w sedno.

Jedną z rzeczy, które lubię w WPGraphQL, jest to, że mój zespół pracuje dalej nad rozszerzeniem WordPress w tym kierunku o to, co nazywamy, naszym roboczym tytułem jest React Gutenberg Bridge, ale jest to również problem w WordPress. Jak ponownie wykorzystać te komponenty? Nie chcę używać słowa tylko komponent, ponieważ nie ma to zastosowania po stronie WordPress w taki sam sposób, jak po stronie JavaScript, prawda?

Ale w jaki sposób ponownie wykorzystujemy kod w różnych projektach, bez headless lub w inny sposób z WordPress, a headless to umożliwia. Ale myślę, że można bezpiecznie powiedzieć, że przeciętny bloger próbujący tylko wydobyć swoje blogi kulinarne, prawdopodobnie sam sobie z tym nie poradzi. To w dużym stopniu problem agencji. Czy to większy koszt?

Może, może nie, ale to się komplikuje, kiedy mówimy o kosztach? Ponieważ są to różne rodzaje sposobów korzystania z danych.

DP: Tak, absolutnie. Wiesz, Jason, pochodząc z gazety, pracując w Weeklys w Twin Cities iw Nashville, mogę sobie wyobrazić, jak by to było, gdybyś powiedział swoim 56 gazetom, żeby nie publikowały przez jeden dzień.

Brak wiadomości dzisiaj, ponieważ aktualizujemy stronę.

J.B.: Tak. I to znaczy, przechodziliśmy przez te okresy, prawda? Tak jak wtedy, gdy mnie tam zatrudniono, nie korzystali z WordPressa, więc częścią mojej pracy było przeniesienie ich z innego systemu do WordPressa. Więc na pewno były dni, kiedy było tak, w porządku, to działa w dniu WordPressa. Przestań robić to, co robisz. Prawidłowy.

Więc na pewno były takie okresy lub też musieliśmy sobie poradzić z tym problemem, okej, publikowali na starym systemie do północy zeszłej nocy, ale WordPress był gotowy do pracy dwa dni wcześniej. Więc teraz musimy zrobić migrację typu Delta i upewnić się, że wszystkie dane są nadal zsynchronizowane, więc wiesz, że te procesy na pewno wiążą się z kosztami technicznymi i ludzkimi.

DP: Tak. I myślę, że jest też wiele rzeczy, kiedy nadal używasz WordPressa, nadal masz ten ekosystem, dzięki któremu możesz zaoszczędzić na kosztach. Nie musisz budować narzędzi SEO.

Możesz użyć wtyczki Yoast SEO lub cokolwiek innego. Zakładam, że nawet jeśli jesteś witryną Headless, większość wtyczek będzie nadal działać, o ile nie będą skierowane do przodu.

J.B.: Tak. To faktycznie ciekawa sprawa. Tak więc nowy Faust jest zbudowany z samą architekturą wtyczek. Więc jak po wyjęciu z pudełka, będzie dostarczany z klientem, używa klienta Apollo, dzięki czemu możesz pobierać dane z WPGraphQL, możesz pobierać dane WordPress, ale możesz tworzyć wtyczki, więc powiedzmy, że zrobiłeś to, tak jak ty wspomniano, zainstaluj Yoast SEO na swojej stronie WordPress.

Możesz dodać wtyczkę Yoast. Jeszcze nie istnieje, ale wkrótce może. Możesz dodać wtyczkę Yoast dla Fausta na interfejsie, która wie, co zrobić z tymi danymi, prawda? Będzie więc możliwość dla ludzi, niektórych możemy produkować i wspierać, ale niektórzy, społeczność może również tworzyć i wspierać wtyczki dla strony Fausta, dzięki czemu wystarczy jedna linia kodu, dodanie tej wtyczki może uzyskaj funkcjonalność, taką jak Yoast, dla swojego bezgłowego interfejsu.

Jest to coś, czego nie sądzę, aby jakikolwiek inny bezgłowy frontend naprawdę miał koncepcję w taki sam sposób, w jaki podchodzi do tego Faust. Myślę więc, że wtyczka jest kolejną rzeczą znaną programistom WordPress. Przynosi znane koncepcje z WordPress, ale łączy je z nowoczesnym stosem frontendu JavaScript.

DP: to jest dobre miejsce na ostatnią przerwę w Press This, a kiedy wrócimy, podsumujemy naszą rozmowę z Chrisem Weigmanem i Jasonem Bahlem. Bądźcie czujni.

DP: Słuchasz Press This, podcastu społeczności WordPress. Jestem twoim gospodarzem, Doc Pop. Dzisiaj mówimy o WPGraphQL, Faust i o tym, jak możesz zasilić swoją bezgłową witrynę WordPress. Tuż przed przerwą rozmawialiśmy o Fauście i wtyczkach, a ja po prostu rzucę wam kilka przypadkowych pytań i po prostu zobaczę, czy pojawią się tutaj jakieś dobre odpowiedzi.

Ale Chris, zastanawiam się, czy z Faustem jest jakiś potencjał, wiem, że to platforma bezgłowa, ale czy jest jakiś potencjał dla motywu WordPress Fausta, który przynajmniej sprawi, że się z nim skonfigurujesz, oto wtyczki, których potrzebujesz, a tutaj jest po prostu wszystko gotowe.

CW: Absolutnie. Właściwie już to mamy. Nazywamy to Planami, ponieważ bardzo dobrze współpracuje z Lokalnymi. Większość ludzi dokona pewnych poprawek w tych rzeczach przed uruchomieniem ich na platformie takiej jak WP Engine. Więc pożyczyliśmy od Locala nazwę Blueprints.

W przypadku nowego Fausta mamy jeden o nazwie Portfolio, który jest w zasadzie pełnym motywem portfolio i pracujemy nad bardzo pustym rusztowaniem, z którego mogą korzystać agencje. Gdy już to opanujesz, prawdopodobnie będziesz chciał wszystko dostosować samodzielnie. Tak więc rusztowanie byłoby najlepszymi praktykami projektowymi, zakręć nim, a następnie możesz zrobić z nim wszystkie własne rzeczy.

Długoterminowo dużo rozmawialiśmy o bezgłowym sklepie z motywami, ala Blueprints. Nie mamy siły roboczej, więc jest to trochę daleko, ale jest to absolutnie coś, co rozważamy i chcielibyśmy zobaczyć.

DP: Tak, fajnie o tym pomyśleć. To zupełnie inny rodzaj ekosystemu, do którego można się dostać.

I wiesz, Jason, przeprowadzałem już z tobą wywiad i jestem pewien, że to pytanie pojawia się cały czas, ale za każdym razem, gdy słyszę o WPGraphQL, myślę, że brzmi to bardzo podobnie do tego, co robi REST API. Właściwie brzmi to o wiele potężniej niż to, co robi REST API, a REST API jest częścią rdzenia i po prostu zastanawiam się, czy uważasz, że WPGraphQL powinien być częścią WordPress Core?

J.B.: Może kiedyś. Myślę, że jeszcze tam nie jesteśmy. Kiedy rzeczy zostają scalone w WordPress Core, prawdopodobnie z wyjątkiem Gutenberga, innowacja zatrzymuje się. Na przykład interfejs API REST nadal zawiera błąd, na który zwracam uwagę ludziom, który nadal istnieje chyba od 2016 r. Mam na myśli to, że kiedy coś trafia do rdzenia, dodajesz zestaw funkcji do 40 procent sieci i więc wprowadzanie zmian musi odbywać się w znacznie wolniejszym tempie, a jeśli jest to wtyczka, możesz pozwolić ludziom wybrać wersję, na którą chcą się zapisać, i możesz iterować znacznie szybciej, ponieważ mogą wybrać wersję, która najlepiej pasuje do ich projektu.

Gdzie w rdzeniu, jeśli zaktualizujesz rdzeń i obejmuje to przełomową zmianę, być może zepsułeś 40 procent sieci. Więc GraphQL jest specyfikacją, nie ma też nic wspólnego z WordPressem.

Prawidłowy. I tak specyfikacja GraphQL wciąż ewoluuje. A ponieważ to wciąż ewoluuje, chcemy nadążać za najnowszymi i najlepszymi specyfikacjami GraphQL. Gdybyśmy dzisiaj połączyli, powiedzmy, WPGraphQL z Core, a GraphQL ewoluuje, WordPress utknąłby w wersji GraphQL 2022, podczas gdy reszta świata korzysta z wersji 2030 lub cokolwiek innego. Dla mnie myślę, że w pewnym momencie może mieć sens rozpoznanie go, tak jak WPCLI jest oficjalnym sposobem na zrobienie rzeczy X.

Na przykład możesz zbudować własnego klienta CLI dla WordPress, ale społeczność uznaje, że WPCLI jest oficjalną rzeczą. Nie jest częścią WordPress Core, ale jest uznawana przez Fundację WordPress i większość społeczności WordPress za coś oficjalnego. Więc może być miło w pewnym momencie, aby WPGraphQL został rozpoznany w ten sposób, na przykład, jeśli zamierzasz zrobić bezgłowego WordPressa, zrób to w ten sposób.

Nadal pozostanie wtyczką. To moja myśl. Może być czas, w którym GraphQL wydaje się idealny i tak naprawdę nie jest powtarzany, i być może w tym czasie rozważamy to. Ale w tej chwili w specyfikacji GraphQL pojawią się rzeczy, które spowodują przełomowe zmiany w interfejsie API.

Więc robienie tego jako wtyczki ma dla mnie sens.

DP: Zaraz. I tak, wspomniałeś o WPCLI, a ja wciąż zapominam, jakby oni po prostu czuli, że to część rdzenia. Bez względu na to, jak to wygląda, jest to oficjalne. Więc tak, to jest jak, o tak, to jest jak ta niezależna rzecz, tak jak WPGraphQL w tej chwili.

To dobra analogia. Więc zakończę, zakończę tutaj. Naprawdę świetnie się rozmawiało z wami obydwoma. Jeśli słuchacze są zainteresowani obserwowaniem któregoś z was, możesz śledzić @JasonBahl i @ChrisWeigman. Umieścimy uchwyty Twittera w opisie programu, jeśli to możliwe. Słuchałeś Press This, podcastu społeczności WordPress na temat WMR.

W odcinku w przyszłym tygodniu Anne McCarthy, łącznik ds. produktu w Automatic, opowie o zmianach w edycji witryny i wersji 6.1 oraz o tym, co nadchodzi w wersji 6.2. Jeszcze raz dziękuję za wysłuchanie Press This.

Możesz śledzić moje przygody z magazynem Torque na Twitterze @thetorquemag lub wejść na Torquemag.io, gdzie codziennie publikujemy samouczki, filmy i wywiady, takie jak ten. Sprawdź więc torquemag.io lub śledź nas na Twitterze. Możesz subskrybować Press This na Red Circle, iTunes, Spotify lub pobrać go bezpośrednio na wmr.fm co tydzień. Jestem twoim gospodarzem Doctor Popular Wspieram społeczność WordPress poprzez moją rolę w WP Engine. I uwielbiam zwracać uwagę członków społeczności każdego tygodnia na Press This.