Far funzionare GraphQL in WordPress

Headless WordPress sembra essere in voga ultimamente, con molti nuovi sviluppi in corso solo nelle ultime settimane. Uno dei motivi dell'esplosione di attività è il rilascio della versione 1.0 di WPGraphQL, un server GraphQL per WordPress.

WPGraphQL fornisce un'API GraphQL: un modo per recuperare e pubblicare dati da un sito Web WordPress. Ci consente di separare l'esperienza di gestione dei nostri contenuti, che viene eseguita tramite WordPress, dal rendering del sito Web, per il quale possiamo utilizzare la libreria del framework di nostra scelta (React, Vue.js, Gatsby, Next.js o qualsiasi altro).

Fino a poco tempo, WPGraphQL era l'unico server GraphQL per WordPress. Ma ora è disponibile un altro plugin simile: GraphQL API per WordPress, creato da me.

Questi due plugin hanno lo stesso scopo: fornire un'API GraphQL a un sito Web WordPress. Ti starai chiedendo: perché un altro plugin quando c'è già WPGraphQL? Questi due plugin fanno la stessa cosa? O sono per situazioni diverse?

Lasciatemi dire prima questo: WPGraphQL funziona alla grande. Non ho creato il mio plugin a causa di alcun problema con esso.

Ho creato l'API GraphQL per WordPress perché stavo lavorando su un motore per recuperare i dati in modo efficiente , che era molto adatto per GraphQL. Quindi, allora mi sono detto: "Perché no?", e l'ho costruito. (E anche un paio di altri motivi.)

I due plugin hanno architetture diverse, che conferiscono loro caratteristiche diverse, che rendono più facili compiti particolari con un plugin o l'altro.

In questo articolo descriverò, dal mio punto di vista ma nel modo più obiettivo possibile, quando WPGraphQL è la strada da percorrere e quando l'API GraphQL per WordPress è una scelta migliore.

Usa WPGraphQL se: Usa Gatsby

Se stai creando un sito Web utilizzando Gatsby, c'è solo una scelta: WPGraphQL.

Il motivo è che solo WPGraphQL ha il plugin sorgente Gatsby per WordPress. Inoltre, il creatore di WPGraphQL, Jason Bahl, è stato impiegato fino a poco tempo da Gatsby, quindi possiamo fidarci pienamente che questo plugin soddisferà le esigenze di Gatsby.

Gatsby riceve tutti i dati dal sito Web di WordPress e, da quel momento in poi, la logica dell'applicazione sarà completamente dalla parte di Gatsby, non da WordPress'. Quindi, nessuna aggiunta a WPGraphQL (come le potenziali aggiunte delle direttive @stream o @defer ) farebbe molta differenza.

WPGraphQL è già buono come Gatsby ha bisogno che sia.

Usa WPGraphQL se: utilizza uno dei nuovi framework senza testa

Come ho già detto, ultimamente c'è stata una raffica di attività nello spazio headless di WordPress riguardante diversi nuovi framework e progetti di avviamento, tutti basati su Next.js:

• Colby Fayock ha creato Next.js WordPress Starter.
• WebDevStudios ha lanciato il proprio Next.js WordPress Starter.
• WP Engine ha creato Headless WordPress Framework, che potenzia il suo servizio per ospitare e distribuire siti Web WordPress senza testa.

Se è necessario utilizzare uno di questi nuovi framework senza testa, sarà necessario utilizzare WPGraphQL, poiché sono stati tutti creati su questo plug-in.

È un po' sfortunato: mi piacerebbe davvero che l'API GraphQL per WordPress fosse anche in grado di alimentarle. Ma affinché ciò avvenga, questi framework dovrebbero operare con GraphQL tramite un'interfaccia , in modo da poter scambiare i server GraphQL.

Sono in qualche modo fiducioso che qualcuno di questi framework metta in atto una tale interfaccia. L'ho chiesto nel forum di discussione Headless WordPress Framework e mi è stato detto che poteva essere preso in considerazione. Ho anche chiesto nel forum di discussione Next.js WordPress Starter di WebDevStudios, ma purtroppo la mia domanda è stata immediatamente eliminata, senza risposta. (Non incoraggiante, vero?)

Quindi WPGraphQL è quindi, attualmente e per il prossimo futuro.

Utilizzare uno (o nessuno dei due) se: utilizzando Frontity

Frontity è un framework React per WordPress. Ti consente di creare un'applicazione basata su React gestita nel back-end tramite WordPress. Anche la creazione di post di blog utilizzando l'editor di WordPress è supportata immediatamente.

Frontity gestisce lo stato dell'applicazione, senza trapelare come sono stati ottenuti i dati. Anche se è basato su REST per impostazione predefinita, puoi anche alimentarlo tramite GraphQL implementando il plug-in sorgente corrispondente.

Ecco come Frontity è intelligente: il plug-in di origine è un'interfaccia per comunicare con il fornitore di dati. Attualmente, l'unico plug-in di origine disponibile è quello per l'API REST di WordPress. Ma chiunque può implementare un plug-in di origine per WPGraphQL o API GraphQL per WordPress. (Questo è l'approccio che desidero replicare i framework basati su Next.js.)

Conclusione : né WPGraphQL né l'API GraphQL offrono alcun vantaggio rispetto all'altro per lavorare con Frontity ed entrambi richiedono uno sforzo iniziale per collegarli.

Usa WPGraphQL se: Creazione di un sito statico

Nelle prime due sezioni, la conclusione era la stessa: Usa WPGraphQL. Ma la mia risposta a questa conclusione è stata diversa: mentre con Gatsby non avevo rimpianti, con Next.js mi sono sentito in dovere di fare qualcosa al riguardo.

Perché?

La differenza è che, mentre Gatsby è un generatore di siti puramente statici, Next.js può alimentare siti Web sia statici che live.

Ho detto che WPGraphQL è già abbastanza buono per Gatsby. Questa affermazione può essere effettivamente ampliata: WPGraphQL è già abbastanza buono per qualsiasi generatore di siti statici . Una volta che il generatore di siti statici ottiene i dati dal sito Web di WordPress, è praticamente risolto con WordPress.

Anche se l'API GraphQL per WordPress offre funzionalità aggiuntive, molto probabilmente non farà la differenza per il generatore di siti statici.

Quindi, poiché WPGraphQL è già abbastanza buono e ha mappato completamente lo schema GraphQL (che è ancora un lavoro in corso per l'API GraphQL per WordPress), quindi WPGraphQL è l'opzione più adatta, ora e per il prossimo futuro.

Usa l'API GraphQL se: Usa GraphQL in un sito web live (cioè non statico).

Ora, la situazione sopra cambia se vogliamo che GraphQL recuperi i dati da un sito Web live, ad esempio quando si alimenta un'app mobile o si tracciano dati in tempo reale su un sito Web (ad esempio, per visualizzare analisi) o combinando gli approcci statico e live sullo stesso sito web.

Ad esempio, supponiamo di aver creato un semplice blog statico utilizzando uno dei framework Next.js e di voler consentire agli utenti di aggiungere commenti ai post del blog. Come dovrebbe essere gestito questo compito?

Abbiamo due opzioni: statico e live (o dinamico). Se optiamo per lo statico, i commenti verranno visualizzati insieme al resto del sito Web. Quindi, ogni volta che viene aggiunto un commento, dobbiamo attivare un webhook per rigenerare e ridistribuire il sito web.

Questo approccio presenta alcuni inconvenienti. Il processo di rigenerazione e ridistribuzione potrebbe richiedere alcuni minuti, durante i quali il nuovo commento non sarà disponibile. Inoltre, se il sito Web riceve molti commenti al giorno, l'approccio statico richiederà più tempo di elaborazione del server, che potrebbe diventare costoso (alcune società di hosting addebitano in base al tempo del server).

In questa situazione, avrebbe senso eseguire il rendering statico del sito Web senza commenti, quindi recuperare i commenti da un sito live e renderli dinamicamente nel client.

Per questo, Next.js è consigliato su Gatsby. Può gestire meglio gli approcci statici e live, incluso il supporto di output diversi per utenti con capacità diverse.

Torna alla discussione su GraphQL: perché consiglio l'API GraphQL per WordPress quando si tratta di dati in tempo reale? Lo faccio perché il server GraphQL può avere un impatto diretto sull'applicazione, principalmente in termini di velocità e sicurezza .

Per un sito Web puramente statico, il sito Web WordPress può essere mantenuto privato (potrebbe anche vivere sul laptop dello sviluppatore), quindi è sicuro. E l'utente non attenderà una risposta dal server, quindi la velocità non è necessariamente di fondamentale importanza.

Per un sito live, tuttavia, l'API GraphQL sarà resa pubblica, quindi la sicurezza dei dati diventa un problema. Dobbiamo assicurarci che nessun attore malintenzionato possa accedervi. Inoltre, l'utente attenderà una risposta, quindi la velocità diventa una considerazione fondamentale.

A questo proposito, l'API GraphQL per WordPress presenta alcuni vantaggi rispetto a WPGraphQL .

WPGraphQL implementa misure di sicurezza, come disabilitare l'introspezione per impostazione predefinita. Ma l'API GraphQL per WordPress va oltre, disabilitando il singolo endpoint per impostazione predefinita (insieme a molte altre misure). Ciò è possibile perché l'API GraphQL per WordPress offre query persistenti in modo nativo.

Per quanto riguarda la velocità, le query persistenti rendono anche l'API più veloce, perché la risposta può quindi essere memorizzata nella cache tramite la memorizzazione nella cache HTTP su più livelli, inclusi il client, la rete di distribuzione dei contenuti e il server.

Questi motivi rendono l'API GraphQL per WordPress più adatta alla gestione di siti Web live.

Utilizzare l'API GraphQL se: esposizione di dati diversi per utenti o applicazioni diversi

WordPress è un sistema di gestione dei contenuti versatile, in grado di gestire i contenuti per più applicazioni e accessibile a diverse tipologie di utenti.

A seconda del contesto, potremmo aver bisogno delle nostre API GraphQL per esporre dati diversi, come ad esempio:

• esporre determinati dati agli utenti pagati ma non agli utenti non pagati,
• esporre determinati dati all'app mobile ma non al sito web.

Per esporre dati diversi, è necessario fornire versioni diverse dello schema GraphQL .

WPGraphQL ci consente di modificare lo schema (ad esempio, possiamo rimuovere un campo registrato). Ma il processo non è semplice: le modifiche allo schema devono essere codificate e non è facile capire chi sta accedendo a cosa e dove (ad esempio, tutti gli schemi sarebbero ancora disponibili sotto il singolo endpoint, /graphql ).

Al contrario, l'API GraphQL per WordPress supporta nativamente questo caso d'uso: offre endpoint personalizzati, che possono esporre dati diversi per contesti diversi, come ad esempio:

• /graphql/mobile-app e /graphql/website ,
• /graphql/pro-users e /graphql/regular-users .

Ogni endpoint personalizzato è configurato tramite elenchi di controllo di accesso, per fornire un accesso utente granulare campo per campo, nonché una modalità API pubblica e privata per determinare se i metadati dello schema sono disponibili per tutti o solo per gli utenti autorizzati.

Queste funzionalità si integrano direttamente con l'editor di WordPress (es. Gutenberg). Quindi, la creazione dei diversi schemi viene eseguita visivamente, in modo simile alla creazione di un post sul blog. Ciò significa che tutti possono produrre schemi GraphQL personalizzati , non solo gli sviluppatori.

L'API GraphQL per WordPress fornisce, credo, una soluzione naturale per questo caso d'uso.

Utilizzare l'API GraphQL se: Interagire con servizi esterni

GraphQL non è semplicemente un'API per il recupero e la pubblicazione di dati. Per quanto importante (sebbene spesso trascurato), può anche elaborare e alterare i dati , ad esempio inviandoli a un servizio esterno, come l'invio di testo a un'API di terze parti per correggere errori grammaticali o il caricamento di un'immagine in una consegna di contenuti Rete.

Ora, qual è il modo migliore per GraphQL di comunicare con servizi esterni? A mio parere, ciò si ottiene al meglio attraverso le direttive, applicate durante la creazione o il recupero dei dati (non diversamente da come funzionano i filtri di WordPress).

Non so quanto bene WPGraphQL interagisca con i servizi esterni, perché la sua documentazione non lo menziona e la base di codice non offre un esempio di alcuna direttiva o documento su come crearne uno.

Al contrario, l'API GraphQL per WordPress ha un solido supporto per le direttive . Ogni direttiva in una query viene eseguita solo una volta in totale (anziché una per campo e/o oggetto). Questa funzionalità consente una comunicazione molto efficiente con API esterne e integra l'API GraphQL all'interno di un cloud di servizi.

Ad esempio, questa query mostra una chiamata all'API di Google Translate tramite una direttiva @translate , per tradurre i titoli e gli estratti di molti post dall'inglese allo spagnolo. Tutti i campi di tutti i post vengono tradotti insieme, in un'unica chiamata.

L'API GraphQL per WordPress è una scelta naturale per questo caso d'uso.

Nota : In effetti, il motore su cui si basa l'API GraphQL per WordPress, GraphQL di PoP, è stato specificamente progettato per fornire funzionalità avanzate di manipolazione dei dati. Questa è una delle sue caratteristiche distintive. Per un esempio estremo di ciò che può ottenere, consulta la guida su "Invio di una newsletter localizzata, utente per utente".

Usa WPGraphQL se: vuoi una community di supporto

Jason Bahl ha svolto un ottimo lavoro nel radunare una comunità attorno a WPGraphQL. Di conseguenza, se devi risolvere i problemi della tua API GraphQL, probabilmente troverai qualcuno che può aiutarti.

Nel mio caso, sto ancora cercando di creare una comunità di utenti attorno all'API GraphQL per WordPress, e certamente non è affatto vicina a quella di WPGraphQL.

Usa l'API GraphQL se: Ti piace l'innovazione

Chiamo GraphQL API per WordPress un server GraphQL "prospettico". Il motivo è che spesso sfoglio l'elenco delle richieste per la specifica GraphQL e ne implemento alcune con largo anticipo (soprattutto quelle per cui sento una certa affinità o che posso supportare con poco sforzo).

Ad oggi, l'API GraphQL per WordPress supporta diverse funzionalità innovative (come l'esecuzione di query multiple e lo spazio dei nomi degli schemi), offerte come opt-in, e sono previste alcune altre.

Usa WPGraphQL se: hai bisogno di uno schema completo

WPGraphQL ha mappato completamente il modello di dati di WordPress, tra cui:

• post e pagine,
• tipi di post personalizzati,
• categorie e tag,
• tassonomie personalizzate,
• media,
• menu,
• impostazioni,
• utenti,
• Commenti,
• plugin,
• temi,
• widget.

L'API GraphQL per WordPress sta mappando progressivamente il modello di dati con ogni nuova versione. Ad oggi l'elenco comprende:

• post e pagine,
• tipi di post personalizzati,
• categorie e tag,
• tassonomie personalizzate,
• media,
• menu,
• impostazioni,
• utenti,
• Commenti.

Quindi, se hai bisogno di recuperare i dati da un plugin, un tema o un widget, attualmente solo WPGraphQL fa il lavoro.

Usa WPGraphQL se: hai bisogno di estensioni

WPGraphQL offre estensioni per molti plugin, inclusi Advanced Custom Fields, WooCommerce, Yoast, Gravity Forms.

L'API GraphQL per WordPress offre un'estensione per Events Manager e continuerà ad aggiungerne altre dopo il rilascio della versione 1.0 del plugin.

Usa entrambi se: creazione di blocchi per l'editor di WordPress

Sia WPGraphQL che GraphQL API per WordPress stanno attualmente lavorando per integrare GraphQL con Gutenberg.

Jason Bahl ha descritto tre approcci attraverso i quali questa integrazione può aver luogo. Tuttavia, poiché tutti hanno problemi, sta sostenendo l'introduzione di un registro lato server su WordPress, per consentire l'identificazione dei diversi blocchi Gutenberg per lo schema GraphQL.

L'API GraphQL per WordPress ha anche un approccio per l'integrazione con Gutenberg, basato sulla strategia "crea una volta, pubblica ovunque". Estrae i dati dei blocchi dal contenuto archiviato e utilizza un unico tipo di Block per rappresentare tutti i blocchi. Questo approccio potrebbe evitare la necessità del registro lato server proposto.

La soluzione di WPGraphQL può essere considerata provvisoria, perché dipenderà dalla comunità che accetta l'uso di un registro lato server e non sappiamo se o quando ciò accadrà.

Per l'API GraphQL per WordPress, la soluzione dipenderà interamente da se stessa ed è già in lavorazione.

Poiché ha maggiori possibilità di produrre presto una soluzione funzionante, sarei propenso a consigliare l'API GraphQL per WordPress . Tuttavia, aspettiamo che la soluzione sia completamente implementata (in poche settimane, secondo il piano) per assicurarci che funzioni come previsto, quindi aggiornerò la mia raccomandazione.

Usa l'API GraphQL se: distribuzione di blocchi tramite un plug-in

Mi sono reso conto: non molti plug-in (se ce ne sono) sembrano utilizzare GraphQL in WordPress.

Non fraintendetemi: WPGraphQL ha superato le 10.000 installazioni. Ma credo che quelle siano principalmente installazioni per alimentare Gatsby (per eseguire Gatsby) o per alimentare Next.js (per eseguire uno dei framework senza testa).

Allo stesso modo, WPGraphQL ha molte estensioni, come ho descritto in precedenza. Ma quelle estensioni sono proprio questo: estensioni. Non sono plugin autonomi.

Ad esempio, l'estensione WPGraphQL per WooCommerce dipende dai plugin WPGraphQL e WooCommerce. Se uno dei due non è installato, l'estensione non funzionerà e va bene. Ma WooCommerce non ha la possibilità di affidarsi a WPGraphQL per funzionare; quindi, non ci sarà GraphQL nel plugin WooCommerce.

La mia comprensione è che non ci sono plug-in che utilizzano GraphQL per eseguire funzionalità per WordPress stesso o, in particolare, per alimentare i loro blocchi Gutenberg.

Il motivo è semplice: né WPGraphQL né GraphQL API per WordPress fanno parte del core di WordPress. Pertanto, non è possibile fare affidamento su GraphQL nel modo in cui i plugin possono fare affidamento sull'API REST di WordPress. Di conseguenza, i plug-in che implementano i blocchi Gutenberg possono utilizzare solo REST per recuperare i dati per i loro blocchi, non GraphQL.

Apparentemente, la soluzione è attendere che una soluzione GraphQL (molto probabilmente WPGraphQL) venga aggiunta al core di WordPress. Ma chissà quanto tempo ci vorrà? Sei mesi? Un anno? Due anni? Più a lungo?

Sappiamo che WPGraphQL viene preso in considerazione per il core di WordPress perché Matt Mullenweg ne ha accennato. Ma prima di allora devono succedere tante cose: portare la versione minima di PHP alla 7.1 (richiesta sia da WPGraphQL che dall'API GraphQL per WordPress), oltre ad avere un chiaro disaccoppiamento, comprensione e roadmap per quale funzionalità alimenterà GraphQL.

(L'editing completo del sito, attualmente in fase di sviluppo, è basato su REST. Che dire della prossima caratteristica principale, i blocchi multilingue, da affrontare nella fase 4 di Gutenberg? In caso contrario, quale funzione sarà?)

Dopo aver spiegato il problema, consideriamo una possibile soluzione , che non deve aspettare!

Qualche giorno fa, ho avuto un'altra realizzazione: dall'API GraphQL per la base di codice di WordPress, posso produrre una versione più piccola, contenente solo il motore GraphQL e nient'altro (nessuna interfaccia utente, nessun endpoint personalizzato, nessuna cache HTTP, nessun controllo di accesso, no niente). E questa versione può essere distribuita come una dipendenza Composer, in modo che i plugin possano installarla per alimentare i propri blocchi.

La chiave di questo approccio è che questo componente deve essere di uso specifico per il plugin, per non essere condiviso con nessun altro. In caso contrario, due plug-in che fanno entrambi riferimento a questo componente potrebbero modificare lo schema in modo tale da sovrascriversi a vicenda.

Fortunatamente, ho recentemente risolto l'ambito dell'API GraphQL per WordPress. Quindi, so che sono in grado di estenderlo completamente, producendo una versione che non entrerà in conflitto con nessun altro codice sul sito web.

Ciò significa che funzionerà per qualsiasi combinazione di eventi :

• Se il plugin che contiene il componente è l'unico che lo utilizza;
• Se anche l'API GraphQL per WordPress è installata sullo stesso sito Web;
• Se sul sito web è installato un altro plugin che incorpora anche questo componente;
• Se due plugin che incorporano il componente fanno riferimento alla stessa versione del componente oa versioni diverse.

In ogni situazione, il plug-in avrà il proprio motore GraphQL autonomo e privato su cui potrà fare pieno affidamento per alimentare i suoi blocchi Gutenberg (e non dobbiamo temere alcun conflitto).

Questo componente, che si chiamerà Private GraphQL API , dovrebbe essere pronto in poche settimane. (Ho già iniziato a lavorarci.)

Quindi, la mia raccomandazione è che, se si desidera utilizzare GraphQL per alimentare i blocchi Gutenberg nel plug-in, attendere alcune settimane, quindi controllare l'API GraphQL per il fratello minore di WordPress, l'API GraphQL privata.

Conclusione

Anche se ho la pelle nel gioco, penso di essere riuscito a scrivere un articolo che è per lo più obiettivo.

Sono stato onesto nell'affermare perché e quando è necessario utilizzare WPGraphQL. Allo stesso modo, sono stato onesto nello spiegare perché l'API GraphQL per WordPress sembra essere migliore di WPGraphQL per diversi casi d'uso.

In termini generali, possiamo riassumere come segue:

• Diventa statico con WPGraphQL o vai in diretta con l'API GraphQL per WordPress.
• Gioca sul sicuro con WPGraphQL o investi (per un guadagno potenzialmente degno) nell'API GraphQL per WordPress.

In una nota finale, vorrei che i framework Next.js fossero riprogettati per seguire lo stesso approccio utilizzato da Frontity: dove possono accedere a un'interfaccia per recuperare i dati di cui hanno bisogno, invece di utilizzare un'implementazione diretta di una soluzione particolare ( quello attuale è WPGraphQL). In tal caso, gli sviluppatori potrebbero scegliere quale server sottostante utilizzare (se WPGraphQL, API GraphQL per WordPress o qualche altra soluzione introdotta in futuro), in base alle proprie esigenze, da progetto a progetto.

link utili

• WPGraphQL: documentazione, pagina di download, repository di codice
• API GraphQL per WordPress: documentazione, pagina di download, repository di codice
• "Il seminario sull'integrazione di Gatsby WordPress"
  Video di YouTube con demo di WPGraphQL
• "Introduzione all'API GraphQL per WordPress"
  Video di YouTube con demo dell'API GraphQL per WordPress