UPDATE: Od tego czasu stworzyłem nowszą wersję tego projektu, używając Vue zamiast React. Powinieneś o tym przeczytać!

Indeks:
Część 2 – Konfiguracja
Część 3 – Schemat

W kolejnych tygodniach, poprzez serię artykułów, wyjaśnię, jak używam Node.js i Express na backendzie z serwerem GraphQL podłączonym do bazy danych MYSQL WordPress, która używa Apollo do pobierania danych i przesyłania ich do komponentów React. Nie martw się, nadal będę używał wypróbowanego i prawdziwego interfejsu administracyjnego WordPressa.

Jeśli to brzmi jak usta, to dlatego, że tak jest. To było wyzwanie, zwłaszcza, że jest to moje pierwsze podejście do GraphQL i Apollo. Wszystko się zmieni. Zmiana jest dobra.

Ten post wyjaśni dlaczego.

WordPress jest gigantem. 25% wszystkich stron internetowych jest zbudowanych na WordPressie. Jest to świetny CMS, z wielką społecznością i wielkim wsparciem. Zarządzanie treścią jest łatwe, a to jest główny cel każdego systemu CMS.

W nclud codziennie tworzę strony WordPress. Administrowanie stronami WordPress jest przyjemnością. Rozwijanie ich nie jest. Mówię to jako programista Javascript, który doświadczył tego, jak wyglądają i czują się izomorficzne aplikacje Javascript. Javascript sprawił, że stałem się twitterpated. Rozwój WordPressa nie.

Co mogę powiedzieć? Nie lubię PHP. Nie lubię szablonów. Nie lubię „pętli”. Zostałem rozpieszczony przez Node, Express, Webpack, React, Babel, a teraz Graph QL i Apollo.

Korzyści z Javascript

Podchodzę do tego czysto od strony front-end developmentu. Node i Express są świetne, ale główną siłą napędową tej konfiguracji jest dla mnie możliwość korzystania z ES2015 z React i CSS-Modules.

Największym wyzwaniem przy tworzeniu i utrzymaniu każdej przyzwoitej wielkości strony internetowej lub aplikacji jest zdolność do obsługi zmian (dodawanie nowych funkcji lub modyfikowanie istniejących) bez łamania rzeczy. Zazwyczaj wiąże się to z upewnieniem się, że zastosowanie lub modyfikacja stylów nie ma żadnych niezamierzonych konsekwencji. Jest to wyzwanie biorąc pod uwagę, że CSS jest globalnie skalowalny. Istnieją całe metodologie CSS, które zostały stworzone aby złagodzić ten ból (SMACSS, BEM, itp.), ale albo wiążą się one z ezoterycznymi konwencjami nazewniczymi, albo wymagają zapamiętania miliona różnych nazw klas.

W React, możemy użyć Modułów CSS do stworzenia lokalnie skalowalnego CSS. Każdy komponent ma swoją własną stylizację, co daje możliwość komponowania klas CSS dla innych stylów, lub zestawu stylów globalnych. Jest to bardzo potężne. Nie jest to również możliwe w WordPress.

Możesz również zrobić style inline, użyć JSXStyles lub niezliczonych innych rozwiązań – jestem fan boyem CSS Modules, więc to jest to, czego będę używał.

Ta metoda oznacza również, że komponenty React są łatwo przełączane między projektami. Są wielokrotnego użytku, można je podłączać. Ponieważ style są lokalnie przypisane do komponentu, możesz dodawać i usuwać je do woli, nie martwiąc się o zepsucie czegoś innego.

Inną korzyścią jest możliwość obsługi stanu aplikacji lub strony internetowej w znacznie bardziej wdzięczny sposób. Używając Apollo (do którego przejdę w innym poście) możemy zarządzać nie tylko danymi aplikacji, ale także stanem UI. Zbyt wiele razy w WordPressie widzę jeden duży plik javascript, który obsługuje zdarzenia i interakcje dla całej strony. Zbyt wiele razy widzę w tym długim pliku testy sprawdzające, czy dany element ma klasę, która powinna wywołać animację. Prowadzi to do bolesnego debugowania, ponieważ stan aplikacji nie jest spójny.

Na koniec dodam, że teraz możemy również wykonywać testy jednostkowe. Testowanie jest ważne! Huzzah testing!

Isn’t WordPress Already doing Node Stuff?

Jeśli śledzisz wiadomości o WordPressie, prawdopodobnie słyszałeś, że Automattic, firma stojąca za WordPressem, opracowała interfejs administratora zbudowany na Node. Jego całkiem słodkie, i to było open sourced. Jest on zasilany przez WordPress REST API, więc możesz uzyskać wszystkie swoje rzeczy związane z WordPressem w JSON i robić z nimi magię.

To całkiem zgrabne.

Gdy pierwotnie postanowiłem spróbować zastąpić PHP przez Javascript, moją pierwszą myślą było użycie tego API. Ma kilka ładnych wbudowanych punktów końcowych, a ty masz możliwość tworzenia własnych. Dokumentacja V2 jest trochę wybrakowana, ale ja po prostu uważam, że to jest tak nowe.

Nie byłem strasznie zadowolony z rezultatu, choć przyznam, że bawiłem się tym tylko przez dzień lub tak. Poza tym, skoro już używam Reacta, to równie dobrze mogę ogarnąć cały ekosystem.

Enter GraphQL

Czy nie byłoby świetnie, gdyby interfejs naszej aplikacji lub strony internetowej mógł sam sterować tym, jakich danych potrzebuje? W przypadku REST, serwer wysyła wszystkie dane, których może potrzebować interfejs użytkownika, a następnie pozwala klientowi posortować resztę. Być może trzeba będzie wykonać wiele połączeń do wielu punktów końcowych REST, aby uzyskać wszystkie możliwe dane.

W przypadku GraphQL klient określa relacje danych, których potrzebuje i wykonuje jedno zapytanie, aby pobrać je wszystkie. To jest tylko jedna podróż. I dostajesz dokładnie to, czego potrzebujesz.

W każdym razie, możesz przeczytać więcej o GraphQL vs. Rest tutaj.

Następne kroki

W moim następnym poście, przejdę przez podstawową konfigurację Node.js/Express i jak skonfigurować podstawowy serwer GraphQL. Przejdę również przez to jak używam Webpacka do obsługi modułów CSS z SASS, jak działa hot module replacement. Będę także używał Sequelize do tworzenia połączenia z bazą danych WordPress MYSQL, co oznacza, że nie będziemy musieli pisać JEDNEJ LINII zapytań SQL! Wizardry!

W międzyczasie, mam repo na Githubie, które zawiera miejsce, w którym obecnie jestem w tym procesie. Ma kilka podstawowych zapytań Post i Postmeta oraz kilka innych zgrabnych rzeczy. Jest to oczywiście w trakcie aktywnego rozwoju i jestem pewien, że są tam jakieś żenujące błędy, więc nie krępuj się, aby się z nich nabijać.