DE{CODE} : Headless 101 pour les développeurs WordPress

Le développement sans tête peut être plus puissant et encore plus amusant que le développement WordPress traditionnel. Cependant, avec tant de nouveaux choix dans cette pile émergente, quelle est la meilleure façon de commencer ? Cet atelier guidera les constructeurs tout au long de l'installation et de l'optimisation d'un projet WordPress pour le headless, jusqu'à la modélisation de votre première page dans une interface découplée.

Diapositives de la session

Transcription du texte intégral

GRACE ERIXON : Bienvenue dans Headless 101 pour les développeurs WordPress. Je m'appelle Grace Erixon et je suis une avocate associée des développeurs ici chez WP Engine. Je suis accompagné de Steve de Haus. Aujourd'hui, nous allons vous donner une introduction rapide à ce qu'est WordPress sans tête et comment vous pouvez commencer à l'utiliser.

Donc, afin de comprendre ce qu'est une architecture de site Web WordPress sans tête, il est important de s'assurer que nous sommes tous sur la même longueur d'onde sur ce à quoi ressemble une architecture WordPress traditionnelle. Traditionnellement, un CMS tel que WordPress gère à la fois le front-end et le back-end d'un site Web.

Dans une architecture traditionnelle, l'éditeur crée et gère du contenu tel que des articles de blog et des pages à l'intérieur de WordPress. Le développeur écrit du code pour contrôler l'apparence et le fonctionnement du site à l'aide de PHP et de l'API de thème de WordPress. WordPress génère ensuite la page HTML qui est envoyée au visiteur.

Dans cette architecture CMS couplée, WordPress fournit les capacités de gestion de contenu aux éditeurs. Et il est également chargé de servir les pages HTML aux visiteurs du site Web. Un CMS sans tête utilise une architecture découplée où le front-end et le back-end sont gérés séparément. Dans une architecture headless, l'éditeur crée et gère toujours le contenu dans WordPress, comme dans une architecture WordPress traditionnelle.

Le développeur écrit du code pour contrôler l'apparence et le fonctionnement du site en JavaScript, ainsi que l'utilisation de WPGraphQL ou de l'API REST pour extraire les données de WordPress. Un framework tel que Faust.js, Next.js, Nuxt.js ou SvelteKit est souvent utilisé pour alimenter cette application frontale. Ensuite, l'application JavaScript frontale génère et sert les pages HTML qui sont envoyées au visiteur du site Web.

Contrairement à une architecture traditionnelle, WordPress n'est plus responsable de la génération des pages HTML. Ainsi, l'interaction pour échanger du contenu entre le back-end WordPress et l'application JavaScript frontale se fait via la couche API. Les deux options pour la couche API sont l'API WordPress REST ou WPGraphQL.

L'API REST est fournie avec WordPress. Cependant, le modèle d'accès aux données requis peut être lent car REST exige que chaque ressource ait son propre point de terminaison. Par exemple, il faudrait plusieurs allers-retours pour reconstruire un poteau entièrement modélisé. Si vous vouliez obtenir le contenu, l'auteur et la catégorie d'un article, cela nécessiterait trois appels d'API distincts.

En revanche, WPGraphQL nous permet de demander le contenu, l'auteur et la catégorie d'un article en une seule requête. Pour cette raison, WPGraphQL est notre couche API préférée. WPGraphQL est un plugin gratuit qui fournit un schéma et une API GraphQL extensibles pour votre site WordPress. WPGraphQL est plus rapide que l'API REST car il obtient les données exactes demandées et entraîne moins de fonctions exécutées grâce à l'optimisation des requêtes, moins de téléchargement de données, un chargement de données plus efficace et plusieurs ressources incluses dans une seule requête.

Une architecture sans tête donne aux développeurs la liberté de choisir parmi n'importe quelle pile technologique frontale, les frameworks JavaScript étant les plus populaires. Certains des frameworks JavaScript frontaux les plus populaires incluent React, Vue.js et Svelte. De nouveaux frameworks sont publiés tout le temps, donc cette liste est loin d'être exhaustive.

Beaucoup de ces frameworks JavaScript sont utilisés conjointement avec des méta-frameworks qui ajoutent des solutions pour des choses comme le routage, le rendu côté serveur, etc. React est utilisé conjointement avec Next.js, Vue.js est utilisé conjointement avec Nuxt.js et Svelte est utilisé conjointement avec SvelteKit. Gatsby est un autre méta-framework populaire.

WP Engine a développé Faust.js, un framework JavaScript construit sur React et Next.js. Faust a été créé spécifiquement pour prendre en charge les applications Web WordPress sans tête. Il prend en charge l'authentification et publie des aperçus prêts à l'emploi, fournit des crochets React intégrés pratiques pour accéder aux données WordPress, et plus encore.

Nous avons donc parlé de ce que signifie une architecture WordPress sans tête et des types de technologie que vous utiliseriez. Mais abordons rapidement pourquoi vous choisiriez même sans tête. WordPress lui-même est un CMS lourd, et il utilise PHP, qui n'est pas un langage rapide. Headless WordPress utilise des langages d'accueil via JavaScript et charge uniquement les fichiers nécessaires via des appels d'API. Il est beaucoup plus léger, donc votre site se chargera plus rapidement.

Headless WordPress minimise également le risque pour votre contenu puisque vos données sont séparées de votre livraison frontale. Il est moins exposé aux attaques Web. Et le principal avantage est que l'architecture WordPress sans tête permet aux éditeurs de continuer à bénéficier de la grande expérience de publication offerte par WordPress tout en permettant aux développeurs et aux visiteurs du site Web de profiter des capacités techniques que les applications JavaScript modernes apportent à la table.

Maintenant, creusons dans le code d'un vrai site sans tête. J'ai pré-enregistré une présentation du nouveau site WordPress sans tête Atlas Blueprints. La nouvelle fonctionnalité Blueprints d'Atlas offre un moyen très simple de mettre en place un site WordPress complet sans tête. Ils sont livrés avec un code de démarrage, des plugins, des modèles de contenu et une structure de page pour faire démarrer votre application plus rapidement.

Créons donc un nouveau site Blueprint afin de pouvoir plonger dans le code. De l'intérieur du tableau de bord de WP Engine, nous irons à Atlas. Cliquez sur Créer une application. Sélectionnez Démarrer avec Blueprint. Et puis nous allons sélectionner le plan que nous voulons utiliser. Je vais choisir le plan du portefeuille.

Ensuite, vous connecterez votre compte WP Engine à votre compte GitHub et clonerez ce plan dans un nouveau référentiel. Cela prendra quelques secondes à construire. Enfin, vous sélectionnerez simplement le nom du référentiel que vous venez de créer, la région la plus proche de vous, puis vous cliquerez sur Créer une application.

Maintenant, si vous cliquez sur l'URL de l'Atlas, nous pouvons voir à quoi ressemble notre site WordPress sans tête. Nous sommes particulièrement intéressés par la page Messages. Comme vous pouvez le constater, le site rassemble tous les articles les plus récents sur cette page Notre blog. Et chaque message a également sa propre page de vue individuelle. Mais d'où viennent toutes ces données ?

Si nous revenons au tableau de bord de WP Engine, nous verrons un bouton pour WP Admin. Il y a le back-end pour notre site WordPress sans tête. Si je clique sur Messages, vous verrez la même liste que celle que l'application Web a récupérée. Maintenant, nous pouvons ouvrir le référentiel GitHub dans lequel notre Blueprint a été cloné. Et clonons ce dépôt dans notre environnement local.

Ensuite, je vais ouvrir ce référentiel dans Visual Studio Code, mon éditeur de code préféré. En explorant le répertoire du projet, le fichier de la page de blog se trouve dans SRC, pages, posts, Index.js. Ce projet est construit à l'aide de React, Next.js, Faust.js et WPGraphQL. Si vous n'êtes pas familier avec React ou même JavaScript, cela peut sembler déroutant au début.

Dans la première section, le fichier importe simplement les éléments dont il a besoin à partir de sources internes et externes. La deuxième section qui définit les champs de prépasse des nœuds post est celle où chaque élément de données dont nous avons besoin est répertorié. L'exécution de ce prépasse garantit que les données sont là quand nous en avons besoin et qu'aucune demande en cascade ne se produit.

Ensuite, nous avons la fonction de page. Au début, il s'agit simplement de collecter les données dont nous avons besoin dans quelques variables différentes, à savoir les paramètres généraux et une liste paginée de publications. Les balises à l'intérieur de l'instruction de retour sont le code qui sera rendu visuellement sur la page Web. Tout d'abord, nous avons le composant pour l'en-tête. Ensuite, à l'intérieur de ce composant principal, nous avons un composant d'en-tête d'entrée, et c'est ce qui affiche le gros titre qui dit Derniers messages en haut de la page.

Enfin, nous arrivons au composant post, qui accepte la liste paginée des publications en tant que paramètre. Regardons ce que fait le composant post avec ces informations. Ici, il parcourt chaque message contenu dans la liste des messages qu'il a reçus. Pour chaque message, il affiche la vue en forme de carte sur la page du dernier message. Ce premier consiste en un composant d'image en vedette enveloppé dans un lien vers la page de l'article de blog individuel, un en-tête du titre de l'article et un composant d'informations sur l'article comprenant la date et l'auteur de l'article.

De retour au fichier Index.js qui affiche tous les messages, nous terminons cela en affichant le composant Charger plus en bas de la page pour récupérer plus de messages si demandé et un pied de page. La dernière fonction, getStaticProps, est une fonction de génération de site statique Next.js qui lui indique de pré-rendre cette page au moment de la génération à l'aide des accessoires renvoyés par la fonction. Et c'est tout.

Merci à Blueprints d'avoir géré la configuration Headless pour nous. Il était simple de décomposer ce qui se passe dans la page de publication pour obtenir des données du backend WordPress à l'aide de WPGraphQL et pour afficher les publications à l'aide de composants React. Merci de vous être connecté. Vous pouvez me trouver sur Twitter @graceerixon.

Consultez developers.wpengine.com pour plus de contenu sur Headless WordPress. Nous avons un tutoriel sur la façon de créer votre premier site WordPress Headless à partir de zéro en utilisant Faust.js, et nous travaillons actuellement sur une série de contenu Headless 101. Vous pouvez obtenir tous les outils proposés par Atlas si vous vous inscrivez pour un compte Sandbox gratuit. Je vais maintenant passer la parole à Steve pour en savoir plus sur les raisons pour lesquelles Haus a choisi Headless WordPress pour son projet leoburnett.com.

STEVE SCAVO : Merci, Grâce. Bonjour, je suis Steve Scavo, CTO chez Haus. Nous sommes un studio et une agence de technologie créative basés à Los Angeles, en Californie. Cette conférence s'intitule à juste titre Headless 101 pour les développeurs WordPress. Et franchement, je ne suis pas un développeur WordPress de métier, mais je pense que cela fait partie de la beauté d'une architecture sans tête.

Nous aurions donc pu facilement appeler ce Headless 101 pour les développeurs non-WordPress qui ont besoin de tirer parti de WordPress. Cela aurait pu être un titre tout aussi approprié. C'est ce qu'il y a de beau sans tête. C'est un gagnant-gagnant de tous les côtés, comme vous le verrez.

Alors pourquoi sans tête ? Il y a tellement de raisons de haut niveau dont nous pourrions parler, mais je pense que ce genre de parler d'exemples de production réels et d'exemples du monde réel de quand ça brille est vraiment utile. Et j'aimerais présenter un projet que nous avons réalisé pour Leo Burnett en utilisant une architecture sans tête sous une architecture sans tête. Pour le contexte, Leo Burnett est une agence de publicité légendaire de Chicago, mais ils ont de nombreux bureaux dans le monde et dans le monde. Ils ont donc beaucoup de contenu, beaucoup de travail.

L'ancien site fonctionnait sur un seul thème WordPress. C'était vraiment fragmenté, un peu lent, ça ne fonctionnait pas bien. Il était difficile à mettre à jour et ne présentait pas tout à fait le genre de cachet et l'image de marque que Leo Burnett voulait transmettre. C'est donc avec cela que nous sommes allés travailler du point de vue de la conception. Et nous avons choisi le headless pour vraiment moderniser leur stack.

Nous voulions juste qu'il se sente vivant et frais et qu'il ait ce genre de capacité dont nous avons besoin pour vraiment mettre en place une expérience utilisateur et une interface utilisateur merveilleuses. Nous voulions augmenter leur puissance éditoriale. Nous voulions augmenter la cadence à laquelle ils peuvent publier du contenu. Nous voulions rétablir l'identité de la marque et avoir une interface utilisateur et une interaction, la sensation sur le site Web qui dégageait vraiment Leo Burnett et toutes ces petites touches et sortes de points éditoriaux, typographiques et d'interaction qu'ils voulaient transmettre.

Et nous voulions préparer la base de code et le site Web pour l'avenir. Nous ne voulions pas seulement que le site soit pertinent pour les 12 prochains mois. Nous voulons qu'il soit pertinent pour la prochaine décennie, peut-être. Et je pense que cette architecture sans tête, cette pile sans tête fait vraiment ça.

Donc, l'un des problèmes initiaux avec headless est qu'il y a toujours beaucoup de décisions concernant l'hébergement, le déploiement et l'infrastructure, et cela a toujours été un énorme problème. Donc, ces décisions de pile ont toujours été laissées au développeur. Et vous cherchez et vous réfléchissez, OK, quelle application tierce, peut-être CI/CD, avez-vous besoin d'utiliser ? Allons-nous héberger cela sur AWS ? Comment fait-on cela? Quels services ? Et puis vous implémentez en quelque sorte ce genre de solutions potentiellement – ​​ces solutions ad hoc autour de ce flux.

Eh bien, la plateforme Atlas et WordPress Engine Atlas résout vraiment ce problème. C'est là que ça entre en jeu. Nous avons choisi d'aller avec Atlas pour toutes ces raisons, et ils ont cette infrastructure de services gérés. Ils standardisent le pipeline CI/CD. Vous n'avez pas vraiment besoin d'y penser.

Il y a des migrations de données entre les environnements qui se résument essentiellement à un flux en un clic. Cela a toujours été un gros problème avec le passage de l'assurance qualité à la mise en scène à la production. Essentiellement, WordPress Engine et la plate-forme Atlas ont réduit cela à un seul clic.

Et puis il y a juste cette fatigue autour des microservices et DevOps. Il y a juste une lourde charge cognitive de combien vous devez penser et soutenir et être conscient de cela en tant que développeur et le maintenir opérationnel. Ce sont toutes des choses que la plate-forme Atlas prend vraiment hors de votre main et résout de manière bénéfique.

Parlons donc de certaines des dynamiques que je pense que le headless promeut vraiment et qu'il met vraiment en valeur. Le premier pilier ici– il y en a trois. Le premier pilier est l'expérience du développeur. Cela nous permet de choisir le bon outil pour le travail. Et quand je dis nous, je veux dire développeurs.

Cela nous permet de choisir une pile dans laquelle nous voulons écrire du code. Et c'est, pour nous, c'est chez Haus, c'est Next.js et React. Next.js est juste un cadre merveilleux autour de très belles conventions pour le routage, les performances et l'architecture des applications. Et nous voulions aussi mettre en place un design system, et pas seulement un design system visuel mais un design system codifié. C'est quelque chose qui maintient notre application cohérente, testée, belle.

Les interactions sont cohérentes. Cela nous permet également de créer de nouvelles pages et fonctionnalités dans cet écosystème, de les conserver et de maintenir cette cohérence. Cela nous permet également d'écrire du code expressif déclaratif et React l'approuve en tant que bibliothèque. Mais nous croyons aussi en ce style d'écriture en équipe. Cela nous permet de choisir cette pile pour nous sur le front-end, alors que peut-être un site WordPress traditionnel basé sur un thème, nous n'avons pas vraiment le même luxe.

Nous avons également besoin de beaucoup de marge de manœuvre créative. Vous pouvez voir lorsque vous visitez leoburnett.com, il y a de belles transitions de page. Il y a - nous ne sommes pas liés à la pile WordPress traditionnelle sur la façon dont les choses doivent être rendues. WordPress n'est plus en charge du rendu du frontend.

Notre marge de manœuvre est pratiquement illimitée. Nous pouvons choisir nos bibliothèques d'animation. Nous pouvons choisir la manière dont nos composants interagissent les uns avec les autres. C'est un énorme avantage du côté DX.

L'expérience d'administration est élevée, et je pense que nous l'avons optimisée parce que nous ne nous sommes jamais éloignés de leur ancienne familiarité. Il n'y a pas de basculement du backend. Nous sommes passés de WordPress à WordPress. Nous n'avions pas besoin d'exporter des données ni d'écrire des scripts pour passer à un autre système propriétaire. La familiarité est donc énorme. Nous voulions maintenir ce type de flux pour les administrateurs actuels de leoburnett.com.

Adoption et documentation - si vous passez cinq minutes sur le Web, vous avez probablement touché à un back-end WordPress, et cela ne peut tout simplement pas être surestimé. Leo Burnett a également beaucoup de points de contenu très spécifiques et de champs personnalisés. WordPress offre cela et vous donne ce pouvoir, mais nous avons pu implémenter le plugin Advanced Custom Fields, qui est une très belle convention autour de l'ajustement de l'interface utilisateur d'administration pour la rendre vraiment conviviale et utilisable. C'était donc une victoire sur l'expérience d'administration.

Maintenant, bien sûr, le troisième pilier est l'expérience utilisateur. C'est ce qui compte vraiment. Utilisateurs, je pense que nous pensons que les applications Web de Haus devraient ressembler à des applications natives, il ne devrait y avoir aucun abandon. Je pense que les utilisateurs apprécient vraiment cela aussi.

Ils sont sans couture. Ils sont réactifs. Ils se sentent juste bien. Et je pense que nous voulions que Leo Burnett et toutes nos applications ressentent cela. Pouvoir choisir la pile que nous voulons sur le front-end nous permet de le faire.

Les applications natives sont intrinsèquement découplées de leurs infrastructures de contenu back-end, tout comme nos applications Web. Et c'est ce que promeut Atlas. C'est ce que promeut l'architecture sans tête en général. Il favorise également les performances. Nous pouvons rendre universellement notre interface utilisateur. Cela signifie que la charge initiale est côté serveur. Et après cela, le client prend le relais.

Il y a beaucoup d'avantages ici. La première est que cela rend les moteurs de recherche heureux. Il s'agit de contenu côté serveur. C'est rapide. Cela nous permet également de pré-rendre virtuellement instantanément la page suivante et de faire ces demandes en fonction de ce qui se trouve dans la fenêtre d'affichage une seule fois.

Pour Leo Burnett, en termes d'API de contenu que nous avons choisi de consommer, nous avons configuré un point de terminaison GraphQL. Cela signifie que des charges utiles plus légères reviennent. Nous définissons explicitement le contenu dont nous avons besoin. Il y a moins d'hydratation après ce rendu côté serveur dans le rendu côté client.

C'est moins de code venant sur le fil, moins de réponse, des temps de réponse plus rapides. C'est définitivement une victoire, et je suggérerais que si vous allez passer à un flux de travail Atlas ou à un flux de travail sans tête, que vous examiniez attentivement l'utilisation de l'API GraphQL par rapport à quelque chose comme une API REST.

Et du point de vue de l'utilisateur, il voit du contenu frais et opportun. Il s'agit d'un flux de publication optimisé pour la prévisualisation du contenu. Il est optimisé pour les récupérations rapides de contenu du côté de la mise en scène et des aperçus, puis pour le promouvoir en production. Les administrateurs de Leo Burnett sont extrêmement satisfaits de la facilité avec laquelle il est possible de mettre à jour le contenu, ce qui rend les utilisateurs heureux.

Quel est le résultat ? C'est juste une sorte de tout rouler. C'est des développeurs inspirés, des administrateurs productifs et des utilisateurs satisfaits. C'est la triade et l'espoir que je pense que toutes les équipes de développement Web recherchent vraiment.

Lorsque les développeurs sont inspirés, ils utilisent un ensemble optimisé d'outils. Ça fait du bien. Ils sont heureux. Ils écrivent un meilleur code.

Les administrateurs savent qu'ils produisent du contenu dans un bel écosystème. C'est rapide. Il est expédié rapidement. Et les utilisateurs voient ce contenu mis à jour, et ils font l'expérience d'un front-end moderne, beau, qui fonctionne bien et optimisé.

Je pense que pour conclure, quelques dernières réflexions que j'aimerais que vous gardiez à l'esprit. Je pense que le mémoire, en soi, a toujours un langage manquant. Je pense que trop souvent nous ne parlons que de, hé, construisez-moi un beau site Web. Construisez-moi un site Web incroyable. Je veux qu'il ait l'air et qu'il se sente – et nous avons mené toutes ces revues avec des clients.

Et tout le monde s'excite, puis la V1 arrive, et elle est lancée. Et puis les gens qui doivent prendre en charge ce site Web sont comme, tu m'as donné un gâchis. Comment puis-je m'en occuper? Est-ce un flux ad hoc que vous avez conçu ?

Vous ne voulez pas créer un beau site Web et remettre un fardeau. Nous sommes très fiers ici à Haus de ne pas faire cela. Et je pense que ce qui est merveilleux avec Atlas et Atlas en tant que plate-forme, c'est qu'il résout ce problème.

Cela vous donne l'assurance que vous proposez un écosystème et un système de publication Web qui ont du sens du point de vue de l'infrastructure et du déploiement du code. Cela donne une preuve documentée à l'équipe informatique et à l'équipe d'ingénierie ou à l'équipe marketing que vous savez ce que vous faites et qu'ils sont maintenant entre de bonnes mains avec ce nouveau site Web que vous avez construit pour eux.

Parce que rappelez-vous, nous ne construisons pas seulement un site Web. Nous établissons un système de publication de contenu, et c'est essentiel à comprendre et à reconnaître dès le premier jour. Et encore une fois, c'est là qu'Atlas entre en jeu.

J'espère donc que cette petite friandise vous aidera à concevoir stratégiquement votre pile sans tête à l'avenir. Si c'est la direction que vous voulez prendre, je vous encourage fortement à jeter un œil à Atlas. J'espère que vous avez apprécié la séance et merci beaucoup.