UPPDATERING: Jag har sedan dess skapat en nyare version av det här projektet som använder Vue istället för React. Du borde läsa om det!

Index:
Del 2 – Inställningen
Del 3 – Schemat

Under de kommande veckorna kommer jag genom en serie artiklar att förklara hur jag använder Node.js och Express på baksidan med en GraphQL-server kopplad till en MYSQL WordPress-databas som använder Apollo för att hämta data och leda in dem i React-komponenter. Oroa dig inte, jag kommer fortfarande att använda det beprövade och pålitliga WordPress-administrationsgränssnittet.

Om det låter som en munfull är det för att det är det. Det har varit en utmaning, särskilt eftersom detta är mitt första försök med GraphQL och Apollo. Saker och ting kommer att förändras. Förändring är bra.

Detta inlägg kommer att förklara varför.

WordPress är en jätte. 25 % av alla webbplatser är byggda på WordPress. Det är ett fantastiskt CMS, med en fantastisk gemenskap och ett fantastiskt stöd. Det är enkelt att hantera innehåll och det är huvudmålet med alla CMS.

På nclud utvecklar jag dagligen WordPress-webbplatser. Att administrera WordPress-webbplatser är ett nöje. Att utveckla dem är det inte. Jag säger detta som en Javascript-utvecklare som har upplevt hur isomorfa Javascript-applikationer ser ut och känns. Javascript fick mig att bli twitterpated. WordPress-utveckling gör det inte.

Vad kan jag säga? Jag gillar inte PHP. Jag gillar inte mallar. Jag gillar inte ”the loop”. Jag har blivit bortskämd av Node, Express, Webpack, React, Babel och nu Graph QL och Apollo.

Fördelarna med Javascript

Jag ser det här enbart från frontend-utvecklingssidan. Node och Express är fantastiska, men den främsta drivkraften bakom den här inställningen är för mig möjligheten att använda ES2015 med React och CSS-moduler.

Den största utmaningen när det gäller att utveckla och underhålla en anständigt stor webbplats eller applikation är förmågan att på ett elegant sätt hantera förändringar (lägga till nya funktioner eller modifiera befintliga) utan att förstöra saker. Detta innebär vanligtvis att se till att tillämpningen eller ändringen av stilar inte får några oavsiktliga konsekvenser. Detta är en utmaning med tanke på att CSS har en global räckvidd. Det finns hela CSS-metodologier som skapats för att underlätta detta (SMACSS, BEM, etc.) men de involverar antingen esoteriska namnkonventioner eller kräver att du kommer ihåg en zillion olika klassnamn.

Med React kan vi använda CSS Modules för att skapa lokalt scoped CSS. Varje komponent har sin egen styling, som möjligheten att komponera CSS-klasser för andra stilar, eller en uppsättning globala stilar. Det är väldigt kraftfullt. Det är inte heller möjligt med WordPress.

Du kan också göra inline-stilar, använda JSXStyles eller otaliga andra lösningar – jag är en CSS Modules-fanpojke så det är det jag kommer att använda.

Denna metod innebär också att React-komponenterna lätt kan bytas ut mellan olika projekt. De är återanvändbara, pluggbara. Eftersom stilar är lokalt scoped till en komponent kan du lägga till och ta bort dem när du vill utan att behöva oroa dig för att bryta något annat.

En annan fördel är möjligheten att hantera program- eller webbplatstillstånd på ett mycket mer graciöst sätt. Med hjälp av Apollo (som jag kommer att gå in på i ett annat inlägg) kan vi hantera inte bara programdata utan även UI-status. Alltför ofta i WordPress ser jag en stor javascriptfil som hanterar händelser och interaktioner för en hel webbplats. Alltför många gånger ser jag i den långa filen tester för att se om ett element har en klass som ska utlösa en animation. Detta leder till smärtsam felsökning eftersom applikationstillståndet inte är konsekvent.

Sist kan vi nu också utföra enhetstester. Testning är viktigt! Huzzah testing!

Är det inte WordPress som redan gör Node-grejer?

Om du följt WordPress-nyheterna har du antagligen hört att Automattic, företaget bakom WordPress, har utvecklat ett administratörsgränssnitt byggt på Node. Det är ganska snyggt, och det har fått en öppen källkod. Det drivs av WordPress REST API, så du kan få alla dina WordPress-grejer i JSON och göra magi med dem.

Det är ganska snyggt.

När jag ursprungligen började försöka ersätta PHP med Javascript, var min första tanke att använda detta API. Det har några trevliga inbyggda ändpunkter, och du har möjlighet att skapa egna. V2-dokumentationen är lite bristfällig, men det beror på att det är så nytt.

Jag var inte särskilt nöjd med resultatet, även om jag medger att jag bara lekte med det i en dag eller så. Eftersom jag redan använder React kan jag lika gärna ta till mig hela ekosystemet.

Enter GraphQL

Vore det inte fantastiskt om vår applikations eller webbplats användargränssnitt kunde styra vilka data den behöver? Med REST skickar servern alla data som användargränssnittet kan behöva och låter sedan klienten sortera resten. Du kan behöva göra anrop till flera REST-slutpunkter för att få all möjlig data.

Med GraphQL bestämmer klienten vilka datarelationer den behöver och gör en förfrågan för att hämta allt. Det finns bara en resa. Och du får exakt det du behöver.

Hur som helst kan du läsa mer om GraphQL vs. Rest här.

Nästa steg

I mitt nästa inlägg kommer jag att gå igenom den grundläggande Node.js/Express-installationen och hur man installerar den grundläggande GraphQL-servern. Jag kommer också att gå igenom hur jag använder Webpack för att hantera CSS-moduler med SASS, hur hot module replacement fungerar. Jag kommer också att använda Sequelize för att skapa en anslutning till en WordPress MYSQL-databas, vilket innebär att vi inte kommer att behöva skriva en enda rad med SQL-frågor! Wizardry!

Under tiden har jag en Github repo som innehåller var jag för närvarande befinner mig i denna process. Den innehåller några grundläggande Post- och Postmeta-frågor och en del andra snygga saker. Den är uppenbarligen under aktiv utveckling, och jag är säker på att det finns några pinsamma misstag där, så du får gärna göra dig lustig.