DE{CODE}: Când să alegeți Headless pentru clienți

Când un client are cerințe de performanță și securitate, când ar trebui o agenție să aleagă WordPress tradițional sau WordPress fără cap pentru job? Aflați mai multe în această sesiune DE{CODE}, care prezintă un grup de experți din agenții care analizează beneficiile, constrângerile, oportunitățile și compromisurile de a deveni fără cap.

Diapozitive de sesiune

Transcriere text integral

HASHIM WARREN: Bună, bine ați venit la panoul nostru, Când să alegeți WordPress fără cap pentru clienți. Deci, numele meu este Hashim Warren și sunt Managerul de Marketing de Produs pentru Atlas, soluția noastră pentru WordPress Headless. Și una dintre primele întrebări pe care le-am primit de la oameni când adoptă sau doresc să adopte WordPress Headless, este când ar trebui să folosesc WordPress tradițional, totul într-un singur WordPress și când ar trebui să folosesc WordPress Headless.

Deci, dacă am un client care are cerințe de performanță și securitate, cum ar fi la ce ar trebui să mă gândesc în ceea ce privește adoptarea sau alegerea Headless sau WordPress tradițional. Și, de asemenea, dacă aleg Headless WordPress, la ce să mă aștept, la ce mă bag aici. Așa că astăzi avem un panou excelent cu experiență atât cu proiectele WordPress tradiționale, cât și cu proiectele WordPress Headless, care vor putea răspunde la unele dintre marile întrebări pe care știu că le aveți mulți dintre voi.

Așa că astăzi îl avem alături de mine pe Jonathan Jeter, care este directorul de producție tehnică la Click Here Labs. Îl avem și pe Stephen Brooks, directorul de tehnologie la Springbox. Îl avem și pe James Squires, Chief Technology Officer la spațiul 150. Și îl avem și pe Tayo Onabule, Managing Director al Drewl.

Așa că vreau doar să aduc panelul chiar acum, ca să putem începe cu această conversație. Deci, să începem conversația în acest fel. Spune-mi doar ce anume te-a determinat pe tine personal, sau pe agenția ta, să fii interesat de WordPress Headless în primul rând. Și Jonathan poți să ne începi?

JONATHAN JETER : Sigur. Așa că suntem interesați să lucrăm în spațiul Headless de ceva vreme. Și principalul motiv pentru care ne-a interesat a fost pentru că am vrut să creăm proiecte mai mari care să integreze date din mai multe surse. Și API-ul WordPress nu era încă acolo. Așa că lucram la diferite moduri de a prezenta stratul frontal, utilizând în continuare conținutul din WordPress. Și așa, practic, asta am făcut de aproximativ cinci până la șapte ani, încercând să ne dăm seama care a fost cel mai bun mod de a face asta.

Și acum este mult mai ușor decât a fost, evident că există mult mai multe – există o gamă largă de opțiuni în ceea ce privește modul în care o vei face. Și așa, am văzut spațiul crescând și suntem foarte încântați de unde se duce. Aceasta

HASHIM WARREN: Minunat. Și Stephen, ai o poveste asemănătoare? Ce anume te-a determinat pe tine sau agenția ta să te interesezi de WordPress Headless?

STEPHEN BROOKS : Da, așa că suntem în spațiul Headless din aproximativ 2015, ocupându-ne în mod tradițional de platforme CMS bazate pe jam. În ultimii câțiva ani, a fost dificil să se confrunte cu unele echipe de marketing care lucrează în interiorul unui sistem de blocaj, doar din cauza schimbării paradigmei în introducerea conținutului, spre deosebire de o abordare de tip post și pagină.

Am încercat, la fel ca Jonathan, să folosim API-ul WordPress. E puțin cam greoi, nu îți oferă exact ceea ce ai nevoie tot timpul. Ori de câte ori WP Engine a menționat Atlas și a vorbit despre tehnologiile de bază, a fost sărutul bucătarului cu ceea ce am făcut în mod tradițional în spațiul de gem.

Așa că acum este o conversație cu adevărat ușoară cu clienții noștri, deoarece aproape toți agenții de marketing au experiență de lucru în interiorul WordPress, dar dezvoltatorii beneficiază de avantajul suplimentar al unei soluții Headless. Astfel, obțineți reducerea riscurilor de securitate, precum și doar câteva dintre interacțiunile de vârf cu un strat de prezentare bazat pe React. Deci acesta a fost adevăratul nostru șofer aici recent.

HASHIM WARREN: E minunat. Tayo, ne poți spune povestea ta și, pentru a continua cu asta, poți să ne spui despre convingerea editorilor să adopte WordPress Headless?

TAYO ONABULE : Da. Deci, cred că, în cazul nostru, am avut o intrare ceva mai recentă și puțin diferită în spațiul WordPress Headless. Unul dintre factorii de bază pentru noi este unul dintre clienții noștri Android Authority, care are o acoperire destul de largă. În momentul de față, un fel de aluzie în jurul valorii de tipul de 20 de milioane de vizitatori lunar.

Și nevoile lor sunt într-un fel destul de simple. Au nevoie de un SEO foarte bun, cum ar fi cel mai înalt nivel. Și au o mulțime de concurenți foarte competenți în jurul lor. Deci da, SEO foarte grozav, performanță foarte mare și experiență de lectură cu adevărat grozavă pentru toate articolele pe care le publică.

Deci Headless a fost într-adevăr – a apărut într-adevăr pentru noi ca parte a conversației, exact când încercam să facem tot ce puteam pentru a găsi o modalitate de a face site-urile lor WordPress existente să răspundă tuturor acestor nevoi. Chiar la maxim, practic. Și Headless, mai întâi a fost cazul în care am făcut niște cercetări și am spus: o, ei bine, poate că am putea, poate să încercăm asta.

Și am intrat din ce în ce mai mult în ea și am trecut prin procesul de convingere a echipei. Dar, pe măsură ce am ajuns mai departe în întreaga dezvoltare, am început să realizăm că, da, a răspuns la toate aceste întrebări principale, cum ar fi performanța SEO și o experiență, dar ne-a oferit și o flexibilitate completă pe parcursul anilor. pe.

Am lansat, cred că a fost luna mai a anului trecut, așa că venim de fapt la aniversarea asta. , Dar da, de la acea lansare am reușit să construim un număr mare de integrări în site. Toate acestea ar fi fost considerabil mai dificile dacă am fi fost pe WordPress monolitic sau toate într-un singur WordPress. Acea flexibilitate pe care ți-o oferă este unul dintre lucrurile pe care le-am spus Autorității Android pe care le-am avea, dar nu cred că mi-am dat seama de amploarea și libertatea pe care o oferă, practic.

HASHIM WARREN: E minunat. Așadar, până acum am auzit despre performanța SEO, flexibilitate pentru dezvoltatori, flexibilitate în ceea ce privește ce tip de proiect, de asemenea, editorii putând rămâne cu un CMS pe care îl cunosc. Jimmy, experiența ta se potrivește cu toate acestea sau ai ceva de adăugat în ceea ce privește ceea ce te-a făcut pe tine sau agenția ta să fii atras de WordPress Headless?

JAMES SQUIRES: Da, cred că multe dintre acele lucruri le împărtășim, de asemenea. Singurul lucru pe care probabil l-aș adăuga că poate că va apărea este puțin egoist la început, dar voi ajunge acolo și de ce este un lucru bun. Dar, într-adevăr, pentru noi, a fost într-adevăr motivat de satisfacția dezvoltatorilor.

Am venit în mare parte dintr-un cadru bazat pe React și React, intrând într-un fel în WordPress. Iar clienții noștri au cerut WordPress din ce în ce mai mult, dar inginerii noștri nu sunt chiar atât de mulțumiți să realizeze dezvoltarea bazată pe teme în cea mai mare parte. Încă facem asta atunci când există încă aplicații în care acest lucru are foarte mult sens, dar dacă sunteți dezvoltatori sunteți mulțumiți de produs și de ceea ce construiesc, constat că rezultatul este de multe ori, obțineți o experiență stelară, astfel încât este un real beneficiu pentru clienții noștri, chiar dacă un fel de salt în ea a fost într-adevăr centrat pe ceva pe care inginerii noștri și-au dorit să facă.

HASHIM WARREN: E minunat. Unul dintre lucrurile pe care mulți oameni care urmăresc asta le-au auzit în cadrul conferințelor, diferența dintre dezvoltarea bazată pe teme pentru WordPress și dezvoltarea bazată pe componente. Poate cineva să vorbească despre asta? Beneficiile adoptării unei abordări bazate pe componente atunci când construiești site-uri web?

TAYO ONABULE: Da, chiar mi-ar plăcea să intru în asta, de fapt. La fel, sunt sigur că avem cu toții exemple în acest sens, dar cred că unul dintre cele mai satisfăcătoare lucruri care se întâmplă atunci când lucrezi cu biblioteci JavaScript, cum ar fi React, oricum din experiența noastră, este da, așa cum spui, acces la acest tip de stil de construcție bazat pe componente.

Și înseamnă că, pe de o parte, puteți împărți un întreg design de site în aceste părți componente care sunt mult mai flexibile. Deci, să spunem ca exemplu, este posibil să aveți un bloc pe o pagină care are două stiluri diferite. Unul, unde imaginea este în partea stângă și textul este în partea dreaptă, să spunem. Doar ca un fel de exemplu simplu. Și React, acesta este un caz în care aveți un bloc cu un modificator, în esență, pentru a spune doar, întoarceți ordinea textului și a imaginii.

Când vorbim de monolitic, în esență ești doar, da, poate începi pe aceeași bază, dar foarte repede trebuie să le despărțizi pe cele două și acum ai două lucruri separate. Și schimbările, într-o oarecare măsură, trebuie să fie răspândite în două lucruri separate. Și acest tip de concept înseamnă că, pe măsură ce intri în utilizări la scară din ce în ce mai mare pentru front-end-urile Headless, acea flexibilitate și consecvență pe care le poți avea rulând pe un întreg site, în toate utilizările unei anumite componente, înseamnă că dezvoltarea , după cum a spus James mai devreme, este mult mai satisfăcător pentru dezvoltatori.

Este o experiență mult mai plăcută. Puteți spune cu adevărat că React a fost conceput pentru a maximiza producția dezvoltatorilor și este și este că, din nou, așa cum spune James, toate acestea sunt transmise clientului. Pentru că cred că îți poți da seama când ceva a fost făcut cu dragoste și plăcere în el, rezultă întotdeauna într-un fel de rezultate mai bune.

STEPHEN BROOKS: Da, nu doar atât, Tayo. Dar există și alte beneficii grozave ale acestuia. Vreau să spun că te-ai dat peste cap pentru piesa de satisfacție a dezvoltatorului, dar dacă te uiți la dezvoltarea tradițională, bazată pe șabloane, spre deosebire de o dezvoltare bazată pe componente, testarea unitară, corect. Este foarte dificil să implementezi orice tip de testare unitară în cadrul unei abordări bazate pe teme. Cu o componentă, boom, este acolo pentru tine.

Dar vreau să adaug un punct la asta, dar nu este neapărat pentru dezvoltatori, ci mai mult pentru proprietarii de afaceri. De obicei, cu o abordare bazată pe componente, nivelul dvs. de efort scade semnificativ față de o anumită pagină de temă, deoarece componentele dvs. le veți reutiliza peste tot, corect. Și nu necesită un timp suplimentar de tastatură, tastare, pentru a merge și a adăuga acel bloc suplimentar oriunde altundeva merge. Îl construiești doar o dată. Ori de câte ori îl consumi, îți hidratezi corpul. Bum, ai terminat. E atât de frumos, atât de rapid. E minunat.

JONATHAN JETER: Și a trebuit să ne pregătim personalul creativ, corect, pentru că sunt atât de obișnuiți să le placă, OK, acest site are 5 șabloane, sau acesta este orice. Suntem ca, nu, nu scăpăm de asta, nu. Și așa am ajuns să-l sunăm. Doar proiectați pagina chiuvetei de bucătărie, dreapta, o pagină cu totul pe ea, corect, și o vom construi de acolo. Așa că da, a făcut dezvoltarea mult mai ușoară, dar a trebuit să instruim personalul la nivel general pentru a ne asigura că înțeleg ce facem și cum îl construim.

JAMES SQUIRES: Da, chiar și în operațiuni. Adică, sa schimbat modul în care propunerile noastre pentru clienți sunt modelate atunci când facem asta. Vorbim despre cantitățile de blocuri și despre modul în care le construim, spre deosebire de șabloane. Și asta este doar o astfel de schimbare de paradigmă, cred, pentru unii, mai ales în partea de marketing, la care să se gândească – aveți pagini nesfârșite de diferite tipuri de blocuri. Sunt de fapt aceste blocuri și componente de bază și ceea ce construim și stabilim domeniul de aplicare.

TAYO ONABULE: Și doar o ultimă bucată despre asta. Și cred că menționarea propunerilor este un punct foarte bun, deoarece procesul Headless schimbă în mod masiv orice estimări pe care le-ați putea avea despre ceea ce va lua o funcție sau va avea un aspect nou de pagină. Faptul este că scade foarte constant în timp. Cu cât biblioteca dvs. de componente este mai largă, cu atât este nevoie de mai puțin pentru a adăuga un stil suplimentar sau ceva de genul acesta, pentru a modifica un stil pe întregul site, pentru a adăuga un nou aspect de pagină. Toate aceste lucruri devin din ce în ce mai ușoare.

Și cred că este îmbucurător pentru toată lumea, să fiu sincer.

HASHIM WARREN: Deci, asta e foarte interesant. Nu este doar Headless versus un site all-in-one, este o dezvoltare bazată pe șabloane versus pe baza de componente. Și se pare că se referă la cotații, munca clientului și aprobarea clientului, testare și munca QA, munca de dezvoltare și munca de proiectare. Și se pare că e o schimbare. Și se pare că există o schimbare pozitivă. Exista ceva-

Deci, dacă ai un client, vine și ei spun că am cerințe xyz. Ce set de cerințe ați auzi care v-ar face să spuneți că este perfect pentru un proiect Headless? Și Stephen, poți să ne începi?

STEPHEN BROOKS: Da, sigur. Deci, primul lucru la care mă uit personal este amprenta de securitate de care are nevoie organizația, corect. Este acesta un site web orientat spre interior sau un site web orientat spre exterior? După aceea, începem să aruncăm o privire la, hei, acest CMS va alimenta mai multe articole, livrare omni-canal. Dacă primele două casete sunt bifate, boom, este o versiune automată Headless.

Dacă doar unul dintre aceștia este bifat, atunci trebuie să vorbim puțin mai profund cu clientul nostru pentru a ne asigura că este în conformitate cu amprenta operațională a acestora. Și vreau să spun că 95% dintre conversațiile pe care le-am avut în ultimele opt luni au fost toate cool. Tuturor le place. Este o adevărată schimbare de paradigmă față de orice altceva. Deci da.

HASHIM WARREN: Nu, e grozav. Și Jonathan, poți vorbi puțin despre asta? Ce set de cerințe te-ar face să simți că, OK, acesta ar trebui să fie un proiect Headless? Și, de asemenea, ce compromisuri i-ați explica unui client despre adoptarea Headless?

JONATHAN JETER: Sigur, deci una dintre principalele, cam la obiect mai devreme, este câte surse de date folosiți pentru a agrega conținutul site-ului? Și dorește clientul să folosească acesta ca depozit central de conținut, spre deosebire de aceasta și de alte opt surse pe care le au pentru aplicația sa mobilă sau pentru media, sau pentru orice altceva, corect?

Deci avem acea conversație. Dacă sunt de genul, oh da, suntem cu toții. Și asta este o alegere evidentă. De asemenea, ca agenție de publicitate avem aceste tipuri creative care proiectează mereu aceste lucruri cu adevărat nebunești, corect. Așadar, dacă știm dinainte cum ar fi, oh, cine este creația, uneori acest lucru determină o conversație, știm că aceasta va fi mai ușor de dezvoltat ca aplicație React decât va fi încercarea de a personaliza acea temă. în WordPress.

Dar schimburile. Unul este prețul. E mai scump, e întreținere, corect. Deci, acum nu doar întrețineți WordPress, corect, mențineți două stive diferite, două aplicații diferite. De aceea am mers pe acea cale și am folosit toate AWS și Gatsby și toate aceste lucruri pentru a le face în prealabil. Și așa, eram cu toții când a apărut Atlas. Am fost ca, oh da, dacă putem face toate astea într-un singur loc.

Pentru că de ani de zile, am vorbit cu Motorul nostru WP, unde am spus că trebuie să faceți asta pentru că o facem în altă parte, corect. Așa că hai să punem totul împreună. Așa că eram încântați de asta. Foarte, foarte mulțumit de procesul de construire a șantierelor din Atlas. Dar compromisul este, în esență, întreținerea, care cam dispare cu Atlas. Costul pentru client, în ceea ce privește găzduirea, spre deosebire de un site WordPress standard.

Dar uneori, așa cum am spus mai înainte, costul de dezvoltare a site-ului scade, costul de întreținere a site-ului scade. Deci este un schimb.

JAMES SQUIRES: Cred că un alt lucru foarte important pe care îl luăm în considerare atunci când dezbatem dacă este potrivit pentru o abordare bazată pe temă sau Headless, este cum arată transferul după construirea unui site? Se așteaptă clientul să aibă resurse interne care preia acest lucru? Sau caută un partener pe termen lung pe care să se bazeze?

Și aceasta este o decizie cu adevărat critică, deoarece dacă aveți o echipă care nu este familiarizată cu, cum ar fi React, Gatsby sau Next, oricare ar fi stiva Headless, atunci aceasta ar putea fi o surpriză destul de mare dacă nu sunt familiarizați cu Arhitectură fără cap și cum va fi întreținută. Deci, acesta este ceva cu adevărat important, poate părea evident, dar doar pentru a fi explicit despre, OK, odată ce acest lucru se lansează, și suntem în modul de întreținere și transferuri, care este planul acolo?

HASHIM WARREN: Minunat.

TAYO ONABULE: Cred că celălalt lucru care este, cred că Jonathan l-a menționat poate, este un fel de fapt că ceea ce, și acesta este în mare parte ceea ce ne concentrăm ca agenție, ceea ce este activat de Headless este în primul rând o experiență. lucru. În ceea ce privește ceea ce interacționează utilizatorii dvs. Și de multe ori, iar aceasta este o conversație în schimbare pentru fiecare companie. Unele companii vor doar să-și facă treaba. Unele companii vor să fie strălucitoare în privința asta.

Și în toate acele cazuri în care este important ca clientul să aibă o experiență cu adevărat revoluționară, sau ceva cu adevărat modern în ceea ce privește performanța, sau are nevoie de ceva care este considerabil mai antrenant în competiție, atunci toate aceste lucruri sunt mult, mult mai ușor de făcut pe Headless. Și astfel, conversația din mintea mea, sau cel puțin unghiul din care avem tendința de a începe, este doar: asta, trebuie să o duci la bun sfârșit sau este asta, trebuie să o faci și să impresionezi foarte mult oamenii cu asta.

Pentru că, evident, WordPress a făcut-o de mult timp și este un loc solid pentru a construi un site, dar, practic, cât de mult „flashy” vrei? Și dacă vrei multe, atunci Headless este o modalitate foarte bună de a face acest lucru

HASHIM WARREN: E minunat. Jimmy, vreau să vorbesc despre personal în termeni de agenție. Când te gândești la proiectele Headless, vrei dezvoltatori WordPress care au adoptat JavaScript și, să zicem, ceva de genul React? Sau mai degrabă ai avea mai mult un dezvoltator JavaScript care nici măcar nu folosește WordPress? Cum credeți despre personal când vine vorba de proiecte Headless WordPress?

JAMES SQUIRES: Da, este o întrebare bună. Agenția noastră, căutăm React ca un fel de bază de bază, deci, evident, JavaScript și experiență în cadrul React. Acesta este un fel de obligatoriu, la toate nivelurile, într-adevăr. WordPress este – tratăm asta ca pe un „placut de a avea”. Este ceva, mai ales în spațiul Headless, pe care îl putem antrena relativ repede.

Adică, în general, cu Headless, îți petreci timpul în WordPress dezvoltând tipuri de postări personalizate și doar amenajând cadrul componentelor din punct de vedere al backend-ului, dar nu atingi prea multe aspecte legate de moștenire, un fel de aspecte bazate pe teme. într-o arhitectură normală, fără cap. Așa că am descoperit că nu avem nevoie de această experiență de bază, WordPress.

Desigur, avem nevoie de câțiva jucători din echipă care au asta pentru anumite aspecte, dar, în general, am reușit să atragem cu adevărat un inginer React, care nu a mai atins WordPress până acum. Arătându-le cum să facă modificări în câmpuri, iar acestea sunt oprite și rulează. Ei înțeleg deja GraphQL, care este o competență de bază cu care trebuie să fii familiarizat cu arhitecturile Headless.

Dar, dincolo de asta, cunoștințele WordPress pot fi destul de superficiale și poți să aduci pe cineva și să fii foarte productiv într-un proiect. Aceasta este frumusețea componentelor React este că orice dezvoltator React poate sări în mijlocul unui proiect, să se uite la folderul meu de componente și le atribuim unul și ei sunt plecați la curse atâta timp cât au structura de date deja setată.

HASHIM WARREN: Este foarte interesant și în ceea ce privește capacitatea de a separa munca. Lucrezi la această componentă și poți lucra la ea separat de proiect. Acesta este un exemplu grozav.

Jonathan, cum crezi despre asta când vine vorba de proiecte Headless WordPress? Ați prefera să aveți un dezvoltator WordPress ale cărui abilități – care să adauge React la asta sau orice cadru JavaScript la centură? Sau un dezvoltator JavaScript care crește pe WordPress, cum crezi despre asta?

JONATHAN JETER: Deci, așa cum a spus Jimmy, avem nevoie de amândouă, dar acum vom căuta mai multe dintre React, View, dezvoltatorii JavaScript front-end. Ei bine, toată lumea își spune Full Stack acum, dar dezvoltatorii JavaScript care vor putea să intre. Și i-am pus pe dezvoltatori să vină și să spună, o, nu voi lucra în WordPress, ca și cum asta nu ar fi ceva Vreau sa fac. Și odată ce intrăm în el, facem un proiect Headless, oh, nu e chiar așa de rău.

Pentru că nu au de-a face cu toată munca pentru PHP și toate astea. Dar, în același timp, am mutat unii dintre oamenii noștri DevOps să se ocupe de WordPress backend, așa că nu avem neapărat nevoie de un dezvoltator de backend pentru a face acest lucru, așa că funcționează foarte bine. Daţi-i drumul.

JAMES SQUIRES: Voiam să adaug că, cel puțin din experiența noastră, numărul de ingineri pe care îi poți implica într-un proiect Headless și să fii productiv tinde să fie mult mai mare. De exemplu, tocmai am lansat un Headless bazat pe SvelteKit – cred că este primul de pe Atlas – săptămâna trecută. Nu recomand SvelteKit încă clienților, dar ne place destul de mult.

Dar am avut un exces de opt ingineri simultan, toți lucrând la componente și, odată cu dezvoltarea bazată pe teme, avem tendința să ne luptăm mai mult să obținem o mulțime de ingineri și să fim productivi. Doar pentru că lucrurile sunt puțin mai monolitice, în ceea ce privește câte lucruri poți atinge simultan. Sunt sigur că este posibil și îl puteți coordona, dar găsim că este mult mai ușor pe arhitecturile Headless.

HASHIM WARREN: Apropo, este o priveliște frumoasă. Am văzut lansarea. Este un site frumos.

JAMES SQUIRES: Mulțumesc.

JONATHAN JETER: Alt lucru pe care l-aș spune, de asemenea, este că știu că vorbim doar despre WordPress, nu, dar ne ocupăm și de proiecte care nu sunt WordPress, corect. Deci, acești dezvoltatori JavaScript pot lucra pe mai multe sisteme backend, spre deosebire de dacă angajez un dezvoltator .net, ei funcționează, în cea mai mare parte, doar în .net, corect.

Așadar, avem oameni care se asigură că API-urile funcționează, cumulează datele, reunesc toate aceste lucruri, corect. Și apoi avem front-end-uri care pot lucra la oricare dintre aceste proiecte, spre deosebire de a fi specific unui anumit limbaj.

TAYO ONABULE: Și cred că sunt câteva lucruri aici pe care le menționăm cu toții. Cred, să spunem cum este, ca React, unul – În cazul nostru, avem tendința de a rămâne cu React oricum. Avem câțiva dezvoltatori View, dar avem tendința de a rămâne cu React. Dar toate aceste cadre frontale au fost concepute special ținând cont de un anumit dezvoltator și proces. Sunt proiectate – mi-aș imagina că domnul Facebook la un moment dat a fost de genul, să ne asigurăm că acest lucru este cât mai eficient pentru echipa noastră.

Și, așadar, acesta este esențialul a ceea ce este React și va fi cam la fel pentru View și Angular. În ceea ce privește partea WordPress a acesteia, din nou, numiți-o așa cum este. În esență, vă puteți descurca doar știind cum să navigați în backend-ul WordPress și folosind ACF. Și altfel nu aveți cunoștințe despre WordPress și reușiți totuși să construiți un site WordPress Headless.

Și, așadar, cerința din partea WordPress, cu excepția cazului în care încercați să faceți lucruri care încep să devină complicate, puteți construi din punct de vedere tehnic un site WordPress Headless cu cunoștințe de bază despre unde este fișierul .php și nimic altceva. Te poți descurca. Și cred că frumusețea acestui lucru este, așa cum a spus Jonathan, încă o dată, acei dezvoltatori JavaScript vor fi utili în toate proiectele tale. Și cred că este destul de sigur să spun că, în viitorul apropiat, web-ul va fi axat pe JavaScript și, prin urmare, acesta este un talent foarte util.

Cât de departe pe linie în care trece ultimul comutator, probabil că va dura ceva timp. Deci, sincer, nu este într-un fel un angajament mare. Este unul care are sens, mi-aș imagina majoritatea cazurilor.

HASHIM WARREN: Vreau doar să-ți susțin povestea pentru că într-o viață anterioară, a trebuit să antrenez doi dezvoltatori React pe noul nostru site WordPress. Și era un site WordPress Headless. Și era doar o după-amiază. Le-am arătat ACF, au fost foarte entuziasmați, au făcut modelele de date și au plecat. Și chiar și unul dintre dezvoltatori a conectat de fapt editorul clasic și l-a făcut astfel încât să pot controla unele componente de pe front-end.

Acest lucru este înainte de Gutenberg, așa că folosim câmpuri repetitoare și ACF și controlam unele dintre componentele de pe front-end. A fost minunat. Dar cei doi dezvoltatori React au înțeles imediat. Doar le-a luat după-amiaza și au plecat la curse.

TAYO ONABULE: Iată că, cu acest tip de dezvoltatori front-end, ei sunt destul de obișnuiți să se conecteze la back-end-uri pentru datele lor și să aibă o structură de date de care să se țină. Aceasta este o componentă comună a fluxului lor de lucru, așa că WordPress nu are multe șanse.

JONATHAN JETER: Cu prevalența – îmi pare rău, prevalența SaaS, aplicațiile fiind disponibile peste tot acum, lucruri pe care obișnuiai să le făceai în WordPress, fie comerțul electronic, fie integrarea cu CRM, tot felul de lucruri. Acum, asta nu se face în – nu mai trebuie să se facă pe WordPress. Nu trebuie să instalați un plug-in Marketo sau un plugin Salesforce sau ceva pentru a încerca să le conectați, corect.

Acum faci singur acele conexiuni, ceea ce permite o experiență mai bună, o experiență personalizată. Acest lucru permite viteza, securitatea, toate aceste lucruri, spre deosebire de încercarea de a aduce un dezvoltator PHP acolo pentru a afla cum să facă aceste lucruri să funcționeze în WordPress.

HASHIM WARREN: Minunat. Stephen, mi-ar plăcea să aud de la tine despre ecosistem, ecosistemul JavaScript. Știu că dezvoltatorii WordPress sunt obișnuiți cu un ecosistem cu adevărat minunat și robust, în ceea ce privește pluginurile, și comunitatea. Puteți vorbi despre cum se compară cu ecosistemul din lumea JavaScript? Atât din punct de vedere al tehnologiei, cât și chiar al comunității.

STEPHEN BROOKS: Da, deci, cu WordPress, are cea mai mare piață pentru plug-in-uri pentru construirea monolit tradițională. Dar să revenim la punctul lui Jonathan cu doar o secundă în urmă, cu utilizarea NPM pentru toate funcționalitățile de care aveți nevoie de la front-end, este echivalent, dacă nu mai mare, decât piața WordPress. Pentru că nu numai că aveți toate acele pachete NPM care sunt disponibile. Există, de asemenea, numeroase STK-uri pe care le puteți introduce, de asemenea, pentru a crea cu adevărat și rapid toată integrarea datelor de care aveți nevoie.

Așa că aproape că aș spune că este mai mare cu aproximativ 20%. Doar aruncați un număr arbitrar, dar este mult mai rapid pentru oameni să se miște. Și multe dintre chestiile NPM sunt la punct. De asemenea, nu trebuie să vă faceți griji cu privire la nepotrivirea versiunii de bază WP și a versiunilor plug-in care se pot întâmpla. Odată ce ați fixat versiunile în manifestul pachetului, vreau să spun că ați terminat. Nu trebuie să vă mai faceți griji cu privire la actualizarea lor dacă nu doriți sau ceva de genul acesta.

Deci, din nou, se întoarce la ceea ce spune toată lumea, viteza și flexibilitatea sunt primordiale ori de câte ori se utilizează soluția Headless, spre deosebire de abordarea WordPress tradițională.

JAMES SQUIRES: Pentru a nu arunca nicio umbră afacerilor care câștigă mulți bani din pluginurile lor WordPress, dar acesta este un alt domeniu, deoarece, într-o arhitectură fără cap, tindeți să aveți mai puține costuri de licențiere, unde într-o temă tipică, există niște plugin-uri foarte grozave pe care le găsim mereu în propuneri de cumpărat și de utilizat. În cea mai mare parte, totul în NPM este software gratuit, open-source.

Există cu siguranță unele care pot avea asociat un model de serviciu. Dar, în general, puteți găsi cea mai populară soluție și este licența open source. Deci, este ușor să te miști rapid în acest fel și să nu încetinești cu aprobările clienților cu privire la costurile de licențiere și lucruri de genul ăsta.

HASHIM WARREN: Jimmy, am un alt exemplu care este așa. Așa că construiam un site web Gatsby și adăugam Google Analytics la el. Gatsby are un ecosistem de pluginuri, toate pluginurile sunt open source. Pachetele lor sunt pe NPM, sunt ușor de instalat. Așa că adaug Google Analytics și avea toate aceste opțiuni care, cu cel mai popular plugin Google Analytics pentru WordPress, unele dintre aceste opțiuni intră în versiunea premium. Așa că am fost foarte încântat ca cineva care este fericit să plătească pentru acest plug-in WordPress pentru a avea aceeași funcționalitate cu acest pachet care era și un plugin Gatsby. Sunt foarte încântat de cum se potrivesc acele ecosisteme.

TAYO ONABULE: Cred că a fost doar foarte rapid și despre tot subiectul NPM. Cred că este cel mai mic lucru, și probabil că nu are importanță, dar eu pentru mine. Prefer cu mult faptul că atunci când dezvoltați ceva în React, doriți ceva, îl descărcați prin CLI. Și nu trebuie să intri în WordPress, sau orice fel de lipici, este doar acolo în spațiul tău. Nu trebuie să părăsești studioul și totul este acolo. Și este un proces mult mai puțin greoi decât să faci niște cercetări, să găsești un plug-in, să-l instalezi și cetera. Nu am fost niciodată un fan al asta.

HASHIM WARREN: Minunat. Jonathan, vreau să te întreb, am vorbit despre cerințe care te-ar face să spui că acest lucru este perfect pentru WordPress Headless. Ce fel de proiect te-ar face să simți că este, OK, acesta ar trebui să fie un proiect tradițional, WordPress.

JONATHAN JETER: Așa că facem și noi multe dintre ele, corect. Uneori este buget. Ei vin și spun, avem atâtea. Suntem ca și cum nu avem de ales, corect. Asta facem, corect. Și pentru că, atunci avem lucruri pe care le folosim. Procesul și sistemul respectiv sunt deja în vigoare. Cum spunea Jimmy, avem plug-in-uri pe care le integrăm în fiecare dintre aceste propuneri pentru că știm că este foarte simplu.

Deci un site tipic de marcă mică. Tipic – Așa cum spunea Tayo mai devreme, nu trebuie să fie sclipitor, nu. Nu este nimic scandalos de creativ la acest site, corect. Și pur și simplu s-au dus, hei, le-am mai avut, de parcă știm că avem nevoie de un site web, așa că fă-ne unul. Dreapta. Și dacă acesta este cazul, atunci, da, absolut, în funcție de bugetul și cerințele dvs., un site WordPress standard va fi potrivit.

Am ajuns chiar și la punctul în care, folosind Genesis, și Genesis Pro și Smart Plugin Manager, și tot felul de lucruri, avem site-uri pe care le construim pe care dezvoltatorii nici nu le ating. Doar trece prin procesul și prin procesul creativ, studioul editează fișierele și practic pun conținutul. Avem niște editori care fac dovada și pun conținutul, iar site-ul se face fără ca un dezvoltator să atingă vreodată. aceasta.

Și cam așa trebuie să faci, corect, pentru a câștiga bani din acele proiecte, pentru că cu aceste tipuri de bugete, nu poți obține 20 de ore de dezvoltare pe partea din spate a unuia dintre acele site-uri. Deci, de obicei, așa decidem, cu excepția cazului în care este un site uriaș, dar sunt ca nu, nu, nu, nu vrem nimic elegant. Vrem doar ca acesta să fie un site obișnuit. Am făcut asta, doar o mulțime de conținut, bloguri, astfel de lucruri.

Din punct de vedere SEO, WordPress este încă grozav. Dacă asta caută, parcă nu ne interesează cum arată. Vrem doar funcția. Vrem să fie rapid. Vrem să avem conținut și să ne poziționăm bine. Un site WordPress tradițional funcționează bine.

HASHIM WARREN: Minunat. Stephen, poți vorbi despre asta? When would you say, OK, this needs to be a traditional site or traditional WordPress site?

STEPHEN BROOKS: It really follows along with Jonathan. Cost is going to be the first one, and then the second one after that is going to be time to market. If somebody needs something out pretty quick, even with the accelerator as John's talking about in terms of Genesis blocks, and just having a block catalog that you can do 0 dev from, it's still really incumbent on getting that stuff out as quickly as possible for those clients. Also to spin outs is a pretty big one for us. To where, hey, we need some sort of marketing presence for our investors. This is going live in two weeks. What could you do for me.

HASHIM WARREN: Awesome Thank you so much to our panel for your participation today. If you are interested in Headless WordPress, you can get a free Atlas Sandbox account at WPEngine.com/Atlas. And compare for yourself. You can use an all-in-one WordPress site, and compare it right against a Headless WordPress site, to compare everything that we talked about today. Thank you so much for joining us.