Faceți ca GraphQL să funcționeze în WordPress

WordPress fără cap pare să fie în vogă în ultima vreme, cu multe dezvoltări noi având loc doar în ultimele săptămâni. Unul dintre motivele exploziei de activitate este lansarea versiunii 1.0 a WPGraphQL, un server GraphQL pentru WordPress.

WPGraphQL oferă un API GraphQL: o modalitate de a prelua date de la și de a posta date pe un site web WordPress. Ne permite să decuplăm experiența de gestionare a conținutului nostru, care se face prin WordPress, de redarea site-ului web, pentru care putem folosi biblioteca cadrului ales de noi (React, Vue.js, Gatsby, Next.js sau oricare altul).

Până de curând, WPGraphQL a fost singurul server GraphQL pentru WordPress. Dar acum este disponibil un alt astfel de plugin: GraphQL API pentru WordPress, creat de mine.

Aceste două plugin-uri servesc aceluiași scop: să ofere un API GraphQL unui site web WordPress. Poate vă întrebați: De ce un alt plugin când există deja WPGraphQL? Aceste două pluginuri fac același lucru? Sau sunt pentru diferite situatii?

Permiteți-mi să spun asta mai întâi: WPGraphQL funcționează excelent. Nu mi-am construit pluginul din cauza vreunei probleme cu acesta.

Am construit API-ul GraphQL pentru WordPress pentru că lucram la un motor pentru a prelua datele în mod eficient , care sa întâmplat să fie foarte potrivit pentru GraphQL. Așa că, apoi mi-am spus: „De ce nu?” și l-am construit. (Și, de asemenea, alte câteva motive.)

Cele două plugin-uri au arhitecturi diferite, oferindu-le caracteristici diferite, ceea ce face anumite sarcini mai ușor de realizat cu un plugin sau altul.

În acest articol, voi descrie, din punctul meu de vedere, dar cât se poate de obiectiv, când WPGraphQL este calea de urmat și când API-ul GraphQL pentru WordPress este o alegere mai bună.

Utilizați WPGraphQL dacă: Folosiți Gatsby

Dacă construiți un site web folosind Gatsby, atunci există o singură opțiune: WPGraphQL.

Motivul este că numai WPGraphQL are pluginul sursă Gatsby pentru WordPress. În plus, creatorul WPGraphQL, Jason Bahl, a fost angajat până de curând de Gatsby, așa că putem avea încredere deplină că acest plugin se va potrivi nevoilor lui Gatsby.

Gatsby primește toate datele de pe site-ul WordPress, iar de atunci, logica aplicației va fi pe deplin de partea lui Gatsby, nu de WordPress'. Prin urmare, nicio adăugare la WPGraphQL (cum ar fi potențialele completări ale directivelor @stream sau @defer ) nu ar face o mare diferență.

WPGraphQL este deja la fel de bun pe cât are nevoie Gatsby.

Utilizați WPGraphQL dacă: utilizați unul dintre noile cadre fără cap

După cum am menționat, în ultimul timp a existat o rafală de activitate în spațiul WordPress headless cu privire la mai multe cadre noi și proiecte de pornire, toate bazate pe Next.js:

• Colby Fayock a creat Next.js WordPress Starter.
• WebDevStudios și-a lansat propriul Next.js WordPress Starter.
• WP Engine a creat Cadrul WordPress Headless, care își alimentează serviciul pentru a găzdui și implementa site-uri web WordPress fără cap.

Dacă trebuie să utilizați oricare dintre aceste noi cadre fără cap, atunci va trebui să utilizați WPGraphQL, deoarece toate au fost construite pe deasupra acestui plugin.

Este puțin regretabil: mi-ar plăcea foarte mult ca API-ul GraphQL pentru WordPress să le poată alimenta și pe ele. Dar pentru ca acest lucru să se întâmple, aceste cadre ar trebui să funcționeze cu GraphQL printr-o interfață , astfel încât să putem schimba serverele GraphQL.

Am oarecum speranța că oricare dintre aceste cadre va pune la punct o astfel de interfață. Am întrebat despre asta în forumul de discuții Headless WordPress Framework și mi s-a spus că ar putea fi luat în considerare. Am întrebat și în forumul de discuții Next.js WordPress Starter de la WebDevStudios, dar, din păcate, întrebarea mea a fost imediat ștearsă, fără răspuns. (Nu este încurajator, nu-i așa?)

Deci WPGraphQL este atunci, în prezent și pentru viitorul previzibil.

Utilizați oricare (sau niciunul) dacă: Folosind Frontity

Frontity este un framework React pentru WordPress. Vă permite să construiți o aplicație bazată pe React, care este gestionată în back-end prin WordPress. Chiar și crearea de postări de blog folosind editorul WordPress este acceptată imediat.

Frontity gestionează starea aplicației, fără a scurge cum au fost obținute datele. Chiar dacă se bazează în mod implicit pe REST, îl puteți alimenta și prin GraphQL prin implementarea pluginului sursă corespunzător.

Iată cum este inteligentă Frontity: pluginul sursă este o interfață pentru a comunica cu furnizorul de date. În prezent, singurul plugin sursă disponibil este cel pentru API-ul REST WordPress. Dar oricine poate implementa un plugin sursă fie pentru WPGraphQL, fie pentru API-ul GraphQL pentru WordPress. (Aceasta este abordarea pe care îmi doresc ca cadrele bazate pe Next.js să fie replicate.)

Concluzie : Nici WPGraphQL, nici API-ul GraphQL nu oferă niciun avantaj față de celălalt pentru lucrul cu Frontity și ambele necesită un efort inițial pentru a le conecta.

Utilizați WPGraphQL dacă: Creați un site static

În primele două secțiuni, concluzia a fost aceeași: Folosiți WPGraphQL. Dar răspunsul meu la această concluzie a fost diferit: în timp ce cu Gatsby nu aveam niciun regret, cu Next.js m-am simțit obligat să fac ceva în acest sens.

De ce este asta?

Diferența este că, în timp ce Gatsby este pur și simplu un generator de site-uri static, Next.js poate alimenta atât site-uri web statice, cât și live.

Am menționat că WPGraphQL este deja suficient de bun pentru Gatsby. Această afirmație poate fi de fapt extinsă: WPGraphQL este deja suficient de bun pentru orice generator de site static . Odată ce generatorul de site-uri static primește datele de pe site-ul WordPress, este aproape rezolvat cu WordPress.

Chiar dacă GraphQL API pentru WordPress oferă funcții suplimentare, cel mai probabil nu va face o diferență pentru generatorul de site static.

Prin urmare, pentru că WPGraphQL este deja suficient de bun și a mapat complet schema GraphQL (care este încă o lucrare în curs pentru GraphQL API pentru WordPress), atunci WPGraphQL este cea mai potrivită opțiune, acum și pentru viitorul apropiat.

Utilizați GraphQL API dacă: Folosiți GraphQL într-un site web live (adică non-static).

Acum, situația de mai sus se schimbă dacă dorim ca GraphQL să preia date de pe un site web în direct, cum ar fi atunci când pornește o aplicație mobilă sau trasează date în timp real pe un site web (de exemplu, pentru a afișa analize) sau combinând atât abordările statice, cât și cele live. pe acelasi site.

De exemplu, să presupunem că am construit un blog static simplu folosind unul dintre cadrele Next.js și dorim să le permitem utilizatorilor să adauge comentarii la postările de blog. Cum ar trebui gestionată această sarcină?

Avem două opțiuni: static și live (sau dinamic). Dacă optăm pentru static, atunci comentariile vor fi redate împreună cu restul site-ului. Apoi, ori de câte ori este adăugat un comentariu, trebuie să declanșăm un webhook pentru a regenera și redistribui site-ul.

Această abordare are câteva inconveniente. Procesul de regenerare și redistribuire ar putea dura câteva minute, timp în care noul comentariu nu va fi disponibil. În plus, dacă site-ul web primește multe comentarii pe zi, abordarea statică va necesita mai mult timp de procesare a serverului, ceea ce ar putea deveni costisitor (unele companii de găzduire taxează în funcție de timpul serverului).

În această situație, ar avea sens să redați site-ul static fără comentarii, apoi să preluați comentariile de pe un site live și să le redați dinamic în client.

Pentru aceasta, Next.js este recomandat față de Gatsby. Poate gestiona mai bine abordările statice și live, inclusiv suportarea diferitelor ieșiri pentru utilizatori cu capacități diferite.

Înapoi la discuția GraphQL: De ce recomand GraphQL API pentru WordPress atunci când lucrez cu date live? O fac pentru că serverul GraphQL poate avea un impact direct asupra aplicației, în principal în ceea ce privește viteza și securitatea .

Pentru un site pur static, site-ul WordPress poate fi păstrat privat (ar putea chiar să trăiască pe laptopul dezvoltatorului), deci este sigur. Și utilizatorul nu va aștepta un răspuns de la server, așa că viteza nu este neapărat de o importanță critică.

Pentru un site live, totuși, API-ul GraphQL va fi făcut public, astfel încât siguranța datelor devine o problemă. Trebuie să ne asigurăm că niciun actor rău intenționat nu îl poate accesa. În plus, utilizatorul va aștepta un răspuns, astfel încât viteza devine un aspect critic.

În acest sens, GraphQL API pentru WordPress are câteva avantaje față de WPGraphQL .

WPGraphQL implementează măsuri de securitate, cum ar fi dezactivarea implicită a introspecției. Dar API-ul GraphQL pentru WordPress merge mai departe, dezactivând în mod implicit punctul final unic (împreună cu alte câteva măsuri). Acest lucru este posibil deoarece API-ul GraphQL pentru WordPress oferă interogări persistente în mod nativ.

În ceea ce privește viteza, interogările persistente fac API-ul mai rapid, deoarece răspunsul poate fi apoi stocat în cache prin cache HTTP pe mai multe straturi, inclusiv client, rețea de livrare de conținut și server.

Aceste motive fac ca API-ul GraphQL pentru WordPress să fie mai potrivit pentru gestionarea site-urilor web live.

Utilizați GraphQL API dacă: Expunerea diferitelor date pentru diferiți utilizatori sau aplicații

WordPress este un sistem versatil de gestionare a conținutului, capabil să gestioneze conținutul pentru mai multe aplicații și accesibil diferitelor tipuri de utilizatori.

În funcție de context, este posibil să avem nevoie de API-urile noastre GraphQL pentru a expune date diferite, cum ar fi:

• expune anumite date utilizatorilor plătiți, dar nu și utilizatorilor neplătiți,
• expune anumite date aplicației mobile, dar nu și site-ului web.

Pentru a expune date diferite, trebuie să oferim versiuni diferite ale schemei GraphQL .

WPGraphQL ne permite să modificăm schema (de exemplu, putem elimina un câmp înregistrat). Dar procesul nu este simplu: modificările schemei trebuie codificate și nu este ușor de înțeles cine accesează ce și unde (de exemplu, toate schemele ar fi în continuare disponibile sub punctul final unic, /graphql ).

În schimb, GraphQL API pentru WordPress acceptă în mod nativ acest caz de utilizare: oferă puncte finale personalizate, care pot expune date diferite pentru diferite contexte, cum ar fi:

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

Fiecare punct final personalizat este configurat prin liste de control al accesului, pentru a oferi acces granular utilizator câmp cu câmp, precum și un mod API public și privat pentru a determina dacă metadatele schemei sunt disponibile pentru toată lumea sau numai pentru utilizatorii autorizați.

Aceste caracteristici se integrează direct cu editorul WordPress (adică Gutenberg). Deci, crearea diferitelor scheme se face vizual, similar cu crearea unei postări pe blog. Aceasta înseamnă că toată lumea poate produce scheme GraphQL personalizate , nu numai dezvoltatorii.

API-ul GraphQL pentru WordPress oferă, cred, o soluție naturală pentru acest caz de utilizare.

Utilizați API-ul GraphQL dacă: interacționați cu serviciile externe

GraphQL nu este doar un API pentru preluarea și postarea datelor. La fel de important (deși deseori neglijat), poate, de asemenea, să proceseze și să modifice datele - de exemplu, furnizându-le unui serviciu extern, cum ar fi trimiterea de text către un API terță parte pentru a remedia erorile gramaticale sau încărcarea unei imagini într-o livrare de conținut. reţea.

Acum, care este cea mai bună modalitate prin care GraphQL poate comunica cu serviciile externe? În opinia mea, acest lucru se realizează cel mai bine prin directive, aplicate fie la crearea, fie la preluarea datelor (nu spre deosebire de modul în care funcționează filtrele WordPress).

Nu știu cât de bine interacționează WPGraphQL cu serviciile externe, deoarece documentația sa nu o menționează, iar baza de cod nu oferă un exemplu de directivă sau document despre cum să creeze una.

În schimb, GraphQL API pentru WordPress are suport robust pentru directive . Fiecare directivă dintr-o interogare este executată o singură dată în total (spre deosebire de o dată pe câmp și/sau obiect). Această capacitate permite o comunicare foarte eficientă cu API-uri externe și integrează API-ul GraphQL într-un nor de servicii.

De exemplu, această interogare demonstrează un apel către API-ul Google Translate printr-o directivă @translate , pentru a traduce titlurile și extrasele multor postări din engleză în spaniolă. Toate câmpurile pentru toate postările sunt traduse împreună, într-un singur apel.

GraphQL API pentru WordPress este o alegere naturală pentru acest caz de utilizare.

Notă : De fapt, motorul pe care se bazează GraphQL API pentru WordPress, GraphQL by PoP, a fost conceput special pentru a oferi capabilități avansate de manipulare a datelor. Aceasta este una dintre caracteristicile sale distincte. Pentru un exemplu extrem de ceea ce poate realiza, consultați ghidul despre „Trimiterea unui buletin informativ localizat, utilizator după utilizator”.

Utilizați WPGraphQL dacă: doriți o comunitate de asistență

Jason Bahl a făcut o treabă superbă de a aduna o comunitate în jurul WPGraphQL. Drept urmare, dacă trebuie să depanați API-ul GraphQL, probabil veți găsi pe cineva care vă poate ajuta.

În cazul meu, încă mă străduiesc să creez o comunitate de utilizatori în jurul API-ului GraphQL pentru WordPress și, cu siguranță, nu se apropie de cea a WPGraphQL.

Utilizați GraphQL API dacă: Vă place inovația

Eu numesc GraphQL API pentru WordPress un server GraphQL „perspectiv”. Motivul este că răsfoiesc adesea lista de solicitări pentru specificația GraphQL și implementez unele dintre ele cu mult înainte de timp (în special cele pentru care simt o anumită afinitate sau pe care le pot suporta cu puțin efort).

Începând de astăzi, GraphQL API pentru WordPress acceptă mai multe funcții inovatoare (cum ar fi execuția de interogări multiple și spațiarea numelor schemei), oferite ca opt-in și există planuri pentru încă câteva.

Utilizați WPGraphQL dacă: aveți nevoie de o schemă completă

WPGraphQL a mapat complet modelul de date WordPress, inclusiv:

• postări și pagini,
• tipuri de postări personalizate,
• categorii și etichete,
• taxonomii personalizate,
• mass-media,
• meniuri,
• setari,
• utilizatori,
• comentarii,
• pluginuri,
• teme,
• widget-uri.

GraphQL API pentru WordPress cartografiază progresiv modelul de date cu fiecare nouă lansare. Începând de astăzi, lista include:

• postări și pagini,
• tipuri de postări personalizate,
• categorii și etichete,
• taxonomii personalizate,
• mass-media,
• meniuri,
• setari,
• utilizatori,
• comentarii.

Deci, dacă trebuie să preluați date dintr-un plugin, o temă sau un widget, în prezent numai WPGraphQL face treaba.

Utilizați WPGraphQL dacă: aveți nevoie de extensii

WPGraphQL oferă extensii pentru multe plugin-uri, inclusiv Advanced Custom Fields, WooCommerce, Yoast, Gravity Forms.

GraphQL API pentru WordPress oferă o extensie pentru Events Manager și va continua să adauge mai multe după lansarea versiunii 1.0 a pluginului.

Utilizați Oricare Dacă: Crearea de blocuri pentru Editorul WordPress

Atât WPGraphQL, cât și GraphQL API pentru WordPress lucrează în prezent la integrarea GraphQL cu Gutenberg.

Jason Bahl a descris trei abordări prin care această integrare poate avea loc. Cu toate acestea, deoarece toți au probleme, el pledează pentru introducerea unui registru pe server în WordPress, pentru a permite identificarea diferitelor blocuri Gutenberg pentru schema GraphQL.

GraphQL API pentru WordPress are, de asemenea, o abordare pentru integrarea cu Gutenberg, bazată pe strategia „creați o dată, publicați peste tot”. Extrage datele blocurilor din conținutul stocat și folosește un singur tip de Block pentru a reprezenta toate blocurile. Această abordare ar putea evita necesitatea registrului propus pe partea serverului.

Soluția WPGraphQL poate fi considerată tentativă, deoarece va depinde de faptul că comunitatea acceptă utilizarea unui registru pe partea de server și nu știm dacă sau când se va întâmpla asta.

Pentru GraphQL API pentru WordPress, soluția va depinde în întregime de ea însăși și este într-adevăr deja o lucrare în curs.

Deoarece are șanse mai mari de a produce o soluție funcțională în curând, aș fi înclinat să recomand API-ul GraphQL pentru WordPress . Totuși, să așteptăm ca soluția să fie implementată integral (în câteva săptămâni, conform planului) pentru a ne asigura că funcționează conform intenției, iar apoi îmi voi actualiza recomandarea.

Utilizați API-ul GraphQL dacă: distribuiți blocuri printr-un plugin

Am ajuns la o realizare: nu multe plugin-uri (dacă există) par să folosească GraphQL în WordPress.

Nu mă înțelege greșit: WPGraphQL a depășit 10.000 de instalări. Dar cred că acestea sunt în mare parte instalații pentru a alimenta Gatsby (pentru a rula Gatsby) sau pentru a alimenta Next.js (pentru a rula unul dintre cadrele fără cap).

În mod similar, WPGraphQL are multe extensii, așa cum am descris mai devreme. Dar acele extensii sunt doar atât: extensii. Nu sunt pluginuri independente.

De exemplu, extensia WPGraphQL pentru WooCommerce depinde atât de pluginurile WPGraphQL, cât și de WooCommerce. Dacă niciunul dintre ele nu este instalat, atunci extensia nu va funcționa și este în regulă. Dar WooCommerce nu are de ales să se bazeze pe WPGraphQL pentru a funcționa; prin urmare, nu va exista GraphQL în pluginul WooCommerce.

Înțeleg că nu există pluginuri care să folosească GraphQL pentru a rula funcționalitatea pentru WordPress în sine sau, în special, pentru a-și alimenta blocurile Gutenberg.

Motivul este simplu: nici WPGraphQL, nici GraphQL API pentru WordPress nu fac parte din nucleul WordPress. Astfel, nu este posibil să te bazezi pe GraphQL în felul în care pluginurile se pot baza pe API-ul REST al WordPress. Ca rezultat, pluginurile care implementează blocuri Gutenberg pot folosi doar REST pentru a prelua date pentru blocurile lor, nu GraphQL.

Aparent, soluția este să așteptați ca o soluție GraphQL (cel mai probabil WPGraphQL) să fie adăugată la nucleul WordPress. Dar cine știe cât va dura? Șase luni? Un an? Doi ani? Mai lung?

Știm că WPGraphQL este luat în considerare pentru nucleul WordPress, deoarece Matt Mullenweg a sugerat acest lucru. Dar trebuie să se întâmple atât de multe lucruri înainte de atunci: ridicarea versiunii minime de PHP la 7.1 (solicitată atât de WPGraphQL, cât și de API-ul GraphQL pentru WordPress), precum și de a avea o decuplare clară, înțelegere și o foaie de parcurs pentru ce funcționalitate va genera GraphQL.

(Editarea completă a site-ului, în prezent în curs de dezvoltare, se bazează pe REST. Cum rămâne cu următoarea caracteristică majoră, blocurile multilingve, care urmează să fie abordată în faza 4 a lui Gutenberg? Dacă nu asta, atunci care caracteristică va fi?)

După ce am explicat problema, să luăm în considerare o posibilă soluție - una care nu trebuie să aștepte!

Acum câteva zile, am avut o altă realizare: din API-ul GraphQL pentru baza de coduri WordPress, pot produce o versiune mai mică, care să conțină doar motorul GraphQL și nimic altceva (fără interfață de utilizare, fără terminale personalizate, fără caching HTTP, fără control al accesului, nimic). Și această versiune poate fi distribuită ca dependență de Composer, astfel încât pluginurile să o poată instala pentru a-și alimenta propriile blocuri.

Cheia acestei abordări este că această componentă trebuie să fie de o utilizare specifică pentru plugin, să nu fie partajată cu nimeni altcineva. În caz contrar, două plugin-uri care fac referire la această componentă ar putea modifica schema în așa fel încât să se suprascrie reciproc.

Din fericire, recent am rezolvat domeniul de aplicare GraphQL API pentru WordPress. Așadar, știu că sunt capabil să-l delimitez pe deplin, producând o versiune care nu va intra în conflict cu niciun alt cod de pe site.

Asta înseamnă că va funcționa pentru orice combinație de evenimente :

• Dacă pluginul care conține componenta este singurul care îl folosește;
• Dacă API-ul GraphQL pentru WordPress este instalat și pe același site web;
• Dacă pe site este instalat un alt plugin care încorporează și această componentă;
• Dacă două plugin-uri care înglobează componenta se referă la aceeași versiune a componentei sau la altele diferite.

În fiecare situație, pluginul va avea propriul său motor GraphQL autonom, privat, pe care se poate baza pe deplin pentru a-și alimenta blocurile Gutenberg (și nu trebuie să ne temem de niciun conflict).

Această componentă, care va fi numită Private GraphQL API , ar trebui să fie gata în câteva săptămâni. (Am început deja să lucrez la el.)

Prin urmare, recomandarea mea este ca, dacă doriți să utilizați GraphQL pentru a alimenta blocurile Gutenberg în pluginul dvs., așteptați câteva săptămâni, apoi verificați API-ul GraphQL pentru fratele mai mic al WordPress, API-ul GraphQL privat.

Concluzie

Chiar dacă am piele în joc, cred că am reușit să scriu un articol care este în mare parte obiectiv.

Am fost sincer când am spus de ce și când trebuie să utilizați WPGraphQL. În mod similar, am fost sincer în a explica de ce API-ul GraphQL pentru WordPress pare a fi mai bun decât WPGraphQL pentru mai multe cazuri de utilizare.

În termeni generali, putem rezuma după cum urmează:

• Treceți static cu WPGraphQL sau intrați în direct cu GraphQL API pentru WordPress.
• Jucați în siguranță cu WPGraphQL sau investiți (pentru o răsplată potențial demnă) în API-ul GraphQL pentru WordPress.

Într-o notă finală, aș dori ca cadrele Next.js să fie re-arhitectate pentru a urma aceeași abordare folosită de Frontity: unde pot accesa o interfață pentru a prelua datele de care au nevoie, în loc să folosească o implementare directă a unei anumite soluții ( cel actual fiind WPGraphQL). Dacă s-a întâmplat acest lucru, dezvoltatorii ar putea alege ce server de bază să folosească (fie WPGraphQL, GraphQL API pentru WordPress sau o altă soluție introdusă în viitor), în funcție de nevoile lor - de la proiect la proiect.

Link-uri utile

• WPGraphQL: documentație, pagină de descărcare, depozit de coduri
• API GraphQL pentru WordPress: documentație, pagină de descărcare, depozit de coduri
• „Atelierul de integrare WordPress Gatsby”
  Video YouTube cu demonstrație WPGraphQL
• „Introducere în GraphQL API pentru WordPress”
  Video YouTube cu demonstrație a API-ului GraphQL pentru WordPress