Eksperymenty projektu WordExpress z wprowadzeniem GraphQL do WordPress

W 2012 roku, kiedy Facebook zaczął przebudowywać swoje aplikacje mobilne oparte na HTML5 na natywne aplikacje na iOS lub Androida, firma wynalazła GraphQL. Ten nowy język zapytań o otwartym kodzie źródłowym jest ogłaszany jako bezpośredni zamiennik REST. GraphQL zapewnia wydajniejszy sposób obsługi ilości interakcji, które mają miejsce każdego dnia w aplikacjach Facebooka, ale jest niezależny od bazy danych i zbudowany do użytku poza Facebookiem.

Chociaż GraphQL jest wciąż stosunkowo nowy, duże firmy, takie jak Intuit, Coursera, Pinterest i Shopify, używają go w produkcji. W zeszłym miesiącu GitHub ogłosił obsługę GraphQL dla swojego interfejsu API GitHub, aby odpowiedzieć na niektóre wady architektury REST.

GraphQL oferuje nowy sposób strukturyzacji komunikacji od klienta do serwera, który sprawia, że ​​pobieranie danych jest wydajniejsze. W swoim artykule GraphQL w dobie REST API, Petr Bela podsumowuje różnicę między tymi dwoma typami architektury:

Siła GraphQL bierze się z prostego pomysłu — zamiast definiowania struktury odpowiedzi na serwerze, klient otrzymuje elastyczność. Każde żądanie określa, jakie pola i relacje chce odzyskać, a GraphQL skonstruuje odpowiedź dostosowaną do tego konkretnego żądania. Zaleta: do pobrania wszystkich złożonych danych, które w innym przypadku mogłyby obejmować wiele punktów końcowych REST, i jednocześnie zwrócenia tylko tych danych, które są rzeczywiście potrzebne, i nic więcej, potrzebna jest tylko jedna podróż w obie strony.

W zeszłym miesiącu Facebook ogłosił, że GraphQL wychodzi z etapu „podglądu technicznego” i jest gotowy do produkcji. Został zaimplementowany w wielu różnych językach programowania i został już przyjęty przez firmy, które chciały wydajniejszego sposobu dostępu do danych.

WordExpress wprowadza GraphQL do WordPress

Ramsay Lanier, programista front-end JavaScript, który pracuje w nclud w Waszyngtonie, stworzył implementację WordPress opartą na GraphQL o nazwie WordExpress. Lanier nie jest fanem PHP i nie lubi pracować z pętlami ani szablonami, czyli wszystkimi rzeczami, które w przeszłości stanowiły większość rozwoju front-endu WordPress. Stworzył WordExpress jako aplikację Node.js w celu zastąpienia PHP przez JavaScript w prezentacji WordPress. Używa Express na backendzie i React na frontendzie. GraphQL znajduje się pomiędzy tymi dwoma, aby pobrać dane z bazy danych WordPress.

„Kiedy początkowo zacząłem od pomysłu na WordExpress, chciałem użyć interfejsu API REST, ale stwierdziłem, że istniejące punkty końcowe nie są tym, czego chciałem” – powiedział Lanier. „W końcu musiałbym napisać kilka niestandardowych punktów końcowych i połączyć ze sobą wywołania. Pomyślałem więc, że spróbuję GraphQL.”

Odkrył, że GraphQL jest bardziej wydajny niż REST, ponieważ ogranicza podróże w obie strony do serwera, pozwalając programistom skupić się na tym, jakich danych klient naprawdę potrzebuje. Lanier podkreślił korzyści związane z witrynami WordPress:

Dzięki GraphQL klient określa dokładne dane, których potrzebuje, za pomocą zapytania GraphQL. Zapytanie GraphQL ma niestandardową funkcję rozwiązywania, która określa sposób pobierania danych. W tej funkcji możesz nawet trafić do wielu baz danych. Na przykład w przypadku WordPressa masz bazę danych MySQL, ale możesz również mieć bazę danych Mongo dla aplikacji, która przechowuje inne dane, które nie muszą być relacyjne. W funkcji rozwiązywania GraphQL można wykonywać wywołania w celu pobrania danych z obu baz danych i odesłania ich z powrotem do klienta w ramach jednej podróży w obie strony do serwera.

WordExpress w swojej obecnej formie jest dobrym punktem wyjścia do tworzenia aplikacji opartych na JavaScript, które wykorzystują WordPress do administracji. Lanier powiedział, że ta konfiguracja programistyczna pozwala mu znacznie łatwiej tworzyć komponenty stron internetowych i aplikacji niż przy użyciu szablonów PHP.

„Dzięki React każdy komponent zawiera nie tylko znaczniki do wyświetlania rzeczy, ale także stylizację dla tego komponentu, dane wymagane do pracy, a także dowolną logikę interakcji – wszystko w jednym lub dwóch plikach” – powiedział.

Aktualne wyzwania WordExpress: Zgodność wtyczek i renderowanie po stronie serwera

Pomimo wszystkich ekscytujących korzyści płynących z bardziej wydajnych zapytań i możliwości zastosowania frontendu opartego na JavaScript, projekt WordExpress ma wiele poważnych wyzwań, które mogą sprawić, że będzie on kłopotliwy w użyciu w produkcji poza prostą instalacją bloga. Nie jest kompatybilny z większością wtyczek WordPress, ponieważ większość jest napisana w PHP.

„Zasadniczo wymieniłem cały interfejs, co oznacza, że ​​wszelkie wtyczki, które wpływają na interfejs, nic nie zrobią” — powiedział Lanier. „Jednak z pewnością możesz wykorzystać istniejące wtyczki, które mają wpływ na stronę administracyjną (takich jak zaawansowane pola niestandardowe lub wtyczka AWS S3). Wszystko, co manipuluje sposobem przechowywania danych WordPressa w MySQL, jest nadal użyteczne – wystarczy zmodyfikować schemat GraphQL i zapytania, aby z nimi pracować.”

Innym poważnym wyzwaniem jest uruchomienie renderowania po stronie serwera, które jest wymagane do obsługi takich rzeczy, jak SEO i metatagi. Apollostack, którego WordExpress używa do pobierania danych i dostarczania ich do komponentów React, dopiero niedawno dodał wczesne wsparcie dla automatycznego renderowania po stronie serwera.

„Przestawiłem się z przekaźnika Facebooka na ApolloStack” — powiedział Lanier. „Oba są całkiem nowymi technologiami i nie jestem pewien, czy któryś z nich naprawdę wymyślił, jak bardzo dobrze radzić sobie z renderowaniem po stronie serwera. Nie zaglądałem do tego od kilku miesięcy, a dzięki ApolloStack sprawy potoczyły się dość szybko, więc mogli już to rozgryźć”.

Na razie WordExpress jest tylko potwierdzeniem koncepcji, a Lanier powiedział, że nie planuje próbować wspierać istniejących wtyczek. Biorąc pod uwagę, że WordExpress nie może obecnie wykorzystywać motywów i wtyczek, jednych z najlepszych części ekosystemu WordPress, Lanier powiedział, że programiści, którzy używają tego stosu, są prawdopodobnie bardziej zainteresowani zachowaniem mocy strony administracyjnej WordPressa.

„Uwielbiam administratora WordPressa” – powiedział. „Jest bardzo wydajny i łatwy w użyciu do zarządzania treścią. WordExpress byłby punktem wyjścia dla każdego programisty JavaScript, który chce tworzyć aplikacje WordPress przy użyciu samego JavaScriptu”.

Celem Lanier z WordExpress jest przekształcenie go w pakiet npm, który można ponownie wykorzystać w wielu różnych projektach React. Opublikował już dwa współpracujące ze sobą pakiety WordExpress npm: wordexpress-schema (obsługuje schemat GraphQL i ustawienia połączeń) oraz wordexpress-components (obecnie zawiera dwa pierwsze komponenty, WordExpressPage i WordExpressMenu). Ponieważ projekt jest oparty na Node.js, programiści mogą korzystać z dowolnego pakietu npm, co jest pocieszeniem w przypadku ograniczonej kompatybilności wtyczek.

GraphQL i WP REST API

Wielu z tych, którzy przewidują, że GraphQL stanie się bezpośrednim zamiennikiem REST, jest również zdania, że ​​te dwa elementy mogą współistnieć. W rzeczywistości Facebook niedawno napisał przewodnik dotyczący pakowania interfejsu API REST w GraphQL.

„Prawdopodobnie, jeśli GraphQL okaże się skuteczny, będzie współistniał z interfejsami API REST”, powiedział Petr Bela. „Niektóre interfejsy API będą korzystać z REST, inne z GraphQL. Niektórzy mogą wspierać jedno i drugie”. Przewiduje, że całkowite przejście z REST na GraphQL zajęłoby branży lata, a może nawet dekadę.

WordExpress firmy Lanier, który niedawno otrzymał 1000 gwiazdek na GitHub, jest obecnie jedynym projektem open source, który publicznie bada implementację WordPressa opartą na GraphQL. Pobieżne wyszukiwanie w serwisie GitHub ujawnia, że ​​wielu innych eksperymentuje z podobnymi konfiguracjami. Na szczęście GraphQL nie wymaga żadnych zmian w rdzeniu WordPressa, aby umożliwić stronom korzystanie z API do przeszukiwania bazy danych.

Lanier powiedział, że docenia pracę tych, którzy próbują połączyć API WP REST z rdzeniem i nie postrzega implementacji GraphQL jako zagrożenia.

„Myślę, że praca, którą wykonują z REST API, jest dobra”, powiedział. „Zdecydowanie musieli zrobić ten krok. REST istnieje już od dłuższego czasu – GraphQL jest wciąż całkiem nowy, więc warto wybrać trasę REST. Ponadto dużo więcej osób wie, jak z niego korzystać. Zaletą GraphQL jest to, że można go używać do pakowania interfejsu API REST, dzięki czemu oba mogą współistnieć”.

Możliwość wyjścia WordExpress poza prosty dowód koncepcji zależy od opinii społeczności. Lanier powiedział, że programiści wykazują zainteresowanie WordExpressem poprzez rozwidlenie go i zadawanie pytań.

„Ludzie go używają, bawią się i (miejmy nadzieję) czynią go swoim” – powiedział. „Myślę, że jest zainteresowanie. Aby było to naprawdę wykonalne, potrzebujesz całego zespołu programistów, dzięki czemu jest to najlepsza opcja”.

Lanier niedawno podjął nową pracę, w której używa React w 100% i od jakiegoś czasu nie miał okazji korzystać z WordPressa, ale powiedział, że jest otwarty na badanie współpracy, aby przygotować produkcję WordExpress.

„Gdyby ludzie byli naprawdę zainteresowani i chcieli zebrać się razem, aby przekształcić to w wykonalne rozwiązanie, byłbym w to zaangażowany w 100%” – powiedział.

Deweloperzy, którzy chcą to przetestować i zacząć programować z WordExpressem, będą potrzebować podstawowej wiedzy na temat działania Reacta. Lanier napisał szczegółową dokumentację dotyczącą konfiguracji implementacji GraphQL oraz rozszerzania zapytań GraphQL i modeli baz danych. Witryna WordExpress.io to demo kodu na żywo, które można znaleźć na GitHub.