CMS fără cap: Gatsby JS cu WordPress

Este cunoscut faptul că WordPress acoperă aproximativ o treime din primele 1 milion de site-uri web din lume, cu o cotă de piață de peste 50% în sistemele de management al conținutului. În 2016, WordPress a decis să introducă un API REST pentru a oferi altor aplicații acces îmbunătățit la conținutul din baza de date WordPress. În consecință, oferind dezvoltatorilor capacitatea de a utiliza WordPress ca un CMS fără cap.

Acest lucru a implicat inevitabil că inginerii nu ar mai fi limitați să folosească stratul de prezentare convențional al WordPress (frontend), ci ar putea acum exploata orice aplicație frontend pentru a-și livra datele. În lumina acestui fapt, majoritatea acestui blog va explora relația dintre WordPress și Gatsby.js în ceea ce privește efectuarea Headless CMS.

O scurtă istorie a CMS

Pe măsură ce facem un pas înapoi pentru a înțelege revoluția Headless CMS, cred că este demn de remarcat să recapitulăm istoria sistemelor de management al conținutului (CMS). În mod tradițional, la începutul anilor '90, paginile web statice erau principala modalitate de a executa site-uri web în care un webmaster edita direct fișiere HTML și le încărca pe un server prin FTP. În cele din urmă, la mijlocul anilor '90, tehnologia web a început să evolueze, iar conținutul a devenit mai dinamic, ducând la apariția primelor sisteme monolitice de management al conținutului.

În esență, un CMS Monolithic este o aplicație software care include tot ceea ce este necesar pentru editarea și publicarea conținutului pe web. Primele dintre astfel de sisteme au fost limitate la întreprinderi precum EpiServer, cu toate acestea, mai târziu au apărut variante open-source precum WordPress, Drupal și Joomla. Restul este istorie, deoarece WordPress a câștigat cea mai mare cotă de piață de-a lungul timpului.

Cu toate acestea, mai târziu, în timpul revoluției smartphone-urilor, dispozitivele mobile au început să afecteze modul în care conținutul web a fost consumat și livrat. Aceasta a fost o provocare pentru CMS-urile monolitice tradiționale concepute pentru a furniza conținut web pentru laptopuri și desktop-uri.

Pentru a atenua acest lucru, a luat naștere designul responsive, care a dus la amenajări de site-uri care s-au adaptat la dimensiunea ecranului. În consecință, aceasta a oferit și o oportunitate de a decupla managementul conținutului de nivelul de afișare. Aici intervin CMS-urile noastre Headless.

CMS-uri fără cap

După cum am menționat anterior, un CMS Headless este unul fără un strat de prezentare. Ca rezultat, conținutul este livrat printr-un API (RESTful sau GraphQL) pentru a separa aplicația frontend care apoi îl prezintă. API-ul face conținutul disponibil oricărui canal și dispozitiv folosind o varietate de instrumente și limbaje de programare cu un nivel mai ridicat de securitate și scalabilitate.

În esență, CMS-ul este decuplat de preocupările de front-end, ceea ce eliberează, la rândul său, dezvoltatorii să construiască experiențe bogate pentru utilizatorii finali, folosind cea mai bună tehnologie disponibilă. Un mod „fără cap” sau „decuplat” este suportat în prezent de majoritatea CMS-urilor, ceea ce a deschis calea site-urilor Gatsby.

Deci, pentru a utiliza un CMS fără cap, va trebui să vă construiți mai întâi site-ul sau aplicația, apoi să utilizați API-ul CMS pentru a vă conecta conținutul.

Execuția WordPress Headless CMS

În ceea ce privește cronologia evenimentelor împărtășită mai sus, am văzut cum WordPress a ajuns să efectueze un CMS Headless. WordPress Conține un API (Application Programming Interface) care vă permite să îl extindeți cu pluginuri (în esență ca „cadru de aplicație”). În special, acest lucru se realizează prin intermediul API-ului REST, așa cum vom face mai târziu.

Cu toate acestea, unul dintre conceptele cheie ale API-ului WordPress este cârligele. Practic, cârligele permit pluginurilor să schimbe funcționalitatea de bază a WordPress. Practic, Hook-urile funcționează astfel încât, atunci când are loc un anumit eveniment în WordPress (de exemplu, încărcarea paginii sau post-editare), WordPress apelează un anumit hook pentru a rula funcția.

Mai exact, cârligele sunt împărțite în „Acțiuni” și „Filtre”. Acțiunile pot fi valorificate pentru a rula anumite funcții PHP în anumite evenimente, deși funcțiile nu trebuie să returneze nimic. În timp ce filtrele pot fi utilizate pentru a rula funcții prin care WordPress trece datele în timpul anumitor evenimente, aceste funcții preluând date ca parametru și returnând o versiune modificată a datelor.

WordPress și API-ul REST

Transferul de stare reprezentativă (REST) ​​se bazează pe protocolul HTTP și oferă o semantică uniformă a interfeței pentru a crea, citi, actualiza și șterge date (CRUD).

În general, execuția REST API în WordPress permite dezvoltatorilor să acceseze datele dintr-o bază de date WordPress de la distanță prin trimiterea și primirea obiectelor JSON (JavaScript Object Notation). În consecință, acest lucru oferă dezvoltatorilor posibilitatea de a crea, citi, actualiza și șterge date WordPress din alte aplicații care nu sunt proiectate cu WordPress. De exemplu, aplicații web JavaScript sau aplicații mobile native.

Cu toate acestea, pe măsură ce înțelegem mai profund relația CMS WordPress Headless cu API-urile REST și Gatsby, va trebui să remarcăm câteva concepte fundamentale ale API-ului WordPress:

• Rute și puncte finale: rutele sunt căi pe care le puteți accesa prin apel HTTP, în timp ce un punct final este o metodă HTTP (cum ar fi obținerea, postarea, introducerea sau ștergerea) mapată la acea rută.
• Solicitare: Când inițiați o solicitare HTTP către o rută REST înregistrată, WordPress va crea automat un obiect de solicitare. Datele care sunt specificate în cerere vor determina răspunsul pe care îl veți primi.
• Răspuns: Un obiect de răspuns este datele pe care le primiți înapoi atunci când faceți o solicitare. Poate cuprinde date solicitate sau mesaje de eroare.
• Schemă: o schemă se referă la structura de date din punctul final. Fiecare punct final poate avea o structură de date ușor sau semnificativ diferită pe care le poate returna. În consecință, o schemă va determina toate proprietățile posibile pe care un punct final poate returna și toți parametrii posibili pe care îi poate primi.
• Clasele Controller: Clasele Controller le permit dezvoltatorilor să gestioneze și să înregistreze punctele finale și rutele, permițându-le în același timp să gestioneze cererile, să utilizeze schema și să genereze răspunsuri.

„Cadrul” React

Pe măsură ce intrăm acum în carnea relației Gatsby.js și WordPress, pentru mai mult context, trebuie să descifrăm acest peisaj tehnologic din mai multe elemente de bază istorice. React este cheia acestei povești, deoarece este biblioteca/cadru JavaScript cu cea mai rapidă creștere. Făcute celebre de Facebook (dezvoltatorii săi de bază), alte site-uri mari folosesc React pentru frontend-ul lor, cum ar fi: Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace și Tesla.

În consecință, deoarece React este o bibliotecă în practică (deoarece încă îi lipsesc caracteristicile notabile ale unui cadru cu drepturi depline), acest lucru înseamnă că și alte „cadre” pot fi proiectate pe deasupra. În consecință, unul dintre acestea este Gatsby.js.

Vă prezentăm pe Gatsby

Potrivit site-ului său părinte, Gatsby.js este un cadru JavaScript gratuit și open-source bazat pe React, care ajută dezvoltatorii să construiască site-uri web și aplicații rapide. În principiu, Gatsby.js generează pagini HTML statice din aplicații pentru încărcarea inițială, apoi continuă ca o aplicație React (SPA) cu o singură pagină.

Atribute Gatsby.js

În aceste circumstanțe, Gatsby exploatează principiile Progressive Web App (PWA) pentru a prelua mai întâi numai elementele necesare, apoi încarcă restul aplicației în fundal mai târziu. În plus, pentru a se asigura că sunt încărcate numai datele necesare, Gatsby folosește limbajul de interogare GraphQL (tot de Facebook) pentru a încărca datele de la sursă. De asemenea, menține o optimizare excepțională a imaginii.

Toate aceste capabilități combinate oferă dezvoltatorilor instrumentele necesare pentru a crea cele mai rapide site-uri web și aplicații web posibile, deoarece încarcă numai HTML, CSS, date și JavaScript esențiale. Deci, odată ce o pagină este încărcată, Gatsby preia resursele pentru paginile legate și, astfel, navigarea pe site se simte destul de rapidă.

De asemenea, deoarece paginile sunt generate la compilare, înainte de plasarea online, nu mai aveți nevoie de servere PHP puternice și puteți servi fișiere statice (HTML, JS și CSS, direct din spațiul de stocare). În plus, deoarece Gatsby este alimentat de React, veți putea structura frumos totul cu componente. Acest aspect modular permite dezvoltatorilor să refolosească ușor componentele.

Alte caracteristici semnificative ale lui Gatsby includ:

• Generator de site static
• Acces offline
• Preîncărcarea paginilor legate
• Memorarea în cache a paginii
• Fără preluare de cod străin
• Exportați ca cod
• Conținut de reîncărcare la cald
• Cod de reîncărcare la cald
• Componentizarea
• Legare de date unidirecțională
• Interogări de date declarative API (GraphQL)
• UI declarativ
• Încărcare progresivă a imaginii
• Încărcare receptivă a imaginii
• Integrarea CSS-ului critic
• Auto-găzduire de font
• Fără server
• Conducte de active
• Extensii CSS (SaSS)
• Sintaxă JavaScript avansată
• Ecosistemul componentelor React

Pluginuri Gatsby

În esență, pluginurile Gatsby sunt în esență pachete Node.js care folosesc API-ul Gatsby. Aceste pluginuri pot adăuga surse de date, pot transforma datele în alte formate și pot adăuga servicii terțe. Deși Gatsby.org menține o bibliotecă de pluginuri care include multe plugin-uri deja realizate, fie de echipa principală Gatsby, fie de terți. În mod ideal, pentru a instala un plugin pentru un proiect Gatsby, dezvoltatorii folosesc managerul de pachete de noduri (NPM) pe terminalul lor UNIX și rulează comanda npm install.

Modul în care vine GraphQL are legătură cu Gatsby.

GraphQL se învârte în jurul ideii că puteți descrie API-ului exact datele pe care le doriți și veți primi exact asta. Ca rezultat, este mai eficient decât REST. În acest scop, Gatsby folosește Webpack și GraphQL. Mai important, cu GraphQL ca limbaj de interogare, totul este definit de partea clientului care execută interogarea, cu clientul indiferent de funcționalitatea insuficientă a aplicației.

Această implementare unică permite dezvoltatorilor să conecteze orice sursă de date la Gatsby. De exemplu, postările pe blog pot proveni din fișiere Markdown, foi Google sau chiar din alt site web WordPress. Prin urmare, oferind o flexibilitate sporită cu livrarea de conținut.

Mecanism Gatsby-WordPress (pluginuri sursă)

Pe măsură ce despachetăm în continuare această relație, trebuie să înțelegem pluginurile sursă. Pluginurile sursă sunt plugin-uri speciale care funcționează în sistemul de date al lui Gatsby. După cum sugerează deja și numele, aceștia sursă date din diferite locații, fie locale, fie la distanță. În consecință, datele sunt apoi transformate în ceea ce Gatsby se referă ca noduri și câmpuri de noduri. Practic, câmpurile de noduri reprezintă o singură bucată de date în interiorul unui nod și, în cele din urmă, aceste noduri pot fi accesate printr-o interogare GraphQL.

În aceeași amploare, prin plugin-uri sursă, Gatsby acceptă zeci de opțiuni CMS fără cap, beneficiind de echipele de inginerie și conținut confortul și familiaritatea interfeței sale de administrare preferate cu experiența îmbunătățită pentru dezvoltatori și beneficiile de performanță ale utilizării Gatsby, GraphQL și React pentru a construi un în față.

Pluginul „Gatsby-source-WordPress” este construit și întreținut de echipa principală Gatsby și extrage date fie de pe site-uri WordPress găzduite de sine, fie de pe WordPress.com. De asemenea, implică autentificarea OAuth la API-ul Word-Press.com și, de asemenea, permite dezvoltatorilor să interogheze imagini receptive.

În esență, acest plugin acceptă toate entitățile din API-ul REST WordPress, cum ar fi postări, pagini, etichete, categorii, media, tipuri, utilizatori, stări, taxonomii, metadate de site și tipuri de postări personalizate. În plus, sunt acceptate și entitățile Advanced Custom Fields (ACF) și informațiile despre limbajul Polylang și WPML, pe lângă alte meta post înregistrate în API-ul REST.

Deci, cu acest plugin, dezvoltatorii pot alege ce rute să preia, deși preia toate punctele finale ale wpjson în mod implicit. Deci, dezvoltatorii pot prelua date de la WordPress cu GraphQL utilizând mecanismul de mai sus.

În practică, instrumentul „Gatsby-source-WordPress” oferă un slug pentru toate postările și alte entități. Și astfel, tot ce trebuie să facă un inginer este să creeze o pagină care apelează funcția „createPage”. Acest lucru este executat în fișierul Gatsby-node.js, de obicei, rulând mai întâi o interogare pentru sursa de date și apoi apelând „createPage” pentru fiecare nod găsit, apoi setând un fișier șablon pentru a fi utilizat ca componentă.

CI/CD și automatizarea lansării aplicațiilor.

Când implementați un CMS WordPress fără cap cu Gatsby, modul în care este efectuată implementarea este extrem de critic. De obicei, astfel de execuții necesită ca implementarea unei aplicații să fie automatizată utilizând Application Release Automation (ARA).

În general, ARA presupune funcții primare:

• Implementarea datelor, codului aplicației și artefactelor.
• Implementarea unor configurații specifice pentru fiecare mediu
• Proiectarea fluxului de lucru pentru automatizarea sarcinilor și a pașilor de implementare.
• În cele din urmă, modelarea mediului și/sau provizorii binare

Deoarece Gatsby produce site-uri statice, este imperativ să configurați o conductă ARA, astfel încât atunci când conținutul este actualizat în WordPress, acesta să poată fi actualizat în mod corespunzător pe site-ul Gatsby. De obicei, implementarea continuă este declanșată numai atunci când codul se modifică, cu toate acestea, în acest caz, este de dorit să o declanșeze atunci când datele se modifică. Deci, pentru aceasta, vă recomandăm să utilizați Netlify deoarece posedă capabilități uimitoare de implementare continuă încorporate și este ușor de configurat.

Interogarea din WordPress folosind GraphQL și gatsby-source-WordPress

Ca o ilustrare, gatsby-source-WordPress funcționează într-un mod în care va prelua mai întâi totul de pe endpoint-ul folosind REST. Apoi va genera un API GraphQl intern pe baza acestor date. Ulterior, va parcurge interogările dvs. și va aduna datele din acel API GraphQL intern. Deci, practic, construcția ta se termină doar cu datele pe care le-ai cerut și nimic altceva.

Avantajele dezvoltării WordPress Headless cu Gatsby.js

Deoarece am abordat dezvoltarea Headless WordPress cu Gatsby, acum putem dezvălui avantajele acestui tip de abordare tehnică. Acest lucru ar trebui, în esență, să vă ghideze decizia dacă îl adoptați sau nu pe Gatsby!

• Primul beneficiu este capacitatea de a avea un site static, pre-rendat. Acesta este cel mai eficient mod de a reda o pagină web și, deoarece Gatsby folosește GraphQL pentru a executa cantitatea minimă de date necesară, aceasta oferă o eficiență suplimentară pentru timpul de după încărcarea inițială.
• Vizibilitate SEO îmbunătățită: Paginile statice sunt ușor de citit de către motoarele de căutare, deoarece totul este preredat și indexabil. Acesta este un lucru pozitiv, spre deosebire de alte mecanisme fără cap în care randarea paginilor cu JavaScript este o problemă privind optimizarea motorului de căutare (SEO).
• Viteză relativ rapidă de dezvoltare: în comparație cu alte abordări fără cap, Gatsby are o modalitate unificată, ușor de înțeles de a prelua date, indiferent de sursă. Acest lucru simplifică destul de mult dezvoltarea, deoarece vă puteți concentra pe site-ul dvs. real și îl lăsați pe Gatsby să se ocupe de majoritatea sarcinilor grele.
• Găzduire mai ieftină: vă puteți găzdui aplicația Gatsby oriunde, deoarece servește doar fișiere statice, reducând astfel cheltuielile de găzduire. În plus, deoarece WordPress este apelat doar în timpul procesului de construire și niciodată în timpul sesiunii utilizator, poate fi găzduit și pe o soluție de găzduire accesibilă.
• Securitate îmbunătățită: în general, generatoarele de site-uri statice sunt extrem de sigure, deoarece nu există o conexiune directă la o bază de date, dependențe, date utilizator sau alte informații sensibile.
• Plugin gratuit: Din perspectiva unui non-dezvoltator, WordPress este destul de ușor de operat datorită pluginurilor disponibile. Cu toate acestea, acest lucru limitează implementarea funcționalităților personalizate. Din păcate, prea multe plugin-uri pot încetini un site, deoarece devine greu și mai greu de redat. O execuție a lui Gatsby ocolește în esență toate aceste blocaje.

Mai multe fațete care vă pot motiva să luați în considerare Gatsby cu WordPress:

• Panoul de administrare WordPress ușor de gestionat.
• Sistem de conectare și autorizare gata de utilizare.
• Cu editorul Gatsby și Gutenberg, puteți construi un generator de site Gatsby cu drag-drop.

Dezavantajele dezvoltării WordPress fără cap cu Gatsby.js

• Limitări de actualizare: atunci când conținutul se modifică de la zero, stabilește restricții cu privire la frecvența cu care se poate actualiza site-ul. În plus, poate dura până la 10 minute pentru a rula Gatsby build dacă site-ul tău conține multe date, ceea ce poate fi o problemă pentru site-urile care se actualizează frecvent.
• Actualizări regulate Hustles: De asemenea, deoarece Gatsby este un generator de site-uri static, acesta nu poate fi doar „editat”, deoarece chiar și modificarea mică a textului va necesita o nouă implementare. Deci, dacă aveți o pagină care necesită multe modificări dinamice de conținut zilnic, acest lucru poate deveni consumator de timp și o agitație.
• Întârzieri: de obicei, trebuie să așteptați câteva minute pentru a vedea modificările conținutului dvs. pe măsură ce sunt difuzate.
• Lipsa previzualizărilor: Spre deosebire de aplicațiile tradiționale WordPress, nu aveți niciun fel de previzualizare în Gatsby. Din păcate, aceasta a fost cea mai mare problemă pe care creatorii de conținut au găsit-o cu Gatsby. Va trebui să compilați totul, probabil cu pipeline Gitlab CI/CD care compilează site-ul și pun totul online.
• Curba de învățare abruptă: în general, dacă doriți să lucrați cu Gatsby și WordPress în același timp, trebuie să fiți relativ familiarizat cu atât limbajele PHP, cât și limbajele JavaScript. Deoarece Gatsby îmbină React și GraphQL, aceasta poate fi o curbă de învățare abruptă pentru mulți.

Gânduri finale.

În concluzie, datorită performanței și avantajelor sale de afaceri, mai multe companii implementează Gatsby ca parte a stack-ului lor de tehnologie. Deși este important să ne amintim că, prin amalgamarea Gatsby cu WordPress, WP devine doar backend, ceea ce înseamnă că veți pierde unele dintre funcționalitățile și abilitățile sale.

Mai mult, dezvoltatorii cu experiență în dezvoltarea WordPress vor găsi pe Gatsby un instrument excelent, cu beneficiile sale moderne de performanță, scalabilitate, securitate și viteză de dezvoltare. Toate acestea, permițându-le în același timp să păstreze interfața de utilizator familiară pentru crearea de conținut oferită de WordPress.

Cu toate acestea, înainte de a iniția această tehnologie, trebuie să luați în considerare întotdeauna specificațiile și obiectivele proiectului. De exemplu, dacă se pune accent pe scalabilitate, performanță, viteza de dezvoltare, ciclu lung de viață, Gatsby va face. Cu toate acestea, dacă accentul este de a avea flexibilitate și instrumente îmbunătățite pentru creatorii de conținut care nu sunt programatori, cu conținut actualizat la o secundă sau la un minut, atunci puteți lua în considerare o abordare alternativă.