UPDATE: Azóta létrehoztam ennek a projektnek egy újabb verzióját, amely a React helyett Vue-t használ. Olvass róla!

Index:
2. rész – A beállítás
3. rész – A séma

A következő hetekben egy cikksorozaton keresztül elmagyarázom, hogyan használom a Node.js-t és az Express-t a backendben egy GraphQL szerverrel, amely egy MYSQL WordPress-adatbázishoz kapcsolódik, amely az Apollót használja az adatok lehívására és a React komponensekbe való átvezetésére. Ne aggódj, továbbra is a jól bevált WordPress admin felületet fogom használni.

Ha ez szájbarágósan hangzik, az azért van, mert az is. Kihívás volt, különösen azért, mert ez az első kirándulásom a GraphQL és az Apollo területén. A dolgok változni fognak. A változás jó.

Ez a bejegyzés elmagyarázza, hogy miért.

A WordPress egy óriás. Az összes weboldal 25%-a WordPressre épül. Ez egy nagyszerű CMS, nagyszerű közösséggel és nagyszerű támogatással. A tartalom kezelése egyszerű, és ez a fő célja minden CMS-nek.

Az nclud-nál naponta fejlesztek WordPress oldalakat. A WordPress weboldalak adminisztrálása egy élvezet. A fejlesztésük nem az. Ezt Javascript-fejlesztőként mondom, aki megtapasztalta, hogy milyenek az izomorf Javascript-alkalmazások. A Javascripttől twitterpated lettem. A WordPress fejlesztés nem.

Mit mondhatnék? Nem szeretem a PHP-t. Nem szeretem a sablonokat. Nem szeretem a “hurkot”. Elkényeztetett a Node, az Express, a Webpack, a React, a Babel, és most már a Graph QL és az Apollo is.

A Javascript előnyei

Ezt tisztán a front-end fejlesztés oldaláról közelítem meg. A Node és az Express nagyszerű, de a fő mozgatórugója ennek a beállításnak számomra az ES2015 használatának lehetősége a React és a CSS-modulok segítségével.

A legnagyobb kihívás bármely tisztességes méretű weboldal vagy alkalmazás fejlesztésénél és karbantartásánál az, hogy a változásokat (új funkciók hozzáadása vagy a meglévők módosítása) kecsesen kezeljük anélkül, hogy a dolgok tönkremenne. Ez általában magában foglalja annak biztosítását, hogy a stílusok alkalmazása vagy módosítása ne járjon nem kívánt következményekkel. Ez kihívást jelent, tekintve, hogy a CSS globálisan határolt. Vannak egész CSS-módszertanok, amelyeket azért hoztak létre, hogy megkönnyítsék ezt a fájdalmat (SMACSS, BEM stb.), de ezek vagy ezoterikus elnevezési konvenciókat tartalmaznak, vagy azt követelik meg, hogy emlékezzünk millió különböző osztálynévre.

A React segítségével CSS-modulokat használhatunk a helyileg skálázott CSS létrehozására. Minden komponensnek saját stílusa van, ami a képesség, hogy CSS osztályokat állítson össze más stílusokhoz, vagy egy sor globális stílushoz. Ez nagyon erőteljes. Ez a WordPress-szel sem lehetséges.

Az inline stílusokat is elkészíthetjük, használhatjuk a JSXStyles-t vagy számtalan más megoldást – én CSS Modules-rajongó fiú vagyok, ezért ezt fogom használni.

Ez a módszer azt is jelenti, hogy a React komponensek könnyen cserélhetők a projektek között. Újrafelhasználhatóak, csatlakoztathatóak. Mivel a stílusok lokálisan egy komponenshez vannak rendelve, tetszés szerint hozzáadhatod és eltávolíthatod őket anélkül, hogy aggódnod kellene amiatt, hogy valami mást tönkreteszel.

Egy másik előnye, hogy az alkalmazás vagy a weboldal állapotát sokkal kegyesebb módon tudod kezelni. Az Apollo használatával (amire egy másik bejegyzésben térek ki) nem csak az alkalmazás adatait, hanem a felhasználói felület állapotát is kezelhetjük. A WordPressben túl sokszor látok egy nagy javascript fájlt, amely egy egész weboldal eseményeit és interakcióit kezeli. Túl sokszor látok ebben a hosszú fájlban teszteket, hogy egy elemnek van-e olyan osztálya, amely animációt vált ki. Ez fájdalmas hibakereséshez vezet, mert az alkalmazás állapota nem konzisztens.

Végre most már unit teszteket is végezhetünk. A tesztelés fontos! Huzzah testing!

A WordPress nem csinál már Node dolgokat?

Ha követted a WordPress híreket, valószínűleg hallottad, hogy az Automattic, a WordPress mögött álló cég, kifejlesztett egy Node-ra épülő admin felületet. Ez elég édes, és nyílt forráskódú lett. A WordPress REST API-t használja, így az összes WordPress-es dolgodat JSON-ban kaphatod meg, és varázsolhatsz vele.

Ez nagyon klassz.

Amikor eredetileg nekiláttam, hogy megpróbálom a PHP-t Javascript-kel helyettesíteni, az első gondolatom az volt, hogy ezt az API-t használjam. Van néhány szép beépített végpontja, és lehetőséged van sajátokat létrehozni. A V2 dokumentációja egy kicsit hiányos, de ezt csak annak tudtam be, hogy még annyira új.

Nem voltam borzasztóan elégedett az eredménnyel, bár elismerem, hogy csak egy napig játszottam vele. Emellett, mivel már használom a Reactot, akár az egész ökoszisztémát is magamévá tehetem.

Enter GraphQL

Nem lenne nagyszerű, ha az alkalmazásunk vagy weboldalunk felhasználói felülete vezérelhetné, hogy milyen adatokra van szüksége? A REST segítségével a szerver elküldi az összes adatot, amire a felhasználói felületnek szüksége lehet, majd hagyja, hogy az ügyfél kiválogassa a többit. Előfordulhat, hogy több REST végpontot is meg kell hívnia ahhoz, hogy az összes lehetséges adatot megkapja.

A GraphQL segítségével az ügyfél meghatározza a szükséges adatok összefüggéseit, és egyetlen lekérdezéssel lekérdezi az összeset. Csak egy út van. És pontosan azt kapja, amire szüksége van.

A GraphQL vs. Rest itt olvashat bővebben.

Következő lépések

A következő bejegyzésemben a Node.js/Express alapbeállítását és az alapvető GraphQL szerver beállítását fogom végigjárni. Azt is végig fogom járni, hogyan használom a Webpackot a CSS modulok kezelésére a SASS-szal, hogyan működik a forró modulcsere. Azt is, hogy a Sequelize segítségével kapcsolatot hozok létre egy WordPress MYSQL adatbázishoz, ami azt jelenti, hogy nem kell írnunk EGY SOR SQL-kérdést! Varázslat!

Eközben van egy Github repóm, ami tartalmazza, hogy jelenleg hol tartok ebben a folyamatban. Van néhány alapvető Post és Postmeta lekérdezés és néhány más ügyes dolog. Nyilvánvalóan aktív fejlesztés alatt áll, és biztos vagyok benne, hogy van benne néhány kínos hiba, úgyhogy nyugodtan piszkáld meg.