Appuyez sur ceci : WPGraphQL et Faust.js

Bienvenue sur Press This, le podcast de la communauté WordPress de WMR. Chaque épisode présente des invités de toute la communauté et des discussions sur les plus grands problèmes auxquels sont confrontés les développeurs WordPress. Ce qui suit est une transcription de l' enregistrement original.

Propulsé par RedCircle

Doc Pop : Vous écoutez Press This, un podcast de la communauté WordPress sur WMR. Chaque semaine, nous mettons en lumière les membres de la communauté WordPress. Je suis votre hôte, Doc Pop. Je soutiens la communauté WordPress à travers mon rôle chez WP Engine et mes contributions sur TorqueMag.Io où je peux faire des podcasts et dessiner des dessins animés et des tutoriels vidéo. Vérifiez cela.

Vous pouvez vous abonner à Press This sur Red Circle, iTunes, Spotify, ou vous pouvez télécharger des épisodes directement sur wmr.fm.

Dans cet épisode de Press This, nous parlons de Headless WordPress, GraphQL et Faust.js. Comment ces outils peuvent être utilisés ensemble et quel type de coût pourrait être associé à Headless WordPress. Nous allons en quelque sorte essayer d'approfondir cela, et j'ai deux invités formidables qui me rejoignent aujourd'hui, j'ai Jason Bahl, un ingénieur logiciel principal chez WP Engine basé à Denver, Colorado, où il maintient WPGraphQL . Et nous avons Chris Weigman, un responsable de l'ingénierie travaillant sur Faust.js. J'aime généralement commencer ces émissions en interrogeant les invités sur leurs histoires d'origine WordPress, mais j'ai pensé que je changerais un peu les choses ici.

Jason, pouvez-vous nous dire ce qu'est WPgraphQL et quelle est son histoire wordPress Origin.

Jason Bahl : Oh oui, WPGraphQL est un plugin WordPress open source gratuit qui apporte une API GraphQL à votre site WordPress et GraphQL est un langage de requête graphique. Ainsi, il permet aux développeurs d'obtenir du contenu dans et hors de WordPress en utilisant le langage de requête graphique.

Et le plugin est né, je travaillais dans un journal il y a quelques années et nous faisions beaucoup de syndication de contenu. Nous avions un réseau de quelque chose comme 54 sites et partout aux États-Unis et nous devions déplacer le contenu d'un côté à l'autre. Vous savez, lorsqu'un reportage était publié, différents journaux pouvaient s'abonner au contenu d'autres journaux.

Ainsi, lorsque divers événements se sont produits, nous devions déplacer des données sur ce réseau et nous utilisions l'API WordPress REST pour effectuer une grande partie de ce déplacement de données. Et avaient des problèmes avec cela techniquement et comme les performances réelles techniquement, mais aussi l'expérience des développeurs. J'ai découvert GraphQL, le véritable langage de requête graphique, qui était open source par Facebook en 2015.

J'ai donc trouvé cette technologie, fait du prototypage, l'ai présentée à mes collègues, puis nous avons migré notre syndication de contacts de REST vers GraphQL. Et puis j'ai continué à travailler sur le projet en tant que projet communautaire en sachant que les frameworks JavaScript devenaient la chose à la mode et que ce serait probablement le principal cas d'utilisation de GraphQL, comme la communication de serveur à serveur n'est pas le principal cas d'utilisation. Cela a répondu à nos besoins, mais j'ai vu une vision plus large pour cela, alors j'ai continué à travailler dessus en tant que projet open source pour la communauté.

DP : Eh bien, cool. Chris, pouvez-vous nous raconter une histoire similaire sur ce qu'est Faust et comment est-il arrivé ?

Chris Weigman : Bien sûr, Faust est, depuis vraiment cette semaine, officiellement rendu public, réédité dans le cadre public pour la création de sites WordPress sans tête à l'aide de GraphQL. Eh bien, le développement a commencé en 2020, et c'était une sorte de projet non officiel de WP Engine, et c'est le troisième pivot majeur.

Ils l'avaient commencé comme une extension de DevRel, en quelque sorte commencé à le rendre un peu plus officiel avec et pivoté vers quelque chose appelé GQty et une mentalité très JavaScript, développeur d'abord. Et puis quand j'ai repris l'équipe le 1er décembre de l'année dernière, on s'est rendu compte que ce n'était pas notre marché cible.

Nous aurions dû développer pour les développeurs WordPress. Nous avons donc recommencé à le reconstruire, et il a finalement pu être réédité récemment.

DP : Jason, vous avez récemment tweeté que vous aviez lancé le nouveau wpgraphql.com sur Faust.js. Le site précédent, je crois, était WordPress sans tête. Pouvez-vous nous parler de ce changement que vous avez fait et vous savez, quelles améliorations vous dites ?

JB : Ouais. Donc, wpgraphql.com, c'est un site sans tête depuis de nombreuses années. J'utilise donc plusieurs sources de données. J'ai donc beaucoup de contenu dans WordPress, comme les articles de blog sont tous dans WordPress.

Une partie de la documentation existe également dans WordPress. Et puis une documentation existe dans les fichiers de démarquage dans le référentiel GitHub. Pendant la plus longue période, j'ai utilisé Gatsby, peut-être pendant environ trois ans, j'ai utilisé Gatsby, qui est un framework JavaScript qui, à la base, a sa couche de données où vous pouvez extraire des données de plusieurs sources.

Donc, j'utilisais cela, cela extrairait des données de GitHub, extrairait également des données de WordPress en utilisant WPGraphQL et me permettrait d'utiliser ces données pour créer mes modèles. Je l'ai donc utilisé pendant quelques années. Il y a beaucoup de points faibles avec la couche de données dont je voulais en quelque sorte sortir.

J'ai donc voulu utiliser Next sur lequel Faust est construit. C'est un autre framework JavaScript, mais il y avait beaucoup de pièces manquantes, je suppose. Ensuite, et beaucoup de ces frameworks JavaScript ont l'idée que vos frameworks frontaux devraient définir tout le routage, n'est-ce pas ? Mais si vous utilisez un CMS, votre CMS définit le routage.

Et donc il y a beaucoup de problèmes techniques pour que ces choses fonctionnent bien, où votre front-end a une opinion sur quelque chose et votre back-end a une opinion différente. Donc, comme l'un des problèmes que j'essayais de résoudre, c'est que mon frontal reconnaisse qu'une URL spécifique était un type de chose spécifique, puis rend un modèle qui représentait cette chose.

Par exemple, un article de blog a un modèle différent de celui d'un document ou d'une archive utilisateur ou autre. Je voulais donc que mon frontal ait la possibilité d'envoyer une URL au CMS, de récupérer des données, mais de comprendre quel modèle renvoyer. Dans WordPress, c'est ce qu'on appelle la hiérarchie des modèles. Et donc, quand l'équipe de Faust a réussi à résoudre ce problème, je me suis dit, bon sang, je passe à Faust.

Donc, oui, je suis capable de prendre certains des concepts qui existent dans le noyau de WordPress, comme le thème PHP et de les utiliser sans tête afin que je puisse utiliser les avantages de React et de tout JavaScript que je veux utiliser sur le front-end pour modéliser mon site, mais encore des concepts familiers du monde WordPress.

DP : Chris, vous mentionniez que Faust avait en quelque sorte subi quelques changements. Quels étaient ces changements ? Vous savez, Jason en parlait. Quels sont certains de ces changements qui ont rendu cette amélioration possible ?

CW : Il est toujours axé sur WPGraphQL. C'était tout le reste qui était vraiment le problème. Par exemple, la dernière version majeure de Faust utilisait une bibliothèque en dessous pour interagir avec GraphQL appelée GQty, qui sur le papier semblait vraiment cool. L'idée étant de l'équipe Faust à l'époque que, soyons abstraits, les gens ne devraient pas avoir besoin de savoir comment construire ces requêtes complexes.

Ce cadre devrait résumer cela pour vous. Sur le papier, cela avait l'air vraiment bien, en pratique à cause de toutes les complexités des données WordPress. Même un seul type de message peut avoir autant de variations. Peut-être que vous mélangez cela avec la catégorie, peut-être toutes les différentes choses. GQty ne pouvait tout simplement pas le faire passer.

En plus de cela, quand il a été construit avec la version GQty, il n'y avait vraiment aucune attention accordée au problème de routage dont parlait Jason. Qui gère le routage ? WordPress veut gérer son routage en fonction de ce qu'est le contenu, c'est un système de gestion de contenu, donc tout le routage et WordPress sont en grande partie basés sur le contenu.

Next.js est un framework frontal, donc tout le routage est basé sur, c'est un paradigme complètement différent sur la façon dont le routage est basé. Ce qui pourrait être /Blog sur Next n'a peut-être rien à voir avec le contenu d'un blog. Il s'agit d'un ensemble de modèles. Il s'agit d'une partie de l'application qui permet de créer un blog.

Alors que /Blog sur WordPress pourrait très bien signifier, ce sont tous les articles de blog. Et ce paradigme lors de la construction, si vous voulez faire de WordPress un CMS frontal ou sans tête très solide, nous avons dû gérer ce routage. Un autre changement lorsque nous avons fait cela, comme je l'ai dit avec la version GQty, notre objectif était les développeurs JavaScript qui devaient utiliser WordPress, ce qui semble noble jusqu'à ce que vous réalisiez qu'il s'agit de WP Engine.

Nous avons affaire à des agences qui ont construit sur WordPress pendant des années, qui maintenant, pour diverses raisons que nous pourrons aborder plus tard, se tournent vers une chose sans tête. Ils savent comment faire du développement WordPress. Ils comprennent comment fonctionnent les routages de modèles WordPress et les modèles, des choses comme ça.

Nous devons faire avancer ces fonctionnalités, afin que GraphQL puisse être utilisé plus facilement par les développeurs WordPress. Et c'est ce qu'a été le but de Faust ici. La hiérarchie des modèles reconstruit simplement ce que WordPress a fait. Maintenant, si vous souhaitez utiliser le routage de Next, il existe des moyens de le remplacer dans l'application afin de ne rien perdre.

Mais pour les personnes qui utilisent WordPress comme un véritable système de gestion de contenu, capable de router le contenu par la gestion de contenu, alors Faust va-t-il gérer cela beaucoup mieux pour vous ? Cela a-t-il du sens?

DP : Ouais. Absolument. Tu sais, je pense que c'est un bon endroit pour faire une petite pause ici. Vous écoutez Press This, un podcast de la communauté WordPress avec Chris Weigman et Jason Bahl. Nous reviendrons pour parler de WordPress et du headless. Restez à l'écoute.

DP : Nous sommes de retour avec Press This. Et vous savez, Chris, juste avant cette pause, vous avez mentionné quelque chose, vous avez mentionné que de plus en plus d'entreprises se lancent dans le sans tête, et je sais que WP Engine a fait beaucoup de recherches pour montrer que c'est le cas. Je me demande un peu, sans tête a définitivement une réputation de quelque chose, je pense que l'entreprise, quand je pense sans tête, est-ce que je pense correctement. C'est ça sans tête ? Est-ce juste un outil pour l'entreprise ou est-ce un outil que plus de sites vont utiliser ?

CW : Oui et non. En grande partie sans tête, en particulier avec WordPress en ce moment, la complexité impliquée signifie que vous avez probablement une équipe complète qui construit ce dont vous avez besoin.

Ce n'est pas quelqu'un qui utilise simplement WordPress prêt à l'emploi, que vous voulez juste votre blog personnel. Il peut le faire, mais c'est un ascenseur beaucoup plus lourd jusqu'à présent pour pouvoir le faire. Même avec Contentful, même avec tous ces autres CMS. Si vous vouliez juste quelque chose de simple, quelque chose qui, vous savez, le type de contenu qui est sur le Web depuis des années, sans tête, c'est probablement plus de travail que vous ne voulez en gérer jusqu'à présent.

Est-ce strictement une entreprise ? Regardez, non. Gatsby travaille sur ce problème depuis des années. Vous avez un autre podcast plus tard, Doc avec Mastodon. C'est une communauté avec laquelle j'ai été impliqué pendant un certain nombre d'années. La plupart des gens utilisent des variantes de CMS sans tête, en particulier Gatsby, mais il y a Hugo. Il y a toutes sortes de technologies différentes à un niveau très local.

Ainsi, vous vous retrouvez avec les utilisateurs de base et vous vous retrouvez avec les utilisateurs d'entreprise pour les sites lourds, alors que WordPress semble traditionnellement tomber avec tout le monde entre les deux. C'est la personne qui ne veut pas gérer les fichiers et le code de démarquage comme le ferait un utilisateur de Gatsby, ou vous savez, juste Gatsby prêt à l'emploi de toute façon.

Mais ce n'est pas non plus quelqu'un qui a toute une équipe de 10 personnes pour construire sa marque personnelle ou son blog personnel. Cela sort WordPress de ce milieu et l'étend très facilement aux deux extrémités. Maintenant, vous pouvez facilement construire entre GraphQL, vous avez toutes les données et vous avez un ensemble toujours croissant de façons de gérer ces données.

Et Faust facilite beaucoup son utilisation et quelque chose que vous pouvez construire en un jour au lieu d'un mois.

DP : Jason, Chris a mentionné quelque chose sur lequel j'aimerais entendre vos réflexions, j'entends que ce n'est peut-être pas idéal pour les petites équipes, les petits blogueurs comme moi, ce qui est évidemment logique, je n'ai pas besoin d'un WordPress sans tête, mais comme , je suppose que ce que je me demande, est-ce que WordPress sans tête va me coûter plus cher parce que je vais devoir avoir un développeur iOS et un développeur WordPress ? Est-ce plus cher ou est-ce en quelque sorte plus rentable?

JB : Cela dépend probablement de ce que vous produisez, je suppose. Si vous faites, comme vous l'avez mentionné iOS, si vous faites une application mobile native, je veux dire qu'il y a évidemment des coûts associés à cela, et il n'y a pas vraiment de bonne façon de le faire si vous utilisez des données de WordPress, d'autres que de le faire sans tête, car vous savez, une application native ne rend pas php, vous devriez donc le faire sans tête.

Mais pour autant que si vous construisez pour le Web en ce moment dans WordPress traditionnel, vous pouvez aller trouver un thème, vous connaissez soit un thème gratuit ou trouver un thème sur un marché, le télécharger, l'installer, et vous êtes hors de la course. La plupart des gens vont le personnaliser d'une manière ou d'une autre.

Donc, vous aurez généralement un coût de développeur, que ce soit vous-même ou quelqu'un d'autre. L'une des choses avec WordPress sans tête qui diffère du thème PHP traditionnel, c'est que, par exemple, lorsque j'ai lancé le nouveau wpgraphql.com, j'ai pu utiliser la même instance de WordPress qui alimentait mon site Gatsby.

J'obtenais les données, les données sortaient et entraient dans le site Gatsby, j'ai pu continuer à publier du contenu dans le CMS tout en développant ma prochaine interface en même temps. Dans le développement WordPress traditionnel, vous devez généralement migrer votre site vers un environnement de mise en scène.

Activez un nouveau thème sur cet environnement, créez votre thème là-bas, faites face à une sorte de période de gel du contenu où vous dites à vos créateurs de contenu : "Hé, aujourd'hui, vous ne pouvez pas publier de contenu car nous allons migrer et ensuite nous ' Je vais définir la nouvelle instance WordPress, l'instance en direct. » Et puis vous devez vous connecter là-bas et commencer à faire votre contenu correctement.

Headless WordPress, j'ai pu reconstruire mon site sur une pile frontale complètement différente sans rien perturber dans mon instance WordPress actuelle, c'est une séparation des données et de la présentation, non ? Donc je pourrais partir, si je voulais explorer la prochaine technologie en vogue demain, comme si je pouvais mettre mon dévolu sur Svelte au lieu de Next, et je n'aurais rien à changer dans WordPress.

Donc, dans certains cas, cela peut en fait être moins cher parce que tout ce processus de création d'un autre serveur, obligeant votre équipe à arrêter d'écrire du contenu, puis à passer à une autre instance de WordPress, puis à commencer à publier là-bas, à faire des migrations Delta, des choses comme ça, ça a aussi un coût.

Une autre chose intéressante est que l'écosystème JavaScript est vraiment en train d'être livré. Le lecteur commun, à mon avis, l'un des facteurs de motivation communs pour se déplacer sans tête est les architectures basées sur les composants. Et il y a toutes sortes de bibliothèques de composants dans l'écosystème React et VUE, qui vous permettent de réutiliser les composants à travers les projets.

Ainsi, les agences peuvent créer des composants communs qu'elles utilisent dans des projets et elles peuvent les mettre à jour dans un emplacement central, puis les installer dans plusieurs projets. Avec WordPress, ce n'est pas aussi simple car vos parties de modèle PHP et WordPress sont généralement très étroitement liées au projet auquel elles appartiennent.

Où avec headless, vous pouvez avoir un package MPM contenant ces composants et plusieurs projets peuvent mettre à jour ce package et en bénéficier tous en même temps avec moins d'effort. Donc, je pense que pour le moment, je dirais que c'est probablement plus coûteux et plus de travail, mais je pense que des outils comme Faust, qui n'existaient pas jusqu'à récemment, réduisent l'effort global requis pour construire sans tête.

Et je pense que dans un avenir pas trop lointain, il pourrait être moins cher de construire sans tête que pas sans tête.

DP : Chris, aviez-vous quelque chose à ajouter à ce que les agences pourraient devoir penser en termes de coûts de WordPress sans tête ?

CW : Je pense que Jason a vraiment mis le doigt dans le mille.

Et c'est une chose que j'aime à propos de WPGraphQL, c'est que mon équipe travaille ensuite à étendre WordPress dans cette direction avec ce que nous appelons, notre titre de travail est le React Gutenberg Bridge, mais c'est aussi un problème dans WordPress. Comment réutiliser ces composants ? Je ne veux pas utiliser le mot juste composant, car il ne s'applique pas du côté WordPress de la même manière qu'il s'applique du côté JavaScript, n'est-ce pas ?

Mais comment réutiliser le code à travers les projets, sans tête ou autrement avec WordPress et sans tête permet cela. Mais je pense qu'il est prudent de dire que le blogueur moyen essaie simplement de sortir ses blogs gastronomiques, sans s'en occuper lui-même. C'est vraiment un problème d'agence. Est-ce plus coûteux ?

Peut-être, peut-être pas, mais c'est là que ça se complique quand on parle de où est le coût là-dedans ? Parce que ce sont différents types d'utilisation des données.

DP : Oui, absolument. Vous savez, venant d'un milieu de presse, travaillant sur Weeklys dans les villes jumelles et à Nashville, Jason, je peux imaginer ce que ça aurait été de dire à vos 56 journaux de ne pas publier pendant une journée.

Pas de nouvelles aujourd'hui, car nous mettons à jour le site.

JB : Ouais. Et je veux dire, nous avons traversé ces périodes, n'est-ce pas? Comme lorsque j'ai été embauché là-bas, ils n'étaient pas sur WordPress et donc une partie de mon travail consistait à les faire passer d'un autre système à WordPress. Donc, il y a certainement eu des jours où c'était comme, d'accord, c'est mis en ligne le jour de WordPress. Arrêtez ce que vous faites. Droite.

Donc, il y a certainement eu des périodes comme celle-là ou nous avons également dû faire face à ce problème du genre, d'accord, ils publiaient sur l'ancien système jusqu'à minuit hier soir, mais nous avions le WordPress prêt à fonctionner deux jours avant cela. Alors maintenant, nous devons faire comme une migration Delta et nous assurer que toutes les données sont toujours synchronisées afin que, vous savez, il y ait certainement un coût technique et humain pour ces processus.

DP : Ouais. Et je pense qu'il y a aussi beaucoup, lorsque vous utilisez encore WordPress, vous obtenez toujours cet écosystème qui vous permet d'obtenir cette économie de coûts. Vous n'avez pas à créer les outils de référencement.

Vous pouvez utiliser le plugin Yoast SEO ou autre. Même si vous êtes un site Headless, je suppose que la plupart des plugins fonctionneront toujours tant qu'ils ne sont pas en face avant.

JB : Ouais. C'est en fait une chose intéressante. Ainsi, le nouveau Faust est construit avec une architecture de plugin elle-même. Donc, comme prêt à l'emploi, il va venir avec un client, il utilise le client Apollo pour que vous puissiez récupérer des données de WPGraphQL, vous pouvez obtenir vos données WordPress, mais vous pouvez créer des plugins pour que, disons que vous l'avez fait, comme vous mentionné, installez Yoast SEO sur votre site WordPress.

Vous pouvez ajouter un plugin Yoast. Il n'existe pas encore, mais il le pourra bientôt. Vous pouvez ajouter un plugin Yoast pour Faust sur le frontend qui sait quoi faire avec ces données, n'est-ce pas ? Il y aura donc la possibilité pour les gens, certains que nous pourrions produire et prendre en charge, mais certains, la communauté peut également produire et prendre en charge des plugins pour le côté Faust des choses, de sorte que vous avec une seule ligne de code, ajoutez ce plugin peut obtenez des fonctionnalités telles que Yoast pour votre frontal sans tête.

C'est quelque chose dont je ne pense pas qu'aucune autre interface sans tête ait vraiment le concept de la même manière que Faust l'aborde. Donc je pense que le plugin, je pense que c'est une autre chose qui est familière aux développeurs WordPress. Il apporte des concepts familiers de WordPress, mais le relie à la pile frontale JavaScript moderne.

DP : c'est un, c'est un bon endroit pour une dernière pause ici sur Press This, et quand nous reviendrons, nous terminerons notre conversation avec Chris Weigman et Jason Bahl. Restez à l'écoute.

DP : Vous écoutez Press This, un podcast de la communauté WordPress. Je suis votre hôte, Doc Pop. Aujourd'hui, nous parlons de WPGraphQL, de Faust et de la façon dont vous pouvez alimenter votre site WordPress sans tête. Juste avant la pause, nous parlions de Faust et de plugins et je vais juste vous poser quelques questions au hasard et juste voir s'il y a de bonnes réponses ici qui se présentent.

Mais Chris, je me demande un peu avec, avec Faust, y a-t-il un potentiel, je sais que c'est une plate-forme sans tête, mais y a-t-il un potentiel comme un thème WordPress Faust qui vous permet au moins de vous installer comme, voici les plugins dont vous avez besoin et voici juste un peu tout ce qui est prêt à l'emploi.

CW : Absolument. En fait, nous l'avons déjà. Nous l'appelons Blueprints parce qu'il fonctionne si étroitement avec Local. La plupart des gens vont faire une sorte de peaufinage sur ce truc avant de le lancer sur une plate-forme comme WP Engine. Nous avons donc emprunté le nom de Blueprints à Local.

Pour le nouveau Faust, nous en avons un appelé Portfolio, qui est essentiellement un thème de portefeuille complet et nous travaillons sur un échafaudage très vierge que les agences peuvent utiliser. Une fois que vous aurez compris les choses, vous voudrez probablement tout personnaliser vous-même. Donc, un échafaudage serait les meilleures pratiques de projet, faites-le tourner, et vous pourrez ensuite faire tout ce que vous voulez avec.

À long terme, nous avons beaucoup parlé d'un magasin à thème sans tête, ala Blueprints. Nous n'avons pas la main-d'œuvre, donc c'est un peu loin, mais c'est absolument quelque chose que nous envisageons et que nous aimerions voir se produire.

DP : Ouais c'est cool d'y penser. C'est un tout autre type d'écosystème dans lequel entrer.

Et vous savez, Jason, je vous ai déjà interviewé, et je suis sûr que cette question revient tout le temps, mais chaque fois que j'entends parler de WPGraphQL, je pense que cela ressemble beaucoup à ce que fait l'API REST. En fait, cela semble beaucoup plus puissant que ce que fait l'API REST et l'API REST fait partie du noyau et je me demande simplement si vous pensez que WPGraphQL devrait faire partie de WordPress Core ?

JB : Peut-être un jour. Je ne pense pas que nous en soyons encore là. Lorsque les choses sont fusionnées dans WordPress Core, probablement à l'exception de Gutenberg, l'innovation s'arrête. L'API REST, par exemple, il y a toujours un bogue que je signale aux gens qui existe toujours depuis je pense 2016. Donc je veux dire, quand les choses entrent dans le noyau, vous ajoutez un ensemble de fonctionnalités à 40 % du web et donc apporter des modifications doit être fait à un rythme beaucoup plus lent, où s'il s'agit d'un plugin, vous pouvez laisser les gens opter pour la version qu'ils souhaitent opter et vous pouvez itérer beaucoup plus rapidement car ils peuvent choisir la version qui convient le mieux à leur projet.

Où dans le noyau, si vous mettez à jour le noyau et qu'il inclut des changements de rupture, vous venez peut-être de casser 40% du Web. Donc GraphQL est une spécification, cela n'a rien à voir avec WordPress non plus.

Droite. Et donc la spécification GraphQL continue d'évoluer. Et comme cela continue d'évoluer, nous voulons suivre les dernières et meilleures spécifications GraphQL. Si nous devions fusionner, disons, WPGraphQL dans Core aujourd'hui, et que GraphQL continue d'évoluer, WordPress serait bloqué à l'édition 2022 de GraphQL où le reste du monde est sur la version 2030 ou autre. Pour moi, je pense qu'il pourrait être logique à un moment donné de le faire reconnaître comme WPCLI est comme la façon officielle de faire X chose.

Par exemple, vous pouvez créer votre propre client CLI pour WordPress, mais il est en quelque sorte reconnu par la communauté que WPCLI est la chose officielle. Cela ne fait pas partie de WordPress Core mais il est reconnu par la WordPress Foundation et la plupart de la communauté WordPress comme la chose officielle. Il peut donc être agréable à un moment donné qu'un WPGraphQL soit reconnu comme tel, comme si vous alliez faire du WordPress sans tête, faites-le de cette façon.

Ça va toujours rester un plugin. C'est ma pensée. Il pourrait y avoir un moment où le GraphQL semble parfait et il n'est pas vraiment itéré et peut-être qu'à ce moment-là nous le considérons. Mais pour le moment, il y a des choses à venir dans la spécification GraphQL qui entraîneront des changements avec rupture dans l'API.

Donc, le faire en tant que plugin pour moi a toujours du sens.

DP : Tout à fait. Et oui, vous avez mentionné WPCLI et je n'arrête pas d'oublier, comme eux, ils ont juste l'impression que cela fait partie du noyau. Quoi qu'il en soit, c'est comme officiel. Alors oui, c'est comme, oh oui, c'est comme cette chose indépendante, tout comme WPGraphQL en ce moment.

C'est une bonne analogie. Alors je vais, je vais conclure ici. C'était vraiment génial de discuter avec vous deux. Si les auditeurs souhaitent suivre l'un de vous, vous pouvez suivre @JasonBahl et @ChrisWeigman. Nous mettrons les poignées Twitter dans la description de l'émission si nous le pouvons. Vous avez écouté Press This, un podcast de la communauté WordPress sur WMR.

Dans l'épisode de la semaine prochaine, nous aurons Anne McCarthy, une agente de liaison produit chez Automatic, qui parlera des changements apportés à l'édition du site et à la 6.1 et de ce qui se passe avec la 6.2. Merci encore d'avoir écouté Press This.

Vous pouvez suivre mes aventures avec le magazine Torque sur Twitter @thetorquemag ou vous pouvez aller sur torquemag.io où nous contribuons chaque jour à des tutoriels, des vidéos et des interviews comme celle-ci. Alors consultez torquemag.io ou suivez-nous sur Twitter. Vous pouvez vous abonner à Press This sur Red Circle, iTunes, Spotify, ou vous pouvez le télécharger directement sur wmr.fm chaque semaine. Je suis votre hôte Doctor Popular Je soutiens la communauté WordPress grâce à mon rôle chez WP Engine. Et j'adore mettre en lumière les membres de la communauté chaque semaine sur Press This.