🙅♀️ Dlaczego GraphQL nie powinien być w rdzeniu WordPress
Aktualizacja 01/05/2024: Sprawdź porównanie Gato GraphQL vs WP REST API.
Tak, dobrze przeczytałeś tytuł. Mimo że sam jestem twórcą serwera GraphQL dla WordPress, zmieniłem zdanie na temat tego, czy WordPress powinien być dostarczany z GraphQL.
Jeszcze nie tak dawno temu wierzyłem, że GraphQL powinien być w rdzeniu WordPress. Logika była taka, że współtwórcy poświęcali czas i wysiłek na implementowanie funkcjonalności w WP REST API (operacje wsadowe), które są natywne dla GraphQL.
Jednak ostatnio dowiedziałem się kilku nowych rzeczy, które skłoniły mnie do ponownego przemyślenia, i teraz uważam, że WordPress nie powinien być dostarczany z GraphQL, ze względu na dodatkowe ryzyka.
Oto moje powody.
1. Nie spełnia reguły 80/20
Historycznie, określona funkcjonalność jest dodawana do rdzenia WordPress tylko wtedy, gdy spełnia regułę 80/20, co oznacza, że 80% lub więcej użytkowników z niej skorzysta.
Czy tak byłoby w przypadku GraphQL? Myślę, że odpowiedź brzmi „nie", opierając się na precedensie wprowadzenia WP REST API do WordPress 4.7.
W swojej prezentacji WordPress as Data, 5 Years In, K. Adam White (główny odpowiedzialny za początkowy rozwój i wydanie WP REST API) opisał, że współtwórcy spodziewali się, że REST API będzie szeroko stosowane po wydaniu z rdzeniem. Ale tak się nie stało: programiści nadal tworzyli strony WordPress w ten sam sposób co wcześniej, zwracając niewielką uwagę na podejście headless czy REST API.
Sytuacja zmieniła się dopiero później, wraz z wprowadzeniem edytora Gutenberg w WordPress 5.0, który był oparty na REST API. Czy Gutenberg mógłby zatem uzasadnić dodanie GraphQL do rdzenia WordPress?
2. Headless jest już obsługiwany przez REST API
Edytor WordPress może być wzbogacony o natywny serwer GraphQL, pozwalając programistom bloków używać GraphQL (oprócz istniejącego REST API) do pobierania danych dla swoich bloków. Ponadto, motywy i wtyczki mogłyby korzystać z GraphQL do zasilania własnych wewnętrznych funkcjonalności. To są mocne argumenty za dodaniem GraphQL do rdzenia WordPress.
Jednak WordPress już posiada REST API, a wszystko, co można zrobić z GraphQL, można też zrobić z REST. Wprowadzenie GraphQL obok REST jest jak kupno BMW, gdy już jeździsz Toyotą. Dotrzesz do celu szybciej, a doświadczenie jazdy będzie przyjemniejsze. Ale oba samochody zawiezą cię tam, gdzie chcesz.
Ponieważ GraphQL nie dostarczy wcześniej niedostępnej funkcjonalności, jego włączenie do rdzenia nie jest w pełni uzasadnione. GraphQL z pewnością poprawiłby doświadczenie interakcji z API, ale to z powodzeniem można uznać za domenę wtyczek.
3. Motywy i wtyczki WordPress mogą używać webonyx/graphql-php
Publiczne wtyczki nie mogą wymagać, aby strona instalowała WPGraphQL lub Gato GraphQL do korzystania z wtyczki, ponieważ zmniejszyłoby to ich potencjalny zasięg. Dlatego publiczne wtyczki nie mogą polegać na GraphQL, co jest naprawdę szkoda.
Długo myślałem o tym problemie i wymyśliłem potencjalne rozwiązanie: GraphQL API Private, samodzielny silnik GraphQL, który wtyczki mogą wbudować do własnego użytku, dystrybuowany jako pakiet Composer. (Nie zacząłem jeszcze pracować nad tym projektem.)
Ale wtedy, kilka tygodni temu, została wydana wtyczka WordPress zasilana przez GraphQL. Zastanawiałem się, jak autor to zrobił: czy korzystałby z WPGraphQL lub Gato GraphQL pod spodem? Sprawdziłem więc jej kod źródłowy i, jak się okazuje, bezpośrednio używa webonyx/graphql-php!
To interesujące rozwiązanie, które pokazuje, że przy odrobinie wysiłku programiści mają już dostęp do GraphQL dla swoich motywów i wtyczek.
Ta wtyczka używa GraphQL do pobierania własnych encji danych, a nie tych WordPress (posty, użytkownicy, komentarze itp.). Dlatego nie musi odtwarzać schematu GraphQL zawierającego model danych WordPress, jak robią to WPGraphQL i Gato GraphQL (i ewentualnie GraphQL API Private). Dlatego poleganie na webonyx/graphql-php ma sens.
4. GraphQL niesie ze sobą dodatkowe ryzyka
Trzy powyższe kwestie sugerują, że GraphQL ulepszyłby WordPress, nawet jeśli nie jest to szczególnie przekonujące. W tym świetle moglibyśmy mimo wszystko dodać GraphQL do rdzenia WordPress, i albo na tym skorzystać, albo nic się nie stanie.
Ale ta 4. kwestia sugeruje, że jeśli GraphQL nie wniesie dużej wartości do WordPress, to nie powinien być dodawany, ze względu na dodatkowe ryzyka.
GraphQL jest podatny na następujące wektory ataków (między innymi):
- Pojedynczy endpoint zapewnia dostęp do wszystkich informacji z witryny, więc prywatne dane mogą zostać nieumyślnie ujawnione.
- Queries mogą być bardzo złożone i mogą przeciążyć serwery web i bazy danych.
- Ta sama mutacja może być wykonana wielokrotnie w jednej query, a wiele queries może być wykonanych razem w jednym żądaniu, pozwalając atakującym na próby uzyskania dostępu do back-endu przez podawanie wielu kombinacji użytkownik/hasło.
Ataki te mogą być naprawdę szkodliwe. W swojej prezentacji Damn GraphQL - Defending and Attacking APIs, badacz cyberbezpieczeństwa Dolev Farhi zdołał obalić stronę WordPress w mniej niż 30 sekund, atakując endpoint WPGraphQL paczką złożonych queries.
Zespół WPGraphQL natychmiast naprawił problem. Ale jak możemy być pewni, że żaden inny exploit nie będzie możliwy? (Mam na myśli nie tylko WPGraphQL, ale również Gato GraphQL.)
Ataki te mogą się zdarzyć z GraphQL, a nie z REST, ponieważ GraphQL jest potężniejszy niż REST. Podczas gdy w REST query jest definiowana z góry i przechowywana na serwerze, w GraphQL jest dostarczana w czasie działania przez klienta (chyba że używa się utrwalonych queries).
Jeśli administratorzy stron będą niedbali w konfigurowaniu, kto może uzyskać dostęp do endpointu lub jakie dane są ujawniane, mogą wydarzyć się złe rzeczy. A ze względu na popularność WordPress, który jest używany przez miliony ludzi niebędących ekspertami technologicznymi, złe rzeczy najprawdopodobniej się wydarzą.
Podsumowanie
Żeby było jasne: nie opowiadam się za nieużywaniem GraphQL w WordPress (oczywiście, że nie!), ale za odpowiedzialnym korzystaniem z GraphQL. GraphQL jest potężny, co oznacza, że jest niebezpieczny. Używając GraphQL, musimy być pewni, że wiemy, co robimy.
Dostarczanie GraphQL w rdzeniu WordPress umieściłoby go w rękach wielu ludzi, z których wielu nie będzie świadomych jego ryzyk i nie podejmie odpowiednich środków ostrożności. To przepis na potencjalną katastrofę. I dlatego jest to teraz moja opinia — należy tego unikać.