MISE À JOUR : J’ai depuis créé une version plus récente de ce projet en utilisant Vue au lieu de React. Vous devriez le lire !

Index:
Partie 2 – La configuration
Partie 3 – Le schéma

Dans les semaines à venir, à travers une série d’articles, j’expliquerai comment j’utilise Node.js et Express sur le backend avec un serveur GraphQL relié à une base de données MYSQL WordPress qui utilise Apollo pour récupérer les données et les canaliser dans les composants React. Ne vous inquiétez pas, je vais continuer à utiliser l’interface d’administration éprouvée de WordPress.

Si cela ressemble à une bouche, c’est parce que c’est le cas. Cela a été un défi, surtout parce que c’est ma première incursion dans GraphQL et Apollo. Les choses vont changer. Le changement est une bonne chose.

Ce post va expliquer pourquoi.

WordPress est un géant. 25% de tous les sites web sont construits sur WordPress. C’est un excellent CMS, avec une grande communauté, et un grand soutien. La gestion du contenu est facile et c’est l’objectif principal de tout CMS.

À nclud, je développe quotidiennement des sites WordPress. Administrer des sites WordPress est un plaisir. Les développer ne l’est pas. Je dis cela en tant que développeur Javascript qui a expérimenté ce à quoi ressemblent les applications Javascript isomorphes. Javascript m’a rendu twitterpated. Le développement de WordPress ne le fait pas.

Que puis-je dire ? Je n’aime pas le PHP. Je n’aime pas les templates. Je n’aime pas « la boucle ». Je suis devenu gâté par Node, Express, Webpack, React, Babel, et maintenant Graph QL et Apollo.

Les avantages de Javascript

J’arrive à cela purement du côté du développement frontal. Node et Express sont géniaux, mais la principale force motrice derrière cette configuration, pour moi, est la possibilité d’utiliser ES2015 avec React et CSS-Modules.

Le plus grand défi du développement et de la maintenance de tout site Web ou application de taille décente est la capacité de gérer gracieusement les changements (ajout de nouvelles fonctionnalités ou modification des fonctionnalités existantes) sans casser les choses. Cela implique généralement de s’assurer que l’application ou la modification des styles n’a pas de conséquences involontaires. Il s’agit d’un défi, car les feuilles de style CSS ont une portée mondiale. Il existe des méthodologies CSS entières qui ont été créées pour faciliter cette douleur (SMACSS, BEM, etc.) mais celles-ci impliquent soit des conventions de nommage ésotériques, soit vous obligent à vous souvenir d’un zillion de noms de classes différents.

Avec React, nous pouvons utiliser des modules CSS pour créer du CSS à portée locale. Chaque composant a son propre style, qui la capacité de composer des classes CSS pour d’autres styles, ou un ensemble de styles globaux. C’est très puissant. Ce n’est pas non plus possible avec WordPress.

Vous pouvez également faire des styles en ligne, utiliser JSXStyles ou une myriade d’autres solutions – je suis un fan des modules CSS, c’est donc ce que j’utiliserai.

Cette méthode signifie également que les composants React sont facilement interchangeables entre les projets. Ils sont réutilisables, pluggables. Parce que les styles sont localement scopés à un composant, vous pouvez les ajouter et les supprimer à volonté sans avoir à vous soucier de casser quelque chose d’autre.

Un autre avantage est la capacité de gérer l’état de l’application ou du site Web d’une manière beaucoup plus gracieuse. En utilisant Apollo (dont je parlerai dans un autre article), nous pouvons gérer non seulement les données de l’application, mais aussi l’état de l’interface utilisateur. Trop souvent, dans WordPress, je vois un grand fichier javascript qui gère les événements et les interactions de tout un site web. Trop souvent, je vois dans ce long fichier des tests pour voir si un élément a une classe qui devrait déclencher une animation. Cela conduit à un débogage douloureux parce que l’état de l’application n’est pas cohérent.

Enfin, nous pouvons aussi maintenant effectuer des tests unitaires. Les tests sont importants ! Huzzah testing!

Isn’est pas WordPress qui fait déjà des trucs Node ?

Si vous avez suivi les nouvelles de WordPress, vous avez probablement entendu dire qu’Automattic, la société derrière WordPress, a développé une interface d’administration construite sur Node. C’est assez doux, et il a été open sourced. Elle est alimentée par l’API REST de WordPress, de sorte que vous pouvez obtenir tous vos trucs WordPress-y en JSON et faire de la magie avec elle.

C’est assez chouette.

Lorsque j’ai commencé à essayer de remplacer PHP par Javascript, ma première pensée a été d’utiliser cette API. Il a quelques points de terminaison bien construits, et vous avez la possibilité de créer les vôtres. La documentation de la V2 fait un peu défaut, mais je mets cela sur le compte du fait que c’est si nouveau.

Je n’étais pas terriblement satisfait du résultat, même si je dois admettre que j’ai seulement joué avec pendant un jour ou deux. En outre, puisque j’utilise déjà React, autant embrasser l’ensemble de l’écosystème.

Entrez GraphQL

Ne serait-il pas formidable si l’interface utilisateur de notre application ou de notre site Web pouvait piloter les données dont elle a besoin ? Avec REST, le serveur envoie toutes les données dont l’IU pourrait avoir besoin, puis laisse le client trier le reste. Vous pourriez avoir besoin de faire des appels à plusieurs points de terminaison REST pour obtenir toutes ces données possibles.

Avec GraphQL, le client détermine les relations des données dont il a besoin et fait une seule requête pour tout récupérer. Il n’y a qu’un seul voyage. Et vous obtenez exactement ce dont vous avez besoin.

En tout cas, vous pouvez en savoir plus sur GraphQL vs Rest ici.

Prochaines étapes

Dans mon prochain billet, je vais parcourir la configuration de base de Node.js/Express et comment configurer le serveur GraphQL de base. Je vais également expliquer comment j’utilise Webpack pour gérer les modules CSS avec SASS, comment fonctionne le remplacement des modules à chaud. Je vais également utiliser Sequelize pour créer une connexion à une base de données MYSQL de WordPress, ce qui signifie que nous n’aurons pas à écrire UNE SEULE LIGNE DE QUESTIONS SQL ! Magie !

En attendant, j’ai un repo Github qui contient où j’en suis actuellement dans ce processus. Il y a quelques requêtes de base sur Post et Postmeta et d’autres trucs intéressants. Il est évidemment en développement actif, et je suis sûr qu’il y a quelques erreurs embarrassantes là-dedans, alors n’hésitez pas à vous moquer.