Faire fonctionner GraphQL dans WordPress

À propos de l'auteur

Leonardo Losoviz est un développeur et écrivain indépendant, avec une quête permanente d'intégration de paradigmes innovants (PHP sans serveur, composants côté serveur, GraphQL)…
En savoir plus sur
Léonard
↬

WordPress Headless semble être en vogue ces derniers temps, avec de nombreux nouveaux développements qui ont eu lieu au cours des dernières semaines. L'une des raisons de l'explosion de l'activité est la sortie de la version 1.0 de WPGraphQL un serveur GraphQL pour WordPress.

WPGraphQL fournit une API GraphQL: un moyen de récupérer des données et de les publier sur , un site Web WordPress. Cela nous permet de découpler l'expérience de gestion de notre contenu, qui se fait via WordPress, du rendu du site Web, pour lequel nous pouvons utiliser la bibliothèque du framework de notre choix ( React Vue. js Gatsby Next.js ou tout autre).

Jusqu'à récemment, WPGraphQL était le seul serveur GraphQL pour WordPress. Mais maintenant, un autre plugin de ce type est disponible: API GraphQL pour WordPress créé par moi.

Ces deux plugins ont le même objectif: fournir une API GraphQL à un site WordPress. Vous vous demandez peut-être: pourquoi un autre plugin alors qu'il y a déjà WPGraphQL? Ces deux plugins font-ils la même chose? Ou sont-ils pour différentes situations?

Permettez-moi d'abord de dire ceci: WPGraphQL fonctionne très bien. Je n'ai pas construit mon plugin à cause d'un problème avec celui-ci.

J'ai construit l'API GraphQL pour WordPress parce que j'avais travaillé sur un moteur pour récupérer des données efficacement ce qui s'est avéré être très approprié pour GraphQL . Alors, je me suis dit: «Pourquoi pas?», Et je l'ai construit. (Et aussi un couple d'autres raisons .)

Les deux plugins ont des architectures différentes, leur donnant des caractéristiques différentes, ce qui facilite la réalisation de tâches particulières avec un plugin ou l'autre.

Dans cet article, je vais décrire , de mon propre point de vue mais aussi objectivement que possible, quand WPGraphQL est la voie à suivre et quand l'API GraphQL pour WordPress est un meilleur choix.

Utilisez WPGraphQL Si: Utilisation de Gatsby

Si vous créez un site Web en utilisant Gatsby alors il n'y a qu'un seul choix: WPGraphQL.

La raison est que seul WPGraphQL a le plugin source Gatsby pour WordPress . De plus, le créateur de WPGraphQL, Jason Bahl, a été employé jusqu'à récemment par Gatsby, nous pouvons donc être pleinement convaincus que ce plugin répondra aux besoins de Gatsby.

Gatsby reçoit toutes les données du site WordPress, et à partir de là, la logique du l'application sera entièrement du côté de Gatsby, pas sur WordPress '. Par conséquent, aucun ajout à WPGraphQL (comme les ajouts potentiels des directives @stream ou @defer ) ne ferait une grande différence.

WPGraphQL est déjà aussi bon que les besoins de Gatsby

Utilisez WPGraphQL Si: Utilisation de l'un des nouveaux cadres sans tête

Comme je l'ai mentionné, dernièrement, il y a eu une vague d'activité dans l'espace sans tête de WordPress concernant plusieurs nouveaux cadres et projets de démarrage, tous basés sur sur Next.js :

Si vous avez besoin d'utiliser l'un de ces nouveaux frameworks headless, alors vous devrez utiliser WPGraphQL, car ils ont tous été construits sur ce plugin.

C'est un peu malheureux: j'aimerais vraiment que l'API GraphQL pour WordPress puisse également les alimenter. Mais pour que cela se produise, ces frameworks devraient fonctionner avec GraphQL via une interface afin que nous puissions échanger des serveurs GraphQL.

J'espère que l'un de ces frameworks mettra une telle interface en place. J'ai posé une question à ce sujet dans le forum de discussion Headless WordPress Framework et on m'a dit que cela pourrait être envisagé. J'ai également posé la question sur le forum de discussion Next.js WordPress Starter de WebDevStudios, mais hélas, ma question a été immédiatement supprimée, sans réponse. (Pas encourageant, n'est-ce pas?)

Donc WPGraphQL c'est alors, actuellement et dans un avenir prévisible.

Utilisez l'un ou l'autre (ou aucun) Si: Using Frontity

Frontity est un Framework React pour WordPress. Il vous permet de créer une application basée sur React qui est gérée dans le back-end via WordPress. Même la création d'articles de blog à l'aide de l'éditeur WordPress est prise en charge dès le départ.

Frontity gère l'état de l'application, sans divulguer comment les données ont été obtenues. Même s'il est basé sur REST par défaut, vous pouvez également l'alimenter via GraphQL en implémentant le plugin source correspondant .

Voici comment Frontity est intelligent: Le plugin source est une interface pour communiquer avec le fournisseur de données. Actuellement, le seul plugin source disponible est le pour l'API WordPress REST . Mais n'importe qui peut implémenter un plugin source pour WPGraphQL ou l'API GraphQL pour WordPress. (C'est l'approche que je souhaite que les frameworks basés sur Next.js soient répliqués.)

Conclusion : Ni WPGraphQL ni l'API GraphQL n'offrent d'avantage par rapport à l'autre pour travailler avec Frontity, et ils nécessitent tous les deux un premier effort pour les brancher.

Utilisez WPGraphQL Si: Création d'un site statique

Dans les deux premières sections, la conclusion était la même: Utilisez WPGraphQL. Mais ma réponse à cette conclusion était différente: alors qu'avec Gatsby je n'avais aucun regret, avec Next.js je me sentais obligé de faire quelque chose à ce sujet.

Pourquoi?

La différence est que, alors que Gatsby est purement un générateur de site statique, Next.js peut alimenter des sites Web statiques et en direct.

J'ai mentionné que WPGraphQL est déjà assez bon pour Gatsby. Cette affirmation peut en fait être élargie: WPGraphQL est déjà assez bon pour tout générateur de site statique . Une fois que le générateur de site statique obtient les données du site Web WordPress, tout est à peu près réglé avec WordPress.

Même si l'API GraphQL pour WordPress offre des fonctionnalités supplémentaires, cela ne fera probablement pas de différence pour le générateur de site statique.

] Par conséquent, parce que WPGraphQL est déjà assez bon et qu'il a complètement mappé le schéma GraphQL (qui est toujours un travail en cours pour l'API GraphQL pour WordPress), alors WPGraphQL est l'option la plus appropriée, maintenant et dans un avenir prévisible. [19659040] Utilisez l'API GraphQL Si: Utilisation de GraphQL dans un site Web en direct (c'est-à-dire non statique)

Maintenant, la situation ci-dessus change si nous voulons que GraphQL récupère des données à partir d'un site Web en direct, par exemple lors de la mise sous tension d'une application mobile ou du traçage réel données de temps sur un site Web (par exemple, pour afficher des analyses) ou en combinant les approches statiques et en direct sur le même site Web.

Par exemple, disons que nous avons construit un blog statique simple en utilisant l'un des frameworks Next.js, et nous voulons permettre aux utilisateurs pour ajouter des commentaires aux articles de blog. Comment gérer cette tâche?

Nous avons deux options: statique et live (ou dynamique). Si nous optons pour le statique, les commentaires seront rendus avec le reste du site Web. Ensuite, chaque fois qu'un commentaire est ajouté, nous devons déclencher un webhook pour régénérer et redéployer le site Web.

Cette approche présente quelques inconvénients. Le processus de régénération et de redéploiement pourrait prendre quelques minutes, pendant lesquelles le nouveau commentaire ne sera pas disponible. De plus, si le site Web reçoit de nombreux commentaires par jour, l'approche statique nécessitera plus de temps de traitement du serveur, ce qui pourrait devenir coûteux (certaines sociétés d'hébergement facturent en fonction de l'heure du serveur).

Dans cette situation, il serait logique de rendre le site Web statiquement sans commentaires, puis récupérer les commentaires d'un site en direct et les rendre dynamiquement dans le client.

Pour cela, Next.js est recommandé sur Gatsby . Il peut mieux gérer les approches statiques et en direct, y compris la prise en charge de différentes sorties pour les utilisateurs avec des capacités différentes.

Retour à la discussion GraphQL: Pourquoi est-ce que je recommande l'API GraphQL pour WordPress lorsque je traite des données en direct? Je le fais parce que le serveur GraphQL peut avoir un impact direct sur l'application, principalement en termes de vitesse et sécurité .

Pour un site Web purement statique, le site WordPress peut rester privé (il peut même vivre sur l'ordinateur portable du développeur), donc c'est sûr. Et l'utilisateur n'attendra pas une réponse du serveur, donc la vitesse n'est pas nécessairement d'une importance critique.

Pour un site en direct, cependant, l'API GraphQL sera rendue publique, donc la sécurité des données devient un problème. Nous devons nous assurer qu'aucun acteur malveillant ne peut y accéder. De plus, l'utilisateur attendra une réponse, donc la vitesse devient une considération critique.

À cet égard, L'API GraphQL pour WordPress présente quelques avantages par rapport à WPGraphQL .

WPGraphQL implémente la sécurité des mesures, telles que désactivant l'introspection par défaut . Mais l'API GraphQL pour WordPress va plus loin, en désactivant le point final unique par défaut (avec plusieurs autres mesures ). Cela est possible car l'API GraphQL pour WordPress offre requêtes persistantes de manière native.

En ce qui concerne la vitesse, les requêtes persistantes accélèrent également l'API, car la réponse peut alors être mise en cache via la mise en cache HTTP sur plusieurs couches, y compris le client, le réseau de diffusion de contenu et le serveur.

Ces raisons rendent l'API GraphQL pour WordPress mieux adaptée à la gestion des sites Web en direct.

Utilisez l'API GraphQL si: Exposition de données différentes pour différents utilisateurs ou applications [19659003] WordPress est un système de gestion de contenu polyvalent, capable de gérer le contenu de plusieurs applications et accessible à différents types d'utilisateurs.

Selon le contexte, nous pourrions avoir besoin de nos API GraphQL pour exposer différentes données, telles que:

• expose certaines données à des utilisateurs payants mais pas à des utilisateurs non rémunérés,
• exposent certaines données à l'application mobile mais pas au site Web.

Pour exposer différentes données, nous devons fournir différentes versions du Gra schéma phQL .

WPGraphQL nous permet de modifier le schéma (par exemple, nous pouvons supprimer un champ enregistré ). Mais le processus n'est pas simple: les modifications de schéma doivent être codées, et il n'est pas facile de comprendre qui accède à quoi et où (par exemple, tous les schémas seraient toujours disponibles sous le seul point final, / graphql ).

En revanche, l'API GraphQL pour WordPress prend en charge nativement ce cas d'utilisation: elle offre des points de terminaison personnalisés qui peuvent exposer différentes données pour différents contextes, tels que:

• / graphql / mobile- app et / graphql / website
• / graphql / pro-users et / graphql / regular-users .

Chaque coutume le point de terminaison est configuré via listes de contrôle d'accès pour fournir un accès utilisateur granulaire champ par champ, ainsi qu'un mode API public et privé pour déterminer si les métadonnées du schéma sont accessibles à tous ou uniquement aux utilisateurs autorisés.

Ces fonctionnalités s'intègrent directement à l'éditeur WordPress (i. e. Gutenberg). Ainsi, la création des différents schémas se fait visuellement, de la même manière que la création d'un article de blog. Cela signifie que tout le monde peut produire des schémas GraphQL personnalisés pas seulement les développeurs.

L'API GraphQL pour WordPress fournit, je crois, une solution naturelle pour ce cas d'utilisation.

Utilisez l'API GraphQL Si: Interagir avec Services externes

GraphQL n'est pas simplement une API pour récupérer et publier des données. Aussi important (bien que souvent négligé), il peut également traiter et modifier les données – par exemple, en les alimentant vers un service externe, tel que l'envoi de texte à une API tierce pour corriger des erreurs de grammaire ou le téléchargement une image vers un réseau de diffusion de contenu.

Quelle est la meilleure façon pour GraphQL de communiquer avec des services externes? À mon avis, ceci est mieux réalisé par des directives appliquées lors de la création ou de la récupération des données (un peu comme le fonctionnement des filtres WordPress).

Je ne sais pas dans quelle mesure WPGraphQL interagit avec les services externes, car sa documentation ne le mentionne pas, et la base de code ne propose pas d'exemple de directive ou de document sur la façon d'en créer une.

En revanche, l'API GraphQL pour WordPress a un support robuste pour les directives . Chaque directive d'une requête n'est exécutée qu'une seule fois au total (par opposition à une fois par champ et / ou objet). Cette fonctionnalité permet une communication très efficace avec des API externes et intègre l'API GraphQL dans un nuage de services.

Par exemple, cette requête montre un appel à l'API Google Translate via un @ translate pour traduire les titres et extraits de nombreux articles de l'anglais vers l'espagnol. Tous les champs de tous les articles sont traduits ensemble, en un seul appel.

L'API GraphQL pour WordPress est un choix naturel pour ce cas d'utilisation.

Note : En fait, le moteur sur lequel l'API GraphQL pour WordPress est basée, GraphQL by PoP, a été spécialement conçu pour fournir des capacités avancées de manipulation de données. C'est l'une de ses caractéristiques distinctes. Pour un exemple extrême de ce qu'il peut réaliser, consultez le guide « Envoi d'une newsletter localisée, utilisateur par utilisateur ».

Jason Bahl a fait un excellent travail de ralliement d'une communauté autour WPGraphQL. En conséquence, si vous avez besoin de dépanner votre API GraphQL, vous trouverez probablement quelqu'un qui pourra vous aider.

Dans mon cas, je m'efforce toujours de créer une communauté d'utilisateurs autour de l'API GraphQL pour WordPress, et il est certainement loin de celui de WPGraphQL.

Utilisez l'API GraphQL Si: Vous aimez l'innovation

J'appelle l'API GraphQL pour WordPress un serveur GraphQL «tourné vers l'avenir». La raison en est que je parcoure souvent la liste des requêtes pour la spécification GraphQL et que j'en implémente certaines bien à l'avance (en particulier celles pour lesquelles je ressens une certaine affinité ou que je peux supporter avec peu d'effort). [19659006] À ce jour, l'API GraphQL pour WordPress prend en charge plusieurs fonctionnalités innovantes (telles que exécution de requêtes multiples et espace de noms de schéma ), proposées en option, et il est prévu de quelques autres .

Utilisez WPGraphQL si: Vous avez besoin d'un schéma complet

WPGraphQL a complètement mappé le modèle de données WordPress y compris:

• articles et pages,
• types de publication personnalisés,
• catégories et balises,
• taxonomies personnalisées,
• médias,
• menus,
• paramètres,
• utilisateurs,
• commentaires,
• plugins,
• thèmes,
• widgets.

L'API GraphQL pour WordPress cartographie progressivement le modèle de données w avec chaque nouvelle version. À ce jour, la liste comprend:

• articles et pages,
• types d'articles personnalisés,
• catégories et balises,
• taxonomies personnalisées,
• médias,
• menus,
• paramètres,
• utilisateurs,
• commentaires.

Donc, si vous avez besoin de récupérer des données à partir d'un plugin, d'un thème ou d'un widget, actuellement seul WPGraphQL fait le travail.

Utilisez WPGraphQL If: You Need Extensions

WPGraphQL propose des extensions pour de nombreux plugins y compris Advanced Custom Fields, WooCommerce, Yoast, Gravity Forms.

L'API GraphQL pour WordPress offre une extension pour Events Manager, et elle continuera à en ajouter après la sortie de la version 1.0 du plugin.

Utilisez l'un ou l'autre si: Création de blocs pour l'éditeur WordPress

WPGraphQL et l'API GraphQL pour WordPress travaillent actuellement sur l'intégration de GraphQL avec Gutenberg.

Jason Bahl a décrit trois approches par lequel cette intégration peut avoir lieu. Cependant, comme tous ont des problèmes, il préconise l'introduction d'un registre côté serveur sur WordPress, afin de permettre l'identification des différents blocs Gutenberg pour le schéma GraphQL.

L'API GraphQL pour WordPress dispose également d'un approche d'intégration avec Gutenberg basée sur la stratégie «créer une fois, publier partout». Il extrait les données de bloc du contenu stocké et il utilise un seul type Bloc pour représenter tous les blocs. Cette approche pourrait éviter le besoin du registre côté serveur proposé.

La solution de WPGraphQL peut être considérée comme provisoire, car elle dépendra de l'acceptation par la communauté de l'utilisation d'un registre côté serveur, et nous ne savons pas si ni quand

Pour l'API GraphQL pour WordPress, la solution dépendra entièrement d'elle-même, et c'est en effet déjà un travail en cours.

Parce qu'elle a plus de chances de produire bientôt une solution fonctionnelle, je serais enclin à recommander API GraphQL pour WordPress . Cependant, attendons que la solution soit entièrement mise en œuvre (dans quelques semaines, selon le plan) pour nous assurer qu'elle fonctionne comme prévu, puis je mettrai à jour ma recommandation.

Utilisez l'API GraphQL Si: Distribuer des blocs via un Plugin

J'en suis venu à une réalisation: peu de plugins (le cas échéant) semblent utiliser GraphQL dans WordPress.

Ne vous méprenez pas: WPGraphQL a dépassé 10 000 installations. Mais je crois que ce sont principalement des installations pour alimenter Gatsby (afin d'exécuter Gatsby) ou pour alimenter Next.js (afin d'exécuter l'un des frameworks headless).

De même, WPGraphQL a de nombreuses extensions, comme je l'ai décrit plus tôt . Mais ces extensions ne sont que cela: des extensions. Ce ne sont pas des plugins autonomes.

Par exemple, l'extension WPGraphQL pour WooCommerce dépend à la fois des plugins WPGraphQL et WooCommerce. Si l’un d’eux n’est pas installé, l’extension ne fonctionnera pas, et c’est OK. Mais WooCommerce n’a pas le choix de s’appuyer sur WPGraphQL pour fonctionner; par conséquent, il n'y aura pas de GraphQL dans le plugin WooCommerce.

Je crois comprendre qu'il n'y a pas de plugins qui utilisent GraphQL pour exécuter des fonctionnalités pour WordPress lui-même ou, en particulier, pour alimenter leurs blocs Gutenberg.

La raison en est simple: ni WPGraphQL ni l'API GraphQL pour WordPress ne font partie du noyau de WordPress. Ainsi, il n'est pas possible de s'appuyer sur GraphQL de la même manière que les plugins peuvent s'appuyer sur l'API REST de WordPress. En conséquence, les plugins qui implémentent des blocs Gutenberg peuvent uniquement utiliser REST pour récupérer les données de leurs blocs, pas GraphQL.

Apparemment, la solution est d'attendre qu'une solution GraphQL (très probablement WPGraphQL) soit ajoutée au cœur de WordPress. Mais qui sait combien de temps cela prendra? Six mois? Une année? Deux ans?

Nous savons que WPGraphQL est envisagé pour le cœur de WordPress parce que Matt Mullenweg y a fait allusion. Mais tant de choses doivent se produire avant cela: passer la version minimale de PHP à 7.1 (requise à la fois par WPGraphQL et l'API GraphQL pour WordPress), ainsi que d'avoir un découplage, une compréhension et une feuille de route clairs pour les fonctionnalités de GraphQL.

(L'édition complète du site, actuellement en cours de développement, est basée sur REST. Qu'en est-il de la prochaine fonctionnalité majeure, les blocs multilingues, à traiter dans la phase 4 de Gutenberg? Sinon, quelle fonctionnalité sera-t-il?)

Après avoir expliqué la problème, considérons une solution potentielle – une solution qui n'a pas besoin d'attendre!

Il y a quelques jours, j'ai eu une autre réalisation: à partir de l'API GraphQL pour la base de code de WordPress, je peux produire un plus petit version, contenant uniquement le moteur GraphQL et rien d'autre (pas d'interface utilisateur, pas de points de terminaison personnalisés, pas de mise en cache HTTP, pas de contrôle d'accès, rien de rien). Et cette version peut être distribuée en tant que dépendance Composer, afin que les plugins puissent l'installer pour alimenter leurs propres blocs.

La clé de cette approche est que ce composant doit être d'une utilité spécifique pour le plugin, et ne doit pas être partagé avec personne. autre. Sinon, deux plugins référençant tous les deux ce composant pourraient modifier le schéma de telle manière qu'ils se surchargent.

Heureusement, j'ai récemment résolu la portée de l'API GraphQL pour WordPress . Donc, je sais que je suis capable de l'étendre complètement, en produisant une version qui ne sera en conflit avec aucun autre code sur le site.

Cela signifie qu'il fonctionnera pour n'importe quelle combinaison d'événements :

• Si le plugin contenant le composant est le seul à l'utiliser;
• Si l'API GraphQL pour WordPress est également installée sur le même site Web;
• Si un autre plugin intégrant également ce composant est installé sur le site Web; [19659058] Si deux plugins qui intègrent le composant font référence à la même version du composant ou à des versions différentes.

Dans chaque situation, le plugin aura son propre moteur GraphQL autonome et privé sur lequel il pourra entièrement compter pour alimenter ses blocs Gutenberg (et il ne faut craindre aucun conflit).

Ce composant, appelé Private GraphQL API devrait être prêt dans quelques semaines. (J'ai déjà commencé à travailler dessus .)

Par conséquent, ma recommandation est que, si vous voulez utiliser GraphQL pour alimenter des blocs Gutenberg dans votre plugin, veuillez patienter quelques semaines, puis vérifiez API GraphQL pour le plus jeune frère de WordPress, l'API Private GraphQL.

Conclusion

Même si j'ai un skin dans le jeu, je pense avoir réussi à écrire un article qui est principalement objectif.

J'ai été honnête en expliquant pourquoi et quand vous devez utiliser WPGraphQL. De même, j'ai été honnête en expliquant pourquoi l'API GraphQL pour WordPress semble être meilleure que WPGraphQL pour plusieurs cas d'utilisation.

En termes généraux, nous pouvons résumer comme suit:

• Passer au statique avec WPGraphQL , ou passez en direct avec l'API GraphQL pour WordPress.
• Jouez la sécurité avec WPGraphQL ou investissez (pour un gain potentiellement digne) dans l'API GraphQL pour WordPress.

Sur une note finale, je souhaite les frameworks Next.js ont été restructurés pour suivre la même approche utilisée par Frontity: où ils peuvent accéder à une interface pour récupérer les données dont ils ont besoin, au lieu d'utiliser une implémentation directe d'une solution particulière (l'actuelle étant WPGraphQL). Si cela se produisait, les développeurs pourraient quel serveur sous-jacent utiliser (que ce soit WPGraphQL, l'API GraphQL pour WordPress ou une autre solution introduite dans le futur), en fonction de leurs besoins – d'un projet à l'autre.

Utile Liens

(vf, yk, il, al)