DE{CODE}: Headless 101 pentru dezvoltatorii WordPress

Dezvoltarea fără cap poate fi mai puternică și chiar mai distractivă decât dezvoltarea tradițională WordPress. Cu toate acestea, cu atât de multe opțiuni noi în această stivă în curs de dezvoltare, care este cea mai bună modalitate de a începe? Acest atelier îi va ghida pe constructori prin instalarea și optimizarea unui proiect WordPress pentru headless, până la șablonarea primei pagini într-un frontend decuplat.

Diapozitive de sesiune

Transcriere text integral

GRACE ERIXON : Bun venit la Headless 101 pentru dezvoltatorii WordPress. Numele meu este Grace Erixon și sunt avocat asociat pentru dezvoltatori aici la WP Engine. Mi se alătură Steve din Haus. Astăzi, vă vom oferi o introducere rapidă despre ce este WordPress fără cap și cum puteți începe să îl utilizați.

Deci, pentru a înțelege ce este o arhitectură web WordPress fără cap, este important să ne asigurăm că suntem cu toții pe aceeași pagină despre cum arată o arhitectură tradițională WordPress. În mod tradițional, un CMS precum WordPress ar gestiona atât front-end-ul, cât și back-end-ul unui site web.

Într-o arhitectură tradițională, editorul creează și gestionează conținut, cum ar fi postări de blog și pagini din interiorul WordPress. Dezvoltatorul scrie cod pentru a controla modul în care arată și funcționează site-ul folosind PHP și API-ul tematic al WordPress. Apoi WordPress generează pagina HTML care este trimisă vizitatorului.

În această arhitectură CMS cuplată, WordPress oferă editorilor capacitățile de gestionare a conținutului. Și, de asemenea, este responsabil pentru difuzarea paginilor HTML vizitatorilor site-ului. Un CMS fără cap folosește o arhitectură decuplată în care partea frontală și cea din spate sunt gestionate separat. Într-o arhitectură fără cap, editorul încă creează și gestionează conținut în WordPress, la fel ca într-o arhitectură tradițională WordPress.

Dezvoltatorul scrie cod pentru a controla modul în care arată și funcționează site-ul în JavaScript, precum și folosind WPGraphQL sau API-ul REST pentru a extrage datele din WordPress. Un cadru precum Faust.js, Next.js, Nuxt.js sau SvelteKit este adesea folosit pentru a alimenta această aplicație frontend. Apoi, aplicația JavaScript front end generează și servește paginile HTML care sunt trimise vizitatorului site-ului.

Spre deosebire de o arhitectură tradițională, WordPress nu mai este responsabil pentru generarea de pagini HTML. Deci, interacțiunea de schimb de conținut între back-end WordPress și aplicația JavaScript front-end are loc prin stratul API. Cele două opțiuni pentru stratul API sunt API-ul REST WordPress sau WPGraphQL.

API-ul REST vine la pachet cu WordPress. Cu toate acestea, modelul de acces la date pe care îl necesită poate fi lent, deoarece REST necesită ca fiecare resursă să aibă propriul punct final. De exemplu, ar fi nevoie de mai multe călătorii dus-întors pentru a reconstrui o postare complet modelată. Dacă doriți să obțineți conținutul, autorul și categoria unei postări, ar fi nevoie de trei apeluri API separate.

În schimb, WPGraphQL ne permite să cerem conținutul, autorul și categoria unei postări într-o singură solicitare. Din această cauză, WPGraphQL este stratul nostru API preferat. WPGraphQL este un plugin gratuit care oferă o schemă extensibilă GraphQL și API pentru site-ul dvs. WordPress. WPGraphQL este mai rapid decât API-ul REST, deoarece primește datele exacte cerute și are ca rezultat mai puține funcții executate prin optimizarea interogărilor, mai puține descărcari de date, încărcare mai eficientă a datelor și mai multe resurse care sunt incluse într-o singură solicitare.

O arhitectură fără cap oferă dezvoltatorilor libertatea de a alege din orice stivă de tehnologie front-end, cadrele JavaScript fiind cele mai populare. Unele dintre cele mai populare cadre JavaScript front-end includ React, Vue.js și Svelte. Cadre noi sunt lansate tot timpul, așa că această listă nu este deloc cuprinzătoare.

Multe dintre aceste cadre JavaScript sunt folosite împreună cu cadre meta care adaugă soluții pentru lucruri precum rutarea, randarea pe server și multe altele. React este folosit împreună cu Next.js, Vue.js este folosit împreună cu Nuxt.js și Svelte este utilizat împreună cu SvelteKit. Gatsby este un alt meta cadru popular.

WP Engine a dezvoltat Faust.js, un cadru JavaScript construit pe React și Next.js. Faust a fost creat special pentru a sprijini aplicațiile web WordPress fără cap. Acceptă autentificarea și previzualizările postate din cutie, oferă cârlige React convenabile încorporate pentru accesarea datelor WordPress și multe altele.

Așa că am vorbit despre ce înseamnă o arhitectură WordPress fără cap și despre tipurile de tehnologie pe care le-ai folosi. Dar haideți să atingem rapid de ce ați alege chiar și fără cap. WordPress în sine este un CMS greu și folosește PHP, care nu este un limbaj rapid. Headless WordPress folosește limbaje adoptive prin JavaScript și încarcă numai fișierele necesare prin apeluri API. Este mult mai ușor, astfel încât site-ul dvs. se va încărca mai repede.

WordPress fără cap reduce, de asemenea, riscul pentru conținutul dvs., deoarece datele dvs. sunt separate de livrarea dvs. frontală. Este mai puțin expus atacurilor web. Și principalul beneficiu este că arhitectura WordPress fără cap permite editorilor să beneficieze în continuare de experiența extraordinară de publicare pe care o oferă WordPress, permițând totodată dezvoltatorilor și vizitatorilor site-ului web să profite de capacitățile tehnice pe care aplicațiile JavaScript moderne le aduc la dispoziție.

Acum, să cercetăm codul unui site real fără cap. Am preînregistrat o prezentare a noului site WordPress fără cap Atlas Blueprints. Noua funcție Blueprints din Atlas oferă o modalitate foarte ușoară de a pune în funcțiune un site WordPress complet fără cap. Acestea vin cu cod de pornire, pluginuri, modele de conținut și structură a paginii pentru ca aplicația să declanșeze mai repede.

Deci, haideți să creăm un nou site Blueprint, astfel încât să ne putem arunca în cod. Din interiorul tabloului de bord al WP Engine, vom merge la Atlas. Faceți clic pe Creare aplicație. Selectați Începeți cu Blueprint. Și apoi vom selecta ce plan vrem să folosim. O să aleg modelul portofoliului.

Apoi vă veți conecta contul WP Engine la contul GitHub și veți clona acel plan într-un nou depozit. Acest lucru va dura câteva secunde pentru a construi. În cele din urmă, veți selecta doar numele depozitului pe care tocmai l-ați creat, regiunea de care vă aflați cel mai aproape, apoi faceți clic pe Creare aplicație.

Acum, dacă faceți clic pe URL-ul Atlas, putem verifica cum arată site-ul nostru WordPress fără cap. Suntem interesați în mod special de pagina Postări. După cum puteți vedea, site-ul atrage toate cele mai recente postări în această pagină Blogul nostru. Și fiecare postare are, de asemenea, propria pagină de vizualizare individuală. Dar de unde vin toate aceste date?

Dacă revenim la tabloul de bord WP Engine, vom vedea un buton pentru WP Admin. Există partea din spate pentru site-ul nostru WordPress fără cap. Dacă dau clic pe Postări, veți vedea aceeași listă ca și aplicația web. Acum, putem deschide depozitul GitHub în care a fost clonat Blueprintul nostru. Și să clonăm acel repo în mediul nostru local.

Apoi voi deschide acest repo în Visual Studio Code, editorul meu de cod preferat. Explorând directorul proiectului, fișierul pentru pagina de blog poate fi găsit la SRC, pagini, postări, Index.js. Acest proiect este construit folosind React, Next.js, Faust.js și WPGraphQL. Dacă nu sunteți familiarizat cu React sau chiar cu JavaScript, atunci acest lucru ar putea părea confuz la început.

În prima secțiune, fișierul doar importă lucrurile de care are nevoie din surse interne și externe. A doua secțiune care definește câmpurile de prepasare post nodurile este cea în care este listată fiecare parte de date de care avem nevoie. Rularea acestui lucru prin prepass ne asigură că datele sunt acolo atunci când avem nevoie de ele și că nu apar solicitări în cascadă.

Apoi avem funcția de pagină. La început, este doar colectarea datelor de care avem nevoie în câteva variabile diferite, și anume, setările generale și o listă paginată de postări. Etichetele din interiorul instrucțiunii return sunt codul care va fi redat vizual pe pagina web. În primul rând, avem componenta pentru antet. Apoi, în interiorul acestei componente principale, avem o componentă antet de intrare și asta este ceea ce afișează titlul mare care spune Ultimele postări în partea de sus a paginii.

În cele din urmă, ajungem la componenta post, care acceptă lista paginată de postări ca parametru. Să ne uităm la ce face componenta post cu aceste informații. Aici se parcurge fiecare postare din lista de postări pe care a primit-o. Pentru fiecare postare, afișează vizualizarea ca un card pe pagina celei mai recente postări. Aceasta constă mai întâi dintr-o componentă de imagine prezentată înfășurată într-un link către pagina individuală a postării de blog, un titlu al postării și o componentă de informații despre postare constând din data și autorul postării.

Înapoi la fișierul Index.js care afișează toate postările, terminăm acest lucru afișând componenta Încărcare mai mult în partea de jos a paginii pentru a prelua mai multe postări, dacă este solicitat, și un subsol. Ultima funcție, getStaticProps, este o funcție statică de generare a site-ului Next.js care îi spune să pre-rendeze această pagină în momentul construirii folosind elementele de recuzită returnate de funcție. Si asta e.

Mulțumim lui Blueprints pentru gestionarea configurației Headless pentru noi. A fost simplu să detaliezi ceea ce intră în pagina de postare pentru a obține date din backend-ul WordPress folosind WPGraphQL și pentru a afișa postările folosind componente React. Vă mulțumesc pentru acord. Mă puteți găsi pe Twitter @graceerixon.

Consultați developers.wpengine.com pentru mai mult conținut despre WordPress Headless. Avem un tutorial despre cum să construiești primul tău site WordPress Headless de la zero folosind Faust.js și lucrăm la o serie de conținut Headless 101 chiar acum. Puteți obține toate instrumentele pe care le oferă Atlas dacă vă înscrieți pentru un cont Sandbox gratuit. Acum îi voi transmite lui Steve pentru a vorbi mai multe despre motivul pentru care Haus a ales WordPress Headless pentru proiectul lor leoburnett.com.

STEVE SCAVO: Mulțumesc, Grace. Bună, sunt Steve Scavo, CTO la Haus. Suntem un studio și o agenție de tehnologie creativă din Los Angeles, California. Această discuție este intitulată în mod corespunzător Headless 101 pentru dezvoltatorii WordPress. Și din punct de vedere clar, nu sunt un dezvoltator WordPress de profesie, dar cred că asta face parte din frumusețea unei arhitecturi fără cap.

Deci am fi putut numi cu ușurință acest Headless 101 pentru dezvoltatorii non-WordPress care trebuie să folosească WordPress. Acesta ar fi putut fi un titlu la fel de potrivit. Asta e frumos la fără cap. Este o victorie, un câștig-câștig din toate părțile, după cum veți vedea.

Deci de ce fără cap? Există atât de multe motive la nivel înalt despre care am putea vorbi, dar cred că acest fel de a vorbi despre exemple reale de producție și exemple din lumea reală despre când strălucește este de mare ajutor. Și aș vrea să prezint un proiect pe care l-am făcut pentru Leo Burnett folosind fără cap sub o arhitectură fără cap. Pentru context, Leo Burnett este o agenție de publicitate cu istorie din Chicago, dar are multe birouri în întreaga lume și la nivel global. Deci au mult conținut, multă muncă.

Vechiul site funcționa pe o singură temă WordPress. A fost într-adevăr fragmentat, cam lent, nu a funcționat bine. A fost dificil de actualizat și nu prea arăta genul de cachet și brandingul pe care Leo Burnett dorea să le transmită. Deci, cu asta am început să lucrăm din perspectiva designului. Și am ales fără cap pentru a le moderniza cu adevărat stiva.

Am vrut doar să se simtă viu și proaspăt și să aibă acel tip de capacitate pe care trebuie să o avem pentru a pune împreună o experiență de utilizator și o interfață de utilizare minunate. Am vrut să le creștem puterea de publicare. Am vrut să creștem cadența cu care pot publica conținut. Am vrut să restabilim identitatea mărcii și să avem o interfață de utilizare și o interacțiune, sentimentul site-ului web care într-adevăr emana Leo Burnett și toate aceste mici atingeri și un fel de puncte editoriale și tipografice și de interacțiune pe care au vrut să le transmită.

Și am vrut să pregătim baza de cod și site-ul web pentru viitor. Nu am vrut doar ca site-ul să fie relevant pentru următoarele 12 luni. Vrem să fie relevant pentru următorul deceniu, poate. Și cred că această arhitectură fără cap, această stivă fără cap într-adevăr face asta.

Deci, una dintre problemele inițiale cu headless este că există întotdeauna o mulțime de decizii în ceea ce privește găzduirea și implementarea și infrastructura și a fost întotdeauna un punct de durere uriaș. Deci, aceste decizii de stivă au fost întotdeauna lăsate la latitudinea dezvoltatorului. Și vânezi și te gândești, OK, ce aplicație terță parte, poate CI/CD trebuie să folosești? Vom găzdui asta pe AWS? Cum facem asta? Ce servicii? Și apoi implementezi astfel de potențial – aceste soluții ad-hoc în jurul acestui flux.

Ei bine, platforma Atlas și WordPress Engine Atlas rezolvă cu adevărat acest lucru. Aici intră în joc. Am ales să mergem cu Atlas din toate aceste motive și au această infrastructură de servicii gestionată. Ei standardizează conducta CI/CD. Chiar nu trebuie să te gândești la asta.

Există migrări de date între medii care se reduc în esență la un flux cu un singur clic. Din punct de vedere istoric, aceasta a fost întotdeauna o mare problemă cu trecerea de la QA la montaj la producție. În esență, WordPress Engine și platforma Atlas au redus acest lucru la un singur clic.

Și apoi există doar această oboseală în jurul microserviciilor și DevOps. Există doar o sarcină cognitivă grea despre cât de mult trebuie să vă gândiți și să susțineți și să fiți conștient de asta în calitate de dezvoltator și să mențineți totul în funcțiune. Acestea sunt toate lucrurile pe care platforma Atlas le ia cu adevărat din mână și le rezolvă într-un mod benefic.

Așa că haideți să vorbim despre unele dintre dinamicile pe care cred că headless le promovează cu adevărat și le subliniază cu adevărat. Primul pilon aici – sunt trei. Primul pilon este experiența dezvoltatorului. Ne permite să alegem instrumentul potrivit pentru muncă. Și când spun noi, mă refer la dezvoltatori.

Ne permite să alegem o stivă în care vrem să scriem cod. Și asta este, pentru noi, asta este la Haus, acesta este Next.js și React. Next.js este doar un cadru minunat în jurul unor convenții foarte frumoase pentru rutare și performanță și arhitectura aplicației. Și am vrut, de asemenea, să implementăm un sistem de proiectare, și nu doar un sistem de design vizual, ci un sistem de proiectare codificat. Acesta este ceva care menține aplicația noastră consistentă, testată, frumoasă.

Interacțiunile sunt consistente. Ne permite să construim noi pagini și funcții în acel ecosistem și în viitor și să păstrăm și să menținem această consistență. De asemenea, ne permite să scriem cod expresiv declarativ, iar React îl aprobă ca bibliotecă. Dar credem și în acel stil de a scrie ca o echipă. Ne permite să alegem acea stivă pentru noi pe front end, în timp ce poate un site WordPress tradițional bazat pe teme, nu avem cu adevărat același lux.

De asemenea, avem nevoie de mult spațiu creativ. Puteți vedea când vizitați leoburnett.com, există tranziții frumoase ale paginilor. Există – nu suntem legați de stiva tradițională WordPress cu privire la modul în care ar trebui să fie redate lucrurile. WordPress nu mai este responsabil de redarea frontend-ului.

Marginea noastră este practic nelimitată. Ne putem alege bibliotecile de animație. Putem alege modul în care componentele noastre interacționează între ele. Este un beneficiu imens din partea DX.

Experiența de administrare este ridicată și cred că am optimizat asta pentru că nu ne-am îndepărtat niciodată de vechea lor familiaritate. Nu există nicio trecere în backend. Am trecut de la WordPress la WordPress. Nu a trebuit să exportăm date și să scriem scripturi pentru a trece într-un alt sistem proprietar. Deci familiaritatea este uriașă. Am vrut să menținem acest tip de flux pentru administratorii actuali ai leoburnett.com.

Adopție și documentare – dacă petreceți cinci minute pe web, probabil că ați atins un back-end WordPress și acest lucru pur și simplu nu poate fi exagerat. Leo Burnett are, de asemenea, o mulțime de puncte de conținut foarte specifice și câmpuri personalizate. WordPress oferă asta și vă oferă această putere, dar am reușit să implementăm pluginul Advanced Custom Fields, care este o convenție foarte frumoasă în ceea ce privește ajustarea interfeței de utilizare admin pentru a o face cu adevărat prietenoasă și utilizabilă. Deci a fost o victorie în experiența de administrare.

Acum, desigur, al treilea pilon este experiența utilizatorului. Este ceea ce contează cu adevărat. Utilizatori, cred că la fel cum credem că aplicațiile web de la Haus ar trebui să se simtă ca niște aplicații native, nu ar trebui să existe renunțare. Cred că și utilizatorii apreciază cu adevărat asta.

Sunt fără sudură. Sunt receptivi. Se simt doar bine. Și cred că am vrut ca Leo Burnett și toate aplicațiile noastre să se simtă așa. Posibilitatea de a alege stiva pe care o dorim pe front-end ne permite să facem asta.

Aplicațiile native sunt în mod inerent decuplate de infrastructurile lor de conținut back-end, la fel și aplicațiile noastre web. Și asta promovează Atlas. Aceasta este ceea ce promovează arhitectura fără cap în general. De asemenea, promovează performanța. Ne putem reda universal interfața de utilizare. Aceasta înseamnă că încărcarea inițială este pe partea serverului. Și după aceea, clientul preia controlul.

Există o mulțime de beneficii aici. Una este că face motoarele de căutare fericite. Sunt conținut pe partea serverului. E rapid. De asemenea, ne permite să redăm practic instantaneu pagina următoare și să facem acele solicitări pe baza a ceea ce este în fereastra de vizualizare o singură dată.

Pentru Leo Burnett, în ceea ce privește API-ul de conținut pe care am ales să-l consumăm, am configurat un punct final GraphQL. Asta înseamnă că revin încărcături mai slabe. Definim în mod explicit exact conținutul de care avem nevoie. Există mai puțină hidratare după randarea de partea serverului în randarea de partea client.

Asta înseamnă mai puțin cod care vine prin cablu, mai puțin răspuns, timpi de răspuns mai rapid. Este cu siguranță o victorie și aș sugera că, dacă intenționați să treceți într-un flux de lucru Atlas sau într-un flux de lucru fără cap, să aruncați o privire atentă la utilizarea API-ului GraphQL față de ceva de genul unui API REST.

Și din perspectiva unui utilizator, aceștia văd conținut proaspăt, în timp util. Acesta este un flux de publicare care este optimizat pentru previzualizarea conținutului. Este optimizat pentru preluarea rapidă a conținutului în scenă și previzualizări și apoi promovarea acestuia în producție. Administratorii de la Leo Burnett sunt extrem de mulțumiți de cât de ușor este actualizarea conținutului și asta îi face pe utilizatori fericiți.

Care este rezultatul? Acesta este doar un fel de a rula totul. Sunt dezvoltatori inspirați, administratori productivi și utilizatori fericiți. Aceasta este triada și speranța pe care cred că toate echipele de dezvoltare web se străduiesc cu adevărat.

Când dezvoltatorii sunt inspirați, folosesc un set optimizat de instrumente. Pur și simplu se simte bine. Sunt fericiți. Ei scriu un cod mai bun.

Administratorii știu că produc conținut într-un ecosistem frumos. E rapid. Se livrează rapid. Iar utilizatorii văd acel conținut actualizat și se confruntă cu un front end modern, frumos, bine funcțional și optimizat.

Cred că s-o închei – doar câteva gânduri finale pe care mi-ar plăcea să le ții cont. Cred că briefului, în sine, întotdeauna lipsește limbajul. Cred că prea des vorbim doar despre, hei, construiește-mi un site frumos. Construiește-mi un site uimitor. Vreau să arate și să se simtă – și am făcut toate aceste recenzii cu clienții.

Și toată lumea devine entuziasmată, apoi vine V1 și este lansat. Și apoi oamenii care trebuie să preia acel site sunt ca, mi-ai dat mizerie. Cum să am grijă de asta? Este un flux ad-hoc pe care l-ați conceput?

Nu doriți să construiți un site web frumos și să predați o povară. Suntem foarte mândri aici, la Haus, să nu facem asta. Și cred că ceea ce este minunat la Atlas și Atlas ca platformă este că rezolvă asta.

Vă oferă încrederea că expediați un ecosistem și un sistem de publicare web care are sens din punct de vedere al infrastructurii și al implementării codului. Oferă dovadă documentată echipei IT și echipei de inginerie sau echipei de marketing că știți ce faceți și că acum sunt pe mâini bune cu acest nou site web pe care l-ați creat pentru ei.

Pentru că nu uitați, nu construim doar un site web. Stabilim un sistem de publicare a conținutului, iar acest lucru este esențial de înțeles și de recunoscut încă din prima zi. Și din nou, aici intră în joc Atlas.

Așa că sper că această mică informație te va ajuta să concepi strategic stiva ta fără cap în viitor. Dacă aceasta este direcția pe care doriți să o luați, vă încurajez să aruncați o privire la Atlas. Sper că v-a plăcut sesiunea și vă mulțumesc foarte mult.