UPDATE: Ik heb sindsdien een nieuwere versie van dit project gemaakt waarbij ik Vue gebruik in plaats van React. Lees er meer over!

Index:
Deel 2 – De setup
Deel 3 – Het schema

In de komende weken zal ik in een reeks artikelen uitleggen hoe ik Node.js en Express gebruik aan de achterkant met een GraphQL-server die is gekoppeld aan een MYSQL WordPress-database die Apollo gebruikt om gegevens op te halen en deze naar React-componenten te leiden. Maak je geen zorgen, ik gebruik nog steeds de beproefde WordPress admin interface.

Als dat klinkt als een mond vol, dan komt dat omdat het dat ook is. Het is een uitdaging geweest, vooral omdat dit mijn eerste uitstapje is naar GraphQL en Apollo. Dingen zullen veranderen. Verandering is goed.

Deze post zal uitleggen waarom.

WordPress is een reus. 25% van alle websites zijn gebouwd op WordPress. Het is een geweldig CMS, met een geweldige community, en geweldige ondersteuning. Het beheren van content is eenvoudig en dat is het belangrijkste doel van elk CMS.

Bij nclud ontwikkel ik dagelijks WordPress sites. Het beheren van WordPress websites is een traktatie. Ze ontwikkelen is dat niet. Ik zeg dit als een Javascript ontwikkelaar die heeft ervaren hoe isomorphic Javascript applicaties eruit zien en voelen. Javascript heeft me getwitterd. WordPress ontwikkeling niet.

Wat kan ik zeggen? Ik hou niet van PHP. Ik hou niet van sjablonen. Ik hou niet van “de lus”. Ik ben verwend geraakt door Node, Express, Webpack, React, Babel, en nu Graph QL en Apollo.

De voordelen van Javascript

Ik bekijk dit puur vanuit de kant van front-end ontwikkeling. Node en Express zijn geweldig, maar de belangrijkste drijfveer achter deze setup, voor mij, is de mogelijkheid om ES2015 te gebruiken met React en CSS-Modules.

De grootste uitdaging van het ontwikkelen en onderhouden van elke redelijk grote website of applicatie is de mogelijkheid om veranderingen (het toevoegen van nieuwe functies of het wijzigen van bestaande) netjes af te handelen zonder dingen te breken. Dit houdt meestal in dat je ervoor moet zorgen dat het toepassen of wijzigen van stijlen geen onbedoelde gevolgen heeft. Dit is een uitdaging aangezien CSS globally scoped is. Er zijn hele CSS methodologieën die zijn gemaakt om deze pijn te verzachten (SMACSS, BEM, etc.), maar ze hebben ofwel esoterische naamgeving conventies nodig, of vereisen dat je een ziljoen verschillende class namen onthoudt.

Met React, kunnen we CSS Modules gebruiken om lokaal scoped CSS te maken. Elke component heeft zijn eigen styling, die de mogelijkheid om CSS klassen samen te stellen voor andere stijlen, of een set van globale stijlen. Het is zeer krachtig. Het is ook niet mogelijk met WordPress.

Je kunt ook inline stijlen doen, JSXStyles gebruiken of talloze andere oplossingen – ik ben een fan van CSS Modules, dus dat is wat ik zal gebruiken.

Deze methode betekent ook dat React-componenten gemakkelijk tussen projecten kunnen worden uitgewisseld. Ze zijn herbruikbaar, pluggable. Omdat stijlen lokaal zijn toegewezen aan een component, kun je ze naar believen toevoegen en verwijderen zonder je zorgen te hoeven maken dat je iets anders kapot maakt.

Een ander voordeel is de mogelijkheid om applicatie- of websitestatus op een veel sierlijkere manier af te handelen. Met behulp van Apollo (waar ik in een andere post op in zal gaan) kunnen we niet alleen applicatie data beheren, maar ook de UI status. Te vaak zie ik in WordPress één groot javascript bestand dat events en interacties afhandelt voor een hele website. Te vaak zie ik in dat lange bestand tests om te zien of een element een klasse heeft die een animatie zou moeten triggeren. Dit leidt tot pijnlijk debuggen omdat de applicatiestatus niet consistent is.

Ten slotte kunnen we nu ook unit tests uitvoeren. Testen is belangrijk! Huzzah testen!

Doet WordPress al niet aan Node?

Als je het nieuws over WordPress hebt gevolgd, heb je waarschijnlijk gehoord dat Automattic, het bedrijf achter WordPress, een beheerinterface heeft ontwikkeld die is gebaseerd op Node. Het is erg mooi, en het is open source. Het wordt aangedreven door de WordPress REST API, dus je kunt al je WordPress-y dingen in JSON krijgen en er magie mee doen.

Dat is best netjes.

Toen ik oorspronkelijk PHP probeerde te vervangen door Javascript, was mijn eerste gedachte om deze API te gebruiken. Het heeft een aantal mooie ingebouwde eindpunten, en je hebt de mogelijkheid om je eigen te maken. De V2 documentatie is een beetje gebrekkig, maar dat komt omdat het zo nieuw is.

Ik was niet erg blij met het resultaat, hoewel ik moet toegeven dat ik er maar een dag of zo mee gespeeld heb. En omdat ik toch al React gebruik, kan ik net zo goed het hele ecosysteem omarmen.

Enter GraphQL

Zou het niet geweldig zijn als de UI van onze applicatie of website zou kunnen bepalen welke gegevens het nodig heeft? Met REST stuurt de server alle gegevens die de UI nodig heeft en laat de client de rest uitzoeken. Het kan zijn dat je meerdere REST endpoints moet aanroepen om al die mogelijke gegevens te krijgen.

Met GraphQL bepaalt de client de relaties van de gegevens die hij nodig heeft en doet hij één query om alles op te halen. Er is maar één reis. En je krijgt precies wat je nodig hebt.

Hoe dan ook, je kunt hier meer lezen over GraphQL vs Rest.

Volgende stappen

In mijn volgende post loop ik door de basis Node.js/Express setup en hoe ik de basis GraphQL server kan opzetten. Ik zal ook doornemen hoe ik Webpack gebruik om CSS modules af te handelen met SASS, hoe hot module replacement werkt. Ik zal ook Sequelize gebruiken om een verbinding te maken met een WordPress MYSQL database, wat betekent dat we geen ENKELE REGEL SQL vragen hoeven te schrijven! Tovenarij!

In de tussentijd heb ik een Github repo die bevat waar ik op dit moment ben in dit proces. Het bevat een aantal basis Post- en Postmeta-query’s en wat andere leuke dingen. Het is duidelijk nog in ontwikkeling, en ik ben er zeker van dat er nog wat gênante fouten in zitten, dus voel je vrij om er de draak mee te steken.