Premi questo: WPGraphQL e Faust.js

Benvenuti a Press This, il podcast della community WordPress di WMR. Ogni episodio presenta ospiti provenienti da tutta la comunità e discussioni sui maggiori problemi che devono affrontare gli sviluppatori di WordPress. Quanto segue è una trascrizione della registrazione originale.

Alimentato da RedCircle

Doc Pop : Stai ascoltando Press This, un podcast della community di WordPress su WMR. Ogni settimana mettiamo in luce i membri della community di WordPress. Sono il tuo ospite, Doc Pop. Sostengo la community di WordPress attraverso il mio ruolo in WP Engine e i miei contributi su TorqueMag.Io dove posso fare podcast e disegnare cartoni animati e video tutorial. Verificalo.

Puoi iscriverti a Press This su Red Circle, iTunes, Spotify o puoi scaricare gli episodi direttamente su wmr.fm.

In questo episodio di Press This, stiamo parlando di Headless WordPress, GraphQL e Faust.js. Come questi strumenti possono essere utilizzati insieme e che tipo di costo potrebbe essere associato a Headless WordPress. Cercheremo di immergerci in profondità con questo, e ho due grandi ospiti che si uniscono a me oggi, ho Jason Bahl, un principale ingegnere del software presso WP Engine con sede a Denver, in Colorado, dove mantiene WPGraphQL . E abbiamo Chris Weigman, un responsabile tecnico che lavora su Faust.js. Di solito mi piace iniziare questi spettacoli chiedendo agli ospiti le loro storie sulle origini di WordPress, ma ho pensato di cambiare un po' le cose qui.

Jason, puoi dirci cos'è WPgraphQL e qual è la sua storia su WordPress Origin?

Jason Bahl: Oh sì, WPGraphQL è un plug-in WordPress open source gratuito che porta un'API GraphQL al tuo sito WordPress e GraphQL è un linguaggio di query grafico. Quindi consente agli sviluppatori di ottenere contenuti dentro e fuori da WordPress utilizzando il linguaggio di query grafico.

E il plug-in è nato, lavoravo in un giornale alcuni anni fa e stavamo facendo un sacco di syndication di contenuti. Avevamo una rete di qualcosa come 54 siti e in tutti gli Stati Uniti e avevamo bisogno di spostare i contenuti da una parte all'altra. Sai, quando veniva pubblicata una notizia, diversi giornali potevano abbonarsi ai contenuti di altri giornali.

E così, quando si sono verificati vari eventi, avevamo bisogno di spostare i dati su questa rete e stavamo utilizzando l'API REST di WordPress per eseguire gran parte di quel movimento di dati. E stavamo riscontrando alcuni problemi tecnicamente e come le prestazioni effettive tecnicamente, ma anche l'esperienza dello sviluppatore. Ho scoperto GraphQL, l'attuale linguaggio di query grafico, che è stato reso open source da Facebook nel 2015.

Quindi ho trovato questa tecnologia, ho fatto un po' di prototipazione, l'ho presentata ai miei colleghi e poi abbiamo migrato la nostra syndication dei contatti da REST a GraphQL. E poi ho continuato a lavorare al progetto come progetto comunitario sapendo che i framework JavaScript stavano diventando la cosa più interessante e che probabilmente sarebbe stato il caso d'uso principale dell'utilizzo di GraphQL, come la comunicazione da server a server non è il caso d'uso principale. Ha risolto i nostri bisogni, ma ho visto una visione più ampia, quindi ho continuato a lavorarci come progetto open source per la comunità.

DP: Bene, bene. Chris, puoi raccontarci una storia simile su cos'è Faust e come è nato?

Chris Weigman: Sure Faust è, di recente, proprio questa settimana, rilasciato ufficialmente al pubblico, ripubblicato nel framework pubblico per la creazione di siti WordPress Headless utilizzando GraphQL. Bene, lo sviluppo è iniziato nel 2020, ed era una specie di progetto non ufficiale di WP Engine, e questo è il terzo grande perno.

L'avevano iniziato come un'estensione di DevRel, in un certo senso hanno iniziato a renderlo un po 'più ufficiale e si sono trasformati in qualcosa chiamato GQty e una mentalità molto JavaScript, prima dello sviluppatore. E poi, quando ho rilevato il team il 1° dicembre dello scorso anno, ci siamo resi conto che quello non era il nostro mercato di riferimento.

Avremmo dovuto sviluppare per gli sviluppatori di WordPress. Quindi abbiamo iniziato a ricostruirlo di nuovo, e finalmente è stato possibile ripubblicarlo di recente.

DP: Jason, hai recentemente twittato di aver lanciato il nuovo wpgraphql.com su Faust.js. Il sito precedente, credo fosse WordPress headless. Puoi solo parlarci di questo cambiamento che hai fatto e sai, quali miglioramenti stai dicendo?

JB: Sì. Quindi wpgraphql.com è stato un sito senza testa per molti anni. Quindi sto usando più fonti di dati. Quindi ho molti contenuti in WordPress, come i post del blog sono tutti in WordPress.

Parte della documentazione esiste anche in WordPress. E poi esiste della documentazione nei file markdown nel repository GitHub. Per molto tempo ho utilizzato Gatsby, forse per circa tre anni, ho utilizzato Gatsby, che è un framework JavaScript che al suo interno ha il suo livello di dati in cui è possibile estrarre dati da più fonti.

Quindi lo stavo usando, estraeva i dati da GitHub, estraeva i dati da WordPress usando anche WPGraphQL e mi permetteva di usare quei dati per costruire i miei modelli. Quindi l'ho usato per alcuni anni. Ci sono molti punti deboli con il livello dati da cui volevo uscire.

Quindi ho voluto usare Next, che è ciò su cui è costruito Faust. È un altro framework JavaScript, ma c'erano molti pezzi mancanti, immagino. Successivamente, e molti di questi framework JavaScript hanno l'idea che i tuoi framework front-end dovrebbero definire tutto il routing, giusto? Ma se utilizzi un CMS, il tuo CMS definisce il routing.

E quindi ci sono molti problemi tecnici per far funzionare bene queste cose, dove il tuo front-end ha un'opinione su qualcosa e il tuo back-end ha un'opinione diversa. Quindi, come se uno dei problemi che stavo cercando di risolvere fosse far riconoscere al mio front-end che un URL specifico era un tipo specifico di cosa, e quindi rendere un modello che rappresentava quella cosa.

Come un post sul blog ha un modello diverso da un documento o un archivio utente o altro. Quindi volevo che il mio front-end avesse la possibilità di inviare un URL al CMS, recuperare i dati, ma capire quale modello restituire. In WordPress si chiama gerarchia dei modelli. E così quando il team di Faust è riuscito a risolvere il problema, ho pensato, diamine sì, mi trasferisco a Faust.

Quindi, sì, sono in grado di prendere alcuni dei concetti che esistono nel core di WordPress, come il tema PHP e usarli in headless in modo da poter utilizzare i vantaggi di React e qualsiasi JavaScript voglio utilizzare sul front-end per modellare il mio site, ma ancora concetti familiari dal mondo WordPress.

DP: Chris, stavi dicendo che Faust ha subito dei cambiamenti. Quali erano questi cambiamenti? Sai, Jason li stava menzionando. Quali sono stati alcuni di quei cambiamenti che hanno reso possibile questo miglioramento?

CW: Si concentra sempre su WPGraphQL. Era tutto il resto che era davvero il problema. Ad esempio, l'ultima versione principale di Faust utilizzava una libreria sottostante per interagire con GraphQL chiamata GQty, che sulla carta suonava davvero bene. L'idea era del team Faust all'epoca che, astrattiamo, le persone non dovrebbero aver bisogno di sapere come costruire queste query complesse.

Questo framework dovrebbe astrarlo per te. Sulla carta sembrava davvero buono, in pratica a causa di tutte le complessità dei dati di WordPress. Anche un singolo tipo di post può avere così tante varianti. Forse lo stai mescolando con la categoria, forse tutte le cose diverse. GQty non è riuscito ad alimentarlo.

Inoltre, quando è stato creato con la versione GQty, non è stata prestata alcuna attenzione al problema di routing di cui parlava Jason. Chi gestisce l'instradamento? WordPress vuole gestire il suo routing in base al contenuto, è un sistema di gestione dei contenuti, quindi tutto il routing e WordPress è in gran parte basato sul contenuto.

Next.js è un framework frontend, quindi tutto il routing è basato su, è un paradigma completamente diverso su come si basa il routing. Quello che potrebbe essere /Blog on Next potrebbe non avere nulla a che fare con il contenuto di un blog. Sta andando a una serie di modelli. Farà parte dell'applicazione che può creare un blog.

Considerando che /Blog su WordPress potrebbe benissimo significare, questi sono tutti i post del blog. E quel paradigma durante la creazione, se vuoi rendere WordPress un frontend molto solido o un CMS senza testa, abbiamo dovuto occuparci di quel routing. Un altro cambiamento quando l'abbiamo fatto, come ho detto con la versione GQty, il nostro obiettivo erano gli sviluppatori JavaScript che dovevano usare WordPress, il che sembra nobile finché non ti rendi conto che si tratta di WP Engine.

Abbiamo a che fare con agenzie che hanno costruito su WordPress per anni, che ora per vari motivi di cui parleremo in seguito, si stanno muovendo verso una cosa senza testa. Sanno come sviluppare WordPress. Capiscono come funzionano i percorsi dei modelli di WordPress e i modelli, cose del genere.

Dobbiamo portare avanti queste funzionalità, in modo che GraphQL possa essere utilizzato più facilmente dagli sviluppatori di WordPress. Ed è questo l'obiettivo di Faust qui. La gerarchia dei modelli ricostruisce semplicemente ciò che ha fatto WordPress. Ora, se vuoi utilizzare il routing di Next, ci sono modi per sovrascriverlo nell'app in modo da non perdere nulla.

Ma per le persone che utilizzano WordPress come un vero sistema di gestione dei contenuti, in grado di instradare i contenuti tramite la gestione dei contenuti, allora Faust lo gestirà molto meglio per te? Ha senso?

DP : Sì. Assolutamente. Sai, penso che sia un buon posto per fare una breve pausa qui. Stai ascoltando Press This, un podcast della community di WordPress con Chris Weigman e Jason Bahl. Torneremo a parlare di WordPress e headless. Rimani sintonizzato.

DP: Siamo tornati con Press This. E sai, Chris, proprio prima di quella pausa hai menzionato qualcosa, hai menzionato un numero sempre maggiore di aziende che entrano nel senza testa, e so che WP Engine ha fatto molte ricerche per dimostrare che è così. Mi chiedo, senza testa ha sicuramente una reputazione come qualcosa, penso all'impresa, quando penso senza testa sto pensando correttamente. È questo ciò che è senza testa? È solo uno strumento per le imprese o è uno strumento che verrà utilizzato da più siti?

CW: Sì e no. In gran parte senza testa, specialmente con WordPress in questo momento, la complessità implicata significa che probabilmente hai un team completo che costruisce ciò di cui hai bisogno.

Questo non è qualcuno che usa WordPress fuori dagli schemi, che vuoi solo il tuo blog personale. Può farlo, ma finora è un sollevamento molto più pesante per poterlo fare. Lo stesso con Contentful, lo stesso con tutti questi altri CMS. Se volevi solo qualcosa di semplice, qualcosa che, sai, il tipo di contenuto che è stato sul web per anni, senza testa è probabilmente più lavoro di quanto tu voglia affrontare finora.

È strettamente aziendale? Guarda, no. Gatsby ha lavorato su questo problema per anni. Hai un altro podcast più tardi, Doc with Mastodon. È una comunità con cui sono stato coinvolto per un certo numero di anni. La maggior parte delle persone utilizza variazioni di CMS senza testa, in particolare Gatsby, ma c'è Hugo. C'è ogni tipo di diverso, quel tipo di tecnologia a livello di base.

Quindi finisci con gli utenti di base e finisci con gli utenti aziendali per i siti pesanti, mentre WordPress tradizionalmente sembra cadere con tutti gli altri nel mezzo. È la persona che non vuole occuparsi di file markdown e codice come potrebbe fare un utente di Gatsby, o sai, solo Gatsby fuori dagli schemi comunque.

Ma non è nemmeno qualcuno che ha un intero team di 10 persone che costruisce il proprio marchio personale o blog personale. Questo porta WordPress fuori da quel mezzo e lo espande ad entrambe le estremità molto facilmente. Ora puoi creare facilmente tra GraphQL, hai tutti i dati e hai una serie sempre crescente di modi per gestirli.

E Faust rende molto più facile l'utilizzo di questo e qualcosa che puoi costruire in un giorno invece che in un mese.

DP: Jason, Chris ha menzionato qualcosa su cui mi piacerebbe sentire i tuoi pensieri, ho sentito che forse non è l'ideale per piccoli team, piccoli blogger come me, il che ovviamente ha senso, non ho bisogno di un WordPress senza testa, ma come , Immagino che quello che mi chiedo sia, WordPress senza testa mi costerà di più perché dovrò avere uno sviluppatore iOS e uno sviluppatore WordPress? È più costoso o è in qualche modo più conveniente?

JB: Probabilmente dipende da cosa stai producendo, immagino. Se stai facendo, come hai menzionato iOS, se stai facendo un'app mobile nativa, voglio dire che ci sono ovviamente dei costi associati a questo a prescindere, e non c'è davvero un buon modo per farlo se stai usando dati da WordPress, altro piuttosto che farlo senza testa, perché sai, un'app nativa non esegue il rendering di php, quindi dovresti farlo senza testa.

Ma per quanto riguarda se stai costruendo per il web in questo momento nel tradizionale WordPress, puoi trovare un tema, conosci un tema gratuito o trova un tema su un mercato, scaricalo, installalo e sei fuori per le gare. La maggior parte delle persone lo personalizzerà in un modo o nell'altro.

Quindi di solito avrai il costo dello sviluppatore, che tu lo faccia o qualcun altro. Una delle cose con WordPress senza testa che differisce dal tradizionale tema PHP, è che, ad esempio, quando ho lanciato il nuovo wpgraphql.com, sono stato in grado di utilizzare la stessa istanza di WordPress che alimentava il mio sito Gatsby.

Sto ricevendo i dati, i dati uscivano ed entravano nel sito di Gatsby, sono stato in grado di continuare a pubblicare contenuti nel CMS sviluppando allo stesso tempo il mio prossimo frontend. Nello sviluppo tradizionale di WordPress, di solito devi migrare il tuo sito in un ambiente di staging.

Attiva un nuovo tema in quell'ambiente, costruisci il tuo tema laggiù, gestisci una sorta di periodo di congelamento dei contenuti in cui dici ai tuoi creatori di contenuti: "Ehi, oggi non puoi pubblicare contenuti perché migreremo e poi ' imposteremo la nuova istanza di WordPress, l'istanza live." E poi devi accedere laggiù e iniziare a fare bene i tuoi contenuti.

Headless WordPress, sono stato in grado di ricostruire il mio sito su uno stack frontend completamente diverso senza interrompere nulla nella mia attuale istanza di WordPress, è una separazione di dati e presentazione, giusto? Quindi potrei andare, se volessi esplorare la prossima tecnologia calda domani, come se potessi mettere gli occhi su Svelte invece di Next, e non dovrei cambiare nulla in WordPress.

Quindi in alcuni casi può effettivamente essere più economico perché l'intero processo di avvio di un altro server, facendo in modo che il tuo team smetta di scrivere contenuti e poi si sposti in un'altra istanza di WordPress, e poi inizi a pubblicare lì, facendo migrazioni Delta, cose del genere, anche quello ha un costo.

Un'altra cosa interessante è che l'ecosistema JavaScript è davvero disponibile. La spinta comune, a mio parere, una delle motivazioni comuni per lo spostamento senza testa sono le architetture basate sui componenti. E ci sono tutti i tipi di librerie di componenti nell'ecosistema React e VUE, che ti consentono di riutilizzare i componenti tra i progetti.

E così le agenzie possono creare componenti comuni che usano nei progetti e possono aggiornarli in una posizione centrale, ma poi installarli in più progetti. Con WordPress, non è così facile perché le parti del tuo modello PHP e WordPress sono solitamente strettamente legate al progetto a cui appartengono.

Dove con headless puoi avere un pacchetto MPM che ha quei componenti e più progetti possono aggiornare quel pacchetto e trarne vantaggio tutti allo stesso tempo con meno sforzo. Quindi penso che al momento, direi che probabilmente è più costoso e richiede più lavoro, ma penso che strumenti come Faust, che non esistevano fino a poco tempo fa, stiano riducendo lo sforzo complessivo richiesto per costruire senza testa.

E penso che in un futuro non troppo lontano, potrebbe essere più economico costruire senza testa piuttosto che senza testa.

DP: Chris, avevi qualcosa che volevi aggiungere a ciò a cui le agenzie potrebbero aver bisogno di pensare in termini di costi di WordPress headless?

CW: Penso che Jason abbia davvero colpito nel segno.

E questa è una cosa che mi piace di WPGraphQL è che il mio team sta lavorando per estendere WordPress quella direzione con ciò che chiamiamo, il nostro titolo provvisorio è React Gutenberg Bridge, ma è un problema anche in WordPress. Come si riutilizzano questi componenti? Non voglio usare la parola solo componente, perché non si applica al lato WordPress nello stesso modo in cui si applica al lato JavaScript, giusto?

Ma come riutilizziamo il codice nei progetti, headless o meno con WordPress e headless lo abilita. Ma penso che sia corretto affermare che il blogger medio sta solo cercando di pubblicare i propri blog di buongustai, probabilmente non se ne occupa da solo. Questo è molto un problema di agenzia. È più costoso?

Forse, forse no, ma è qui che diventa complicato quando parliamo di dov'è il costo in questo? Perché sono diversi tipi di come si desidera utilizzare i dati.

DP: Sì, assolutamente. Sai, provenendo da un giornale, lavorando su Weeklys nelle Twin Cities ea Nashville, Jason, posso immaginare come sarebbe stato dire ai tuoi 56 giornali di non pubblicare per un giorno.

Nessuna novità oggi, perché stiamo aggiornando il sito.

JB: Sì. E voglio dire, abbiamo attraversato quei periodi, giusto? Come quando sono stato assunto lì, non erano su WordPress e quindi parte del mio lavoro consisteva nel portarli da un altro sistema a WordPress. Quindi ci sono sicuramente stati giorni in cui è stato come dire, va bene, è andato in diretta il giorno di WordPress. Ferma quello che stai facendo. Destra.

Quindi ci sono stati sicuramente periodi del genere o abbiamo anche dovuto affrontare quel problema del tipo, ok, stavano pubblicando sul vecchio sistema fino a mezzanotte di ieri sera, ma avevamo WordPress pronto per partire due giorni prima. Quindi ora dobbiamo fare come una migrazione Delta e assicurarci che tutti i dati siano ancora sincronizzati in modo che, sai, ci siano sicuramente costi tecnici e umani per quei processi.

DP: Sì. E penso che ci sia anche molto, quando usi ancora WordPress, ottieni ancora quell'ecosistema che puoi ottenere questo risparmio sui costi. Non devi costruire gli strumenti SEO.

Puoi usare il plugin Yoast SEO o qualsiasi altra cosa. Anche se sei un sito Headless, presumo, la maggior parte dei plugin funzionerà comunque fintanto che non sono frontali.

JB: Sì. In realtà è una cosa interessante. Quindi il nuovo Faust è costruito con un'architettura plug-in stessa. Quindi, come fuori dagli schemi, verrà fornito con un client, utilizza il client Apollo in modo che tu possa recuperare i dati da WPGraphQL, puoi ottenere i tuoi dati WordPress, ma puoi creare plug-in in modo che, diciamo che l'hai fatto, come te menzionato, installa Yoast SEO sul tuo sito WordPress.

Puoi aggiungere un plugin Yoast. Non esiste ancora, ma potrebbe presto. Potresti aggiungere un plugin Yoast per Faust sul frontend che sa cosa fare con quei dati, giusto? Quindi ci sarà la possibilità per le persone, alcune che potremmo produrre e supportare, ma alcune, la comunità può produrre e supportare anche plugin per il lato Faust delle cose, in modo che tu con una sola riga di codice, aggiungi questo plugin puoi ottieni funzionalità come Yoast per il tuo front-end headless.

È qualcosa di cui non credo nessun altro frontend senza testa abbia davvero il concetto nello stesso modo in cui Faust lo sta affrontando. Quindi penso che il plugin, penso che sia un'altra cosa familiare per gli sviluppatori di WordPress. Sta portando concetti familiari da WordPress, ma collegandoli con il moderno stack di frontend JavaScript.

DP: questo è un buon posto per un'ultima pausa qui su Press This, e quando torneremo, concluderemo la nostra conversazione con Chris Weigman e Jason Bahl. Rimani sintonizzato.

DP: Stai ascoltando Press This, un podcast della community di WordPress. Sono il tuo ospite, Doc Pop. Oggi parliamo di WPGraphQL, Faust e di come potenziare il tuo sito WordPress headless. Proprio prima della pausa, stavamo parlando di Faust e dei plugin e vi farò alcune domande casuali per vedere se ci sono delle buone risposte che vengono fuori.

Ma Chris, mi chiedo con, con Faust, c'è qualche potenziale, so che è una piattaforma senza testa, ma c'è qualche potenziale per un tema Faust di WordPress che almeno ti fa impostare come, ecco i plugin di cui hai bisogno e qui c'è solo una specie di tutto fuori dagli schemi.

CW: Assolutamente. In effetti, ce l'abbiamo già. Ci riferiamo ad esso come Blueprints perché funziona così pesantemente con Local. La maggior parte delle persone eseguirà una sorta di modifica su queste cose prima di lanciarle su una piattaforma come WP Engine. Quindi abbiamo preso in prestito il nome di Local Blueprints.

Per il nuovo Faust ne abbiamo uno chiamato Portfolio, che è fondamentalmente un tema di portfolio completo e stiamo lavorando solo su un'impalcatura molto vuota che le agenzie possono utilizzare. Una volta che avrai capito le cose, probabilmente vorrai personalizzare tutto da solo. Quindi un'impalcatura sarebbe le migliori pratiche del progetto, lo fai girare e poi puoi fare tutte le tue cose con esso.

A lungo termine abbiamo parlato molto pesantemente di un negozio a tema senza testa, ala Blueprints. Non abbiamo la forza lavoro, quindi è un po 'lontano, ma è assolutamente qualcosa che stiamo considerando e che vorremmo vedere accadere.

DP: Sì, è bello pensarci. Questo è un tipo completamente diverso di ecosistema in cui entrare.

E sai, Jason, ti ho già intervistato, e sono sicuro che questa domanda si presenta sempre, ma ogni volta che sento parlare di WPGraphQL, penso che somigli molto a ciò che fa l'API REST. In realtà, sembra molto più potente di quello che fa l'API REST e l'API REST fa parte del core e mi chiedo solo, pensi che WPGraphQL dovrebbe far parte del core di WordPress?

JB: Forse un giorno. Non credo che ci siamo ancora. Quando le cose vengono unite in WordPress Core, probabilmente con l'eccezione di Gutenberg, l'innovazione si ferma. L'API REST, ad esempio, c'è ancora un bug che faccio notare alle persone che esiste ancora dal 2016, credo. quindi apportare modifiche deve essere fatto a un ritmo molto più lento, dove se si tratta di un plug-in puoi consentire alle persone di scegliere la versione a cui vogliono aderire e puoi iterare molto più velocemente perché possono scegliere quale versione funziona meglio per il loro progetto.

Dove nel core, se aggiorni il core e include modifiche sostanziali, potresti aver appena rotto il 40 percento del web. Quindi GraphQL è una specifica, non ha nulla a che fare anche con WordPress.

Destra. E così la specifica GraphQL è ancora in evoluzione. E mentre continua a evolversi, vogliamo stare al passo con le ultime e migliori specifiche GraphQL. Se dovessimo unire, diciamo, WPGraphQL in Core oggi e GraphQL continua ad evolversi, WordPress rimarrebbe bloccato all'edizione 2022 di GraphQL dove il resto del mondo è sulla versione 2030 o altro. Per me, penso che a un certo punto potrebbe avere senso vederlo riconosciuto come WPCLI come il modo ufficiale di fare X cosa.

Ad esempio, puoi creare il tuo client CLI per WordPress, ma è in qualche modo riconosciuto dalla comunità che WPCLI è la cosa ufficiale. Non fa parte di WordPress Core ma è riconosciuto dalla WordPress Foundation e dalla maggior parte della community di WordPress come qualcosa di ufficiale. Quindi potrebbe essere bello a un certo punto che un WPGraphQL venga riconosciuto in questo modo, come se avessi intenzione di fare WordPress senza testa, fallo in questo modo.

Rimarrà comunque un plugin. Questo è il mio pensiero. Potrebbe esserci un momento in cui GraphQL sembra perfetto e non viene realmente ripetuto e forse in quel momento lo consideriamo. Ma in questo momento ci sono cose in arrivo nelle specifiche GraphQL che causeranno modifiche sostanziali all'API.

Quindi farlo come plugin per me ha ancora senso.

DP: Subito. E sì, hai menzionato WPCLI e continuo a dimenticare, come se si sentissero come se fosse parte del nucleo. Qualunque cosa si senta, è come ufficiale. Quindi sì, è come, oh sì, è come questa cosa indipendente, proprio come lo è WPGraphQL al momento.

Questa è una buona analogia. Quindi, finirò qui. È stato davvero fantastico chiacchierare con tutti e due. Se gli ascoltatori sono interessati a seguire uno di voi, potete seguire @JasonBahl e @ChrisWeigman. Se possibile, inseriremo gli handle di Twitter nella descrizione dello spettacolo. Hai ascoltato Press This, un podcast della community di WordPress su WMR.

Nell'episodio della prossima settimana, Anne McCarthy, una product liaison presso Automatic, parlerà delle modifiche apportate all'editing del sito e alla 6.1 e di cosa accadrà con la 6.2. Grazie ancora per aver ascoltato Press This.

Puoi seguire le mie avventure con la rivista Torque su Twitter @thetorquemag o puoi andare su torquemag.io dove ogni giorno contribuiamo con tutorial, video e interviste come questa. Dai un'occhiata a torquemag.io o seguici su Twitter. Puoi iscriverti a Press This su Red Circle, iTunes, Spotify o puoi scaricarlo direttamente su wmr.fm ogni settimana. Sono il tuo host Doctor Popular Sostengo la community di WordPress attraverso il mio ruolo in WP Engine. E mi piace mettere in luce i membri della comunità ogni settimana su Press This.