Apăsați pe aceasta: WPGraphQL și Faust.js

Bun venit la Press This, podcastul comunității WordPress de la WMR. Fiecare episod prezintă invitați din întreaga comunitate și discuții despre cele mai mari probleme cu care se confruntă dezvoltatorii WordPress. Următoarea este o transcriere a înregistrării originale.

Produs de RedCircle

Doc Pop : Ascultați Press This, un podcast comunitar WordPress pe WMR. În fiecare săptămână, punem în evidență membrii comunității WordPress. Sunt gazda ta, doctore Pop. Sprijin comunitatea WordPress prin rolul meu la WP Engine și prin contribuțiile mele pe TorqueMag.Io, unde pot să fac podcasturi și să desenez desene animate și videoclipuri tutoriale. Verifica asta.

Vă puteți abona la Press This pe Red Circle, iTunes, Spotify sau puteți descărca episoade direct de pe wmr.fm.

În acest episod din Press This, vorbim despre Headless WordPress, GraphQL și Faust.js. Cum pot fi utilizate aceste instrumente împreună și ce fel de cost ar putea fi asociat cu WordPress Headless. Vom încerca să ne aprofundăm în acest sens și am doi invitați grozavi care mi se alătură astăzi, îl am pe Jason Bahl, inginer principal de software la WP Engine cu sediul în Denver, Colorado, unde menține WPGraphQL . Și îl avem pe Chris Weigman, un manager de inginerie care lucrează pe Faust.js. De obicei, îmi place să încep aceste spectacole întrebând oaspeții despre poveștile lor despre originea WordPress, dar m-am gândit să schimb puțin lucrurile aici.

Jason, poți să ne spui ce este WPgraphQL și care este povestea lui WordPress Origin.

Jason Bahl: Da, WPGraphQL este un plugin gratuit pentru WordPress cu sursă deschisă, care aduce un API GraphQL pe site-ul tău WordPress, iar GraphQL este un limbaj de interogare grafică. Prin urmare, permite dezvoltatorilor să introducă conținut în și din WordPress folosind limbajul de interogare grafic.

Și plugin-ul a apărut, lucram la un ziar în urmă cu câțiva ani și făceam multă sindicare de conținut. Aveam o rețea de aproximativ 54 de site-uri în toată SUA și trebuia să mutăm conținutul dintr-o parte în alta. Știți, atunci când o știre era publicată, diferite ziare se puteau abona la conținut din alte ziare.

Și așa că, atunci când au avut loc diverse evenimente, trebuia să mutăm datele în această rețea și folosim API-ul REST WordPress pentru a face o mare parte din această mișcare a datelor. Și aveam unele probleme cu asta din punct de vedere tehnic și ca performanța reală din punct de vedere tehnic, dar și experiența dezvoltatorului. Am aflat despre GraphQL, limbajul actual de interogare a graficelor, care a fost deschis de Facebook în 2015.

Așa că am găsit această tehnologie, am făcut niște prototipuri, le-am prezentat-o ​​colegilor și apoi am migrat sindicarea de contacte de la REST la GraphQL. Și apoi am continuat să lucrez la proiect ca un proiect comunitar, știind că framework-urile JavaScript deveneau lucrul fierbinte și probabil că acesta ar fi cazul de utilizare principal al utilizării GraphQL, cum ar fi comunicarea server-server nu este cazul principal de utilizare. Ne-a rezolvat nevoile, dar am văzut o viziune mai mare pentru el, așa că am continuat să lucrez la el ca un proiect open source pentru comunitate.

DP: Ei bine, cool. Chris, poți să ne spui o poveste similară despre ce este Faust și cum a apărut?

Chris Weigman: Sigur că Faust este, recent, chiar în această săptămână, lansat oficial publicului, relansat în cadrul public pentru construirea de site-uri WordPress Headless folosind GraphQL. Dezvoltarea a început în 2020 și a fost un fel de proiect neoficial al WP Engine, iar acesta este al treilea pivot major.

Au început-o ca o extensie a DevRel, au început să-l facă puțin mai oficial și s-au transformat în ceva numit GQty și într-o mentalitate foarte JavaScript, primul dezvoltator. Și apoi, când am preluat echipa la 1 decembrie a anului trecut, ne-am dat seama că nu asta era piața noastră țintă.

Ar fi trebuit să dezvoltăm pentru dezvoltatorii WordPress. Așa că am început să-l reconstruim din nou și, în sfârșit, a putut fi relansat recent.

DP: Jason, ai scris recent pe Twitter că ai lansat noul wpgraphql.com pe Faust.js. Site-ul anterior, cred că era WordPress fără cap. Ne poți spune despre această schimbare pe care ai făcut-o și știi ce îmbunătățiri spui?

JB: Da. Deci, wpgraphql.com, a fost un site fără cap de mulți ani. Deci folosesc mai multe surse de date. Deci am o mulțime de conținut în WordPress, ca și cum postările de blog sunt toate în WordPress.

O parte din documentație există și în WordPress. Și apoi există documentație în fișierele markdown din depozitul GitHub. Pentru cea mai lungă perioadă de timp am folosit Gatsby, poate de vreo trei ani, am folosit Gatsby, care este un cadru JavaScript care, la bază, are stratul său de date în care puteți extrage date din mai multe surse.

Așa că foloseam asta, extragea date din GitHub, extragea date din WordPress folosind și WPGraphQL și îmi permitea să folosesc acele date pentru a-mi construi șabloanele. Așa că l-am folosit de câțiva ani. Există o mulțime de puncte dureroase cu stratul de date din care am vrut să ies.

Așa că am vrut să folosesc Next, pe care este construit Faust. Este un alt cadru JavaScript, dar au lipsit multe piese, cred. În continuare, și multe dintre aceste cadre JavaScript au ideea că cadrele dumneavoastră frontale ar trebui să definească toată rutarea, nu? Dar dacă utilizați un CMS, CMS-ul dvs. definește rutarea.

Și deci există o mulțime de probleme tehnice de a face ca aceste lucruri să se joace frumos, în cazul în care front-end-ul tău are o părere despre ceva și back-end-ul tău are o părere diferită. Deci, una dintre problemele pe care încercam să le rezolv este să-mi fac front-end-ul să recunoască că o anumită adresă URL este un anumit tip de lucru și apoi să redea un șablon care a reprezentat acel lucru.

Ca și cum o postare de blog ar avea un alt șablon decât un document sau o arhivă de utilizator sau orice altceva. Așa că am vrut ca front-end-ul meu să aibă capacitatea de a trimite o adresă URL către CMS, de a obține date înapoi, dar să înțeleagă ce șablon să returnez. În WordPress se numește ierarhie de șabloane. Și așa că, când echipa Faust a reușit să rezolve problema, am spus, naiba, da, mă mut la Faust.

Deci, da, sunt capabil să iau unele dintre conceptele care există în WordPress de bază, cum ar fi tematica PHP și să le folosesc fără cap, astfel încât să pot folosi beneficiile React și orice JavaScript pe care vreau să-l folosesc pe front-end pentru a-mi șablon. site, dar încă concepte familiare din lumea WordPress.

DP: Chris, ai menționat că Faust a suferit niște schimbări. Care au fost acele schimbări? Știi, Jason le-a menționat. Care au fost unele dintre acele schimbări care au făcut posibilă această îmbunătățire?

CW: Este întotdeauna concentrat pe WPGraphQL. Orice altceva era cu adevărat problema. De exemplu, ultima versiune majoră a lui Faust a folosit o bibliotecă de dedesubt pentru a interacționa cu GraphQL numită GQty, care pe hârtie suna foarte bine. Ideea provenind de la echipa Faust de la acea vreme că, să rezumam, oamenii nu ar trebui să știe cum să construiască aceste interogări complexe.

Acest cadru ar trebui să abstractizeze asta pentru tine. Pe hârtie, arăta foarte bine, în practică, din cauza tuturor complexităților datelor WordPress. Chiar și un singur tip de post poate avea atât de multe variații. Poate amestecați asta cu categoria, poate toate lucrurile diferite. GQty pur și simplu nu l-a putut alimenta.

În plus, când a fost construit cu versiunea GQty, nu a fost acordată nicio atenție problemei de rutare despre care vorbea Jason. Cine se ocupă de rutare? WordPress vrea să-și gestioneze rutarea în funcție de conținutul, este un sistem de gestionare a conținutului, așa că toate rutarea și WordPress se bazează în mare parte pe conținut.

Next.js este un cadru frontend, deci se bazează toată rutarea, este o paradigmă complet diferită pentru modul în care se bazează rutarea. Ceea ce ar putea fi /Blog on Next poate să nu aibă nimic de-a face cu conținutul unui blog. Va ajunge la un set de șabloane. Va fi o parte a aplicației care poate construi un blog.

În timp ce /Blog pe WordPress ar putea însemna foarte bine, acestea sunt toate postările de blog. Și acea paradigmă atunci când construiești, dacă vrei să faci din WordPress un frontend foarte solid sau un CMS capabil fără cap, a trebuit să ne ocupăm de rutarea respectivă. O altă schimbare când am făcut asta, așa cum am spus cu versiunea GQty, scopul nostru era dezvoltatorii JavaScript care au trebuit să folosească WordPress, ceea ce pare nobil până când îți dai seama că acesta este WP Engine.

Avem de-a face cu agenții care au construit WordPress de ani de zile, care acum, din diverse motive în care putem intra mai târziu, trec într-un lucru fără cap. Ei știu cum să facă dezvoltarea WordPress. Ei înțeleg cum funcționează rutările șabloanelor WordPress și cum funcționează șabloanele, lucruri de genul acesta.

Trebuie să aducem aceste funcții înainte, astfel încât GraphQL să poată fi utilizat mai ușor de dezvoltatorii WordPress. Și acesta este scopul lui Faust aici. Ierarhia șablonului, pur și simplu reconstruiește ceea ce a făcut WordPress. Acum, dacă doriți să utilizați rutarea Next, există modalități de a o înlocui în aplicație, astfel încât să nu pierdeți nimic.

Dar pentru cei care folosesc WordPress-urile ca un adevărat sistem de management al conținutului, capabil să direcționeze conținutul prin managementul conținutului, atunci Faust se va descurca mult mai bine pentru tine? Are sens?

DP : Da. Absolut. Știi, cred că este un loc bun pentru a lua o pauză rapidă aici. Ascultați Press This, un podcast al comunității WordPress cu Chris Weigman și Jason Bahl. Vom reveni să vorbim despre WordPress și fără cap. Rămâneţi aproape.

DP: Ne-am întors cu Press This. Și știi, Chris, chiar înainte de acea pauză ai menționat ceva, ai menționat că tot mai multe companii intră în fără cap și știu că WP Engine a făcut o mulțime de cercetări pentru a arăta că așa este. Mă întreb într-un fel, fără cap are cu siguranță o reputație ca ceva, cred că întreprindere, când cred că fără cap, gândesc corect. Asta este fără cap? Este doar un instrument pentru întreprinderi sau este un instrument pe care îl vor folosi mai multe site-uri?

CW: Da și nu. În mare parte fără cap, mai ales cu WordPress în acest moment, complexitatea implicată înseamnă că probabil aveți o echipă completă care construiește ceea ce aveți nevoie.

Acesta nu este cineva care folosește numai WordPress din cutie, că vrei doar blogul tău personal. Poate face asta, dar este o ridicare mult mai grea până acum pentru a putea face asta. La fel cu Contentful, la fel cu toate celelalte CMS-uri. Dacă ți-ai dorit doar ceva simplu, ceva care, știi, tipul de conținut care a fost pe web de ani de zile, fără cap este, probabil, mai multă muncă decât vrei să te ocupi până acum.

Este strict întreprindere? Uite, nu. Gatsby lucrează la această problemă de ani de zile. Aveți un alt podcast mai târziu, Doc with Mastodon. Este o comunitate în care sunt implicat de câțiva ani. Cei mai mulți oameni din asta folosesc variante de CMS-uri fără cap, în special Gatsby, dar există și Hugo. Există tot felul de diferite, acest tip de tehnologie la nivel de bază.

Așadar, ajungi cu utilizatorii de la bază și ajungi cu utilizatorii de întreprindere pentru site-uri grele, în timp ce WordPress în mod tradițional pare să se încadreze cu toți ceilalți între ele. Este persoana care nu vrea să se ocupe de fișiere și coduri de reducere, așa cum ar face un utilizator Gatsby, sau știi, oricum, doar Gatsby din cutie.

Dar nici nu este cineva care are o întreagă echipă de 10 care își construiesc brandingul personal sau blogul personal. Acest lucru scoate WordPress din acel mijloc și îl extinde la ambele capete foarte ușor. Acum puteți construi cu ușurință între GraphQL, aveți toate datele și aveți un set din ce în ce mai mare de moduri de a gestiona acele date.

Și Faust face mult mai ușor să folosești asta și ceva pe care îl poți construi într-o zi în loc de o lună.

DP: Jason, Chris a menționat ceva despre care mi-ar plăcea să aud părerile tale, am auzit că acest lucru nu este grozav pentru echipe mici, bloggeri mici ca mine, ceea ce, evident, are sens, nu am nevoie de un WordPress fără cap, dar , Cred că ceea ce mă întreb este că WordPress fără cap mă va costa mai mult pentru că va trebui să am un dezvoltator iOS și un dezvoltator WordPress? Este mai scump sau este cumva mai rentabil?

JB: Probabil depinde de ceea ce produci, cred. Dacă faci, așa cum ai menționat iOS, dacă faci o aplicație mobilă nativă, vreau să spun că există, în mod evident, costuri asociate cu asta, indiferent și nu există chiar o modalitate bună de a face asta dacă folosești date de la WordPress, alte decât să o faci fără cap, pentru că știi, o aplicație nativă nu redă php, așa că ar trebui să faci asta fără cap.

Dar în măsura în care construiești pentru web chiar acum în WordPress tradițional, poți să găsești o temă, știi fie o temă gratuită, fie să găsești o temă pe o piață, să o descarci, să o instalezi și ești am plecat la curse. Majoritatea oamenilor o vor personaliza într-un fel sau altul.

Deci, vei avea costuri de dezvoltator de obicei, indiferent dacă faci asta tu însuți sau altcineva. Unul dintre lucrurile cu WordPress fără cap, care diferă de tematica tradițională PHP, este că, de exemplu, când am lansat noul wpgraphql.com, am putut folosi aceeași instanță de WordPress care alimenta site-ul meu Gatsby.

Primesc datele, ieseau datele și intrau pe site-ul Gatsby, am putut să continui publicarea conținutului în CMS în timp ce dezvolt următorul meu frontend pentru acesta în același timp. În dezvoltarea WordPress tradițională, de obicei, trebuie să migrați site-ul într-un mediu de pregătire.

Activați o temă nouă în acel mediu, construiți-vă tema acolo, tratați-vă cu un fel de perioadă de înghețare a conținutului în care le spuneți creatorilor de conținut: „Hei, astăzi nu puteți publica conținut pentru că vom migra și apoi vom” Vom seta noua instanță WordPress, instanța live.” Și apoi trebuie să vă conectați acolo și să începeți să vă faceți conținutul corect.

WordPress fără cap, am reușit să-mi reconstruiesc site-ul pe o stivă de front-end complet diferită, fără a perturba nimic în instanța mea reală WordPress, este o separare a datelor și a prezentării, nu? Așa că aș putea merge, dacă aș vrea să explorez următoarea tehnologie fierbinte mâine, așa cum aș putea să-mi pun ochii pe Svelte în loc de pe Next, și nu ar trebui să schimb nimic în WordPress.

Deci, în unele cazuri, poate fi de fapt mai ieftin, deoarece întregul proces de a porni un alt server, de a determina echipa dvs. să nu mai scrie conținut și apoi să se mute într-o altă instanță de WordPress și apoi să înceapă să publice acolo, să facă migrări Delta, lucruri de genul ăsta, are si un cost.

Un alt lucru care este și interesant este că ecosistemul JavaScript este într-adevăr expediat. Unitatea comună, în opinia mea, unul dintre motivele comune pentru deplasarea fără cap este arhitecturile bazate pe componente. Și există tot felul de biblioteci de componente în ecosistemul React și VUE, care vă permit să reutilizați componente în cadrul proiectelor.

Astfel, agențiile pot construi componente comune pe care le folosesc în proiecte și le pot actualiza pe acelea într-un loc central, dar apoi le pot instala în mai multe proiecte. Cu WordPress, acest lucru nu este la fel de ușor, deoarece părțile șablonului PHP și WordPress sunt de obicei foarte strâns legate de proiectul căruia îi aparțin.

În cazul în care cu headless puteți avea un pachet MPM care are acele componente și mai multe proiecte pot actualiza acel pachet și beneficiați toate în același timp cu mai puțin efort. Așa că, în acest moment, aș spune că probabil este mai costisitor și mai mult de muncă, dar cred că instrumente precum Faust, care nu existau până de curând, reduc efortul general necesar pentru a construi fără cap.

Și cred că într-un viitor nu prea îndepărtat, ar putea fi mai ieftin să construiești fără cap decât fără cap.

DP: Chris, ai vrut să adaugi ceva la ce ar trebui să se gândească agențiile în ceea ce privește costurile WordPress fără cap?

CW: Cred că Jason a dat cu adevărat cuiul în cap.

Și acesta este un lucru care îmi place la WPGraphQL este că echipa mea lucrează în continuare la extinderea WordPress în această direcție cu ceea ce numim, titlul nostru de lucru este React Gutenberg Bridge, dar este o problemă și în WordPress. Cum reutilizați aceste componente? Nu vreau să folosesc cuvântul doar componentă, pentru că nu se aplică pe partea WordPress în același mod în care se aplică pe partea JavaScript, nu?

Dar cum reutilizam codul în cadrul proiectelor, fără cap sau altfel, cu WordPress și fără cap permite acest lucru. Dar cred că este sigur să spun că bloggerii obișnuiți încearcă doar să-și scoată blogurile gastronomice, probabil că nu se ocupă singuri de asta. Este foarte mult o problemă de agenție. Asta costa mai mult?

Poate, poate nu, dar acolo se complică când vorbim despre unde este costul în asta? Pentru că sunt diferite tipuri de modul în care doriți să utilizați datele.

DP: Da, absolut. Știi, venind din mediul ziarului, lucrând la Weeklys în Twin Cities și în Nashville, Jason, îmi pot imagina cum ar fi fost să le spui celor 56 de ziare ale tale să nu publice o zi.

Nicio veste astăzi, pentru că actualizăm site-ul.

JB: Da. Și vreau să spun, am trecut prin acele perioade, nu? La fel ca atunci când am fost angajat acolo, ei nu erau pe WordPress și, așadar, o parte din munca mea era să-i aduc de la un alt sistem la WordPress. Deci, cu siguranță, au existat zile în care a fost ca, în regulă, este difuzat în ziua WordPress. Încetează ce faci. Dreapta.

Deci, cu siguranță au existat perioade de genul ăsta sau a trebuit să ne confruntăm și cu acea problemă de genul, bine, ei publicau pe vechiul sistem până aseară la miezul nopții, dar aveam WordPress gata să funcționeze cu două zile înainte. Așa că acum trebuie să facem ca o migrare Delta și să ne asigurăm că toate datele sunt încă sincronizate, astfel încât, știți, există cu siguranță un cost tehnic și uman pentru acele procese.

DP: Da. Și mă gândesc că sunt multe, atunci când încă utilizați WordPress, încă obțineți acel ecosistem pe care îl puteți obține cu această economie de costuri. Nu trebuie să construiți instrumentele SEO.

Puteți folosi pluginul Yoast SEO sau orice altceva. Chiar dacă sunteți un site Headless, presupun că majoritatea pluginurilor vor funcționa în continuare atâta timp cât nu sunt orientate în față.

JB: Da. Acesta este de fapt un lucru interesant. Deci noul Faust este construit cu o arhitectură plugin în sine. Deci, de la cutie, va veni cu un client, folosește clientul Apollo, astfel încât să puteți prelua date de la WPGraphQL, puteți obține datele dvs. WordPress, dar puteți crea plugin-uri astfel încât, să presupunem că ați făcut, ca dvs. menționat, instalați Yoast SEO pe site-ul dvs. WordPress.

Puteți adăuga un plugin Yoast. Nu există încă, dar poate în curând. Ai putea adăuga un plugin Yoast pentru Faust pe front-end care știe ce să facă cu acele date, nu? Deci va exista posibilitatea pentru oameni, pe unii i-am putea produce și sprijini, dar unii, comunitatea poate produce și susține pluginuri și pentru partea Faust a lucrurilor, astfel încât, cu o singură linie de cod, puteți adăuga acest plugin obțineți funcționalități precum Yoast pentru partea frontală fără cap.

Este ceva despre care nu cred că niciun alt frontend fără cap are conceptul în același mod în care îl abordează Faust. Deci cred că pluginul, cred că este un alt lucru familiar pentru dezvoltatorii WordPress. Aduce concepte familiare de la WordPress, dar le face legătura cu stiva modernă de front-end JavaScript.

DP: ăsta e un, ăsta este un loc bun pentru o ultimă pauză aici pe Press This, iar când ne vom întoarce, vom încheia conversația cu Chris Weigman și Jason Bahl. Rămâneţi aproape.

DP: Ascultați Press This, un podcast al comunității WordPress. Sunt gazda ta, doctore Pop. Astăzi vorbim despre WPGraphQL, Faust și despre cum vă puteți alimenta site-ul WordPress fără cap. Chiar înainte de pauză, vorbeam despre Faust și pluginuri și o să vă pun câteva întrebări aleatorii și să văd dacă există răspunsuri bune aici.

Dar Chris, mă întreb cu, cu Faust, dacă există vreun potențial, știu că este o platformă fără cap, dar există vreun potențial pentru o temă Faust WordPress care să te facă cel puțin să te configurezi cu așa ceva, iată pluginurile de care aveți nevoie și iată doar un fel de tot ce este disponibil.

CW: Absolut. De fapt, îl avem deja. Ne referim la el ca Blueprints pentru că funcționează foarte mult cu Local. Majoritatea oamenilor vor face un fel de ajustări la aceste lucruri înainte de a le lansa pe o platformă precum WP Engine. Așa că am împrumutat numele localului Blueprints.

Pentru noul Faust avem unul numit Portofoliu, care este practic o temă de portofoliu complet și lucrăm doar la o schelă foarte goală pe care agențiile îl pot folosi. Odată ce ați înțeles lucrurile, probabil că veți dori să personalizați totul singur. Așadar, o schelă ar fi cele mai bune practici pentru proiect, învârte-l și apoi poți să-ți faci toate lucrurile cu el.

Pe termen lung, am vorbit foarte mult despre un magazin tematic fără cap, ala Blueprints. Nu avem forță de muncă, așa că este puțin mai departe, dar este ceva absolut pe care îl luăm în considerare și ne-ar plăcea să se întâmple.

DP: Da, e grozav de gândit. Acesta este un cu totul alt tip de ecosistem în care să intri.

Și știi, Jason, ți-am mai intervievat și sunt sigur că această întrebare apare tot timpul, dar de fiecare dată când aud despre WPGraphQL, mă gândesc că seamănă foarte mult cu ceea ce face API-ul REST. De fapt, asta pare mult mai puternic decât ceea ce face REST API și REST API face parte din nucleu și mă întreb doar, crezi că WPGraphQL ar trebui să facă parte din WordPress Core?

JB: Poate într-o zi. Nu cred că suntem încă acolo. Când lucrurile se îmbină în WordPress Core, probabil cu excepția lui Gutenberg, inovația se oprește. API-ul REST, de exemplu, există încă o eroare pe care o subliniez oamenilor care încă mai există din 2016. Așa că vreau să spun, când lucrurile intră în nucleu, adaugi un set de funcții la 40% din web și deci efectuarea modificărilor trebuie făcută într-un ritm mult mai lent, în cazul în care, dacă este un plugin, îi puteți lăsa pe oameni să opteze pentru versiunea la care doresc să opteze și puteți repeta mult mai rapid, deoarece ei pot alege ce versiune funcționează cel mai bine pentru proiectul lor.

Unde în nucleu, dacă actualizați nucleul și include schimbarea ruptură, este posibil să fi spart doar 40 la sută din web. Deci GraphQL este o specificație, nu are nimic de-a face și cu WordPress.

Dreapta. Și astfel, specificația GraphQL este încă în evoluție. Și pe măsură ce aceasta continuă să evolueze, vrem să ținem pasul cu cele mai recente și mai bune specificații GraphQL. Dacă ar fi să îmbinăm, să spunem, WPGraphQL în Core astăzi, iar GraphQL continuă să evolueze, WordPress ar fi blocat la ediția din 2022 a GraphQL, unde restul lumii este pe versiunea 2030 sau orice altceva. Pentru mine, cred că ar putea avea sens, la un moment dat, să fie recunoscut ca WPCLI ca modalitatea oficială de a face ceva X.

De parcă ai putea să-ți construiești propriul client CLI pentru WordPress, dar comunitatea a recunoscut că WPCLI este lucrul oficial. Nu face parte din WordPress Core, dar este recunoscut de Fundația WordPress și de majoritatea comunității WordPress ca lucru oficial. Așa că ar putea fi frumos la un moment dat ca un WPGraphQL să fie recunoscut așa cum este, ca dacă ai de gând să faci WordPress fără cap, fă-o astfel.

În continuare va rămâne un plugin. Acesta este gândul meu. S-ar putea să existe un moment în care GraphQL se simte perfect și nu este cu adevărat repetat și poate că în acel moment îl luăm în considerare. Dar, în acest moment, sunt lucruri care vin la specificația GraphQL care vor face ca API-ul să aibă modificări nerespective.

Așa că să-l fac ca un plugin pentru mine încă mai are sens.

DP: Chiar mai departe. Și da, ați menționat WPCLI și tot uit, de parcă ei, pur și simplu simt că face parte din nucleu. Orice simt, este ca oficial. Așa că da, este ca și cum, oh, da, este ca acest lucru independent, la fel cum este WPGraphQL în acest moment.

E o analogie bună. Deci, voi încheia aici. A fost foarte grozav să discutăm cu amândoi. Dacă ascultătorii sunt interesați să vă urmărească pe oricare dintre voi, îi puteți urmări pe @JasonBahl și @ChrisWeigman. Vom pune mânerele Twitter în descrierea emisiunii dacă putem. Ați ascultat Press This, un podcast al comunității WordPress pe WMR.

În episodul de săptămâna viitoare, o vom avea pe Anne McCarthy, un agent de legătură de produs la Automatic, care vorbește despre modificările aduse editării site-ului și 6.1 și despre ce urmează cu 6.2. Vă mulțumim din nou pentru că ați ascultat Press This.

Puteți urmări aventurile mele cu revista Torque pe Twitter @thetorquemag sau puteți accesa torquemag.io unde contribuim zilnic cu tutoriale și videoclipuri și interviuri ca acesta. Așa că accesați torquemag.io sau urmăriți-ne pe Twitter. Vă puteți abona la Press This pe Red Circle, iTunes, Spotify sau îl puteți descărca direct de la wmr.fm în fiecare săptămână. Sunt gazda ta Doctor Popular. Sprijin comunitatea WordPress prin rolul meu la WP Engine. Și îmi place să pun în evidență membrii comunității în fiecare săptămână pe Press This.