DE{CODE}: Headless 101 per gli sviluppatori di WordPress

Lo sviluppo senza testa può essere più potente e persino più divertente dello sviluppo tradizionale di WordPress. Tuttavia, con così tante nuove scelte in questo stack emergente, qual è il modo migliore per iniziare? Questo workshop guiderà i costruttori attraverso l'installazione e l'ottimizzazione di un progetto WordPress per headless, fino alla creazione di modelli per la prima pagina in un frontend disaccoppiato.

Slide della sessione

Trascrizione del testo completo

GRACE ERIXON : Benvenuto in Headless 101 per sviluppatori WordPress. Mi chiamo Grace Erixon e sono una sostenitrice degli sviluppatori associati qui a WP Engine. Insieme a me c'è Steve di Haus. Oggi ti forniremo una rapida introduzione su cos'è WordPress headless e su come puoi iniziare a usarlo.

Quindi, per capire cos'è un'architettura di un sito Web WordPress headless, è importante assicurarsi che siamo tutti sulla stessa pagina su come appare un'architettura WordPress tradizionale. Tradizionalmente, un CMS come WordPress gestiva sia il front-end che il back-end di un sito web.

In un'architettura tradizionale, l'editore crea e gestisce contenuti come post di blog e pagine all'interno di WordPress. Lo sviluppatore scrive il codice per controllare l'aspetto e il funzionamento del sito utilizzando PHP e l'API del tema di WordPress. Quindi WordPress genera la pagina HTML che viene inviata al visitatore.

In questa architettura CMS accoppiata, WordPress fornisce agli editori le funzionalità di gestione dei contenuti. Ed è anche responsabile della pubblicazione di pagine HTML ai visitatori del sito web. Un CMS headless utilizza un'architettura disaccoppiata in cui il front-end e il back-end sono gestiti separatamente. In un'architettura headless, l'editore crea e gestisce ancora i contenuti in WordPress, come in un'architettura WordPress tradizionale.

Lo sviluppatore scrive il codice per controllare l'aspetto e il funzionamento del sito in JavaScript, oltre a utilizzare WPGraphQL o l'API REST per estrarre i dati da WordPress. Un framework come Faust.js, Next.js, Nuxt.js o SvelteKit viene spesso utilizzato per alimentare questa applicazione frontend. Quindi l'applicazione JavaScript front-end genera e serve le pagine HTML che vengono inviate al visitatore del sito web.

A differenza di un'architettura tradizionale, WordPress non è più responsabile della generazione di pagine HTML. Quindi l'interazione per lo scambio di contenuti tra il back-end di WordPress e l'applicazione JavaScript front-end avviene attraverso il livello API. Le due opzioni per il livello API sono l'API REST di WordPress o WPGraphQL.

L'API REST viene fornita in bundle con WordPress. Tuttavia, il modello di accesso ai dati che richiede può essere lento perché REST richiede che ogni risorsa abbia il proprio punto finale. Ad esempio, sarebbero necessari più viaggi di andata e ritorno per ricostruire un post completamente modellato. Se volessi ottenere il contenuto, l'autore e la categoria di un post, sarebbero necessarie tre chiamate API separate.

Al contrario, WPGraphQL ci consente di chiedere il contenuto, l'autore e la categoria di un post in un'unica richiesta. Per questo motivo, WPGraphQL è il nostro livello API preferito. WPGraphQL è un plug-in gratuito che fornisce uno schema e un'API GraphQL estendibili per il tuo sito WordPress. WPGraphQL è più veloce dell'API REST perché ottiene i dati esatti richiesti e si traduce in un minor numero di funzioni eseguite attraverso l'ottimizzazione delle query, un minor download di dati, un caricamento dei dati più efficiente e più risorse incluse in una singola richiesta.

Un'architettura senza testa offre agli sviluppatori la libertà di scegliere tra qualsiasi stack tecnologico front-end con i framework JavaScript che sono i più popolari. Alcuni dei framework JavaScript front-end più popolari includono React, Vue.js e Svelte. Nuovi framework vengono rilasciati continuamente, quindi questo elenco non è neanche lontanamente completo.

Molti di questi framework JavaScript vengono utilizzati insieme a meta framework che aggiungono soluzioni per cose come il routing, il rendering lato server e altro ancora. React viene utilizzato insieme a Next.js, Vue.js viene utilizzato insieme a Nuxt.js e Svelte viene utilizzato insieme a SvelteKit. Gatsby è un altro popolare meta framework.

WP Engine ha sviluppato Faust.js, un framework JavaScript basato su React e Next.js. Faust è stato creato appositamente per supportare le applicazioni Web WordPress headless. Supporta l'autenticazione e pubblica anteprime predefinite, fornisce comodi hook React integrati per l'accesso ai dati di WordPress e altro ancora.

Quindi abbiamo parlato di cosa significa un'architettura WordPress headless e del tipo di tecnologia che useresti. Ma tocchiamo rapidamente il motivo per cui sceglieresti anche senza testa. WordPress stesso è un CMS pesante e utilizza PHP, che non è un linguaggio veloce. Headless WordPress utilizza i linguaggi Foster tramite JavaScript e carica solo i file necessari tramite chiamate API. È molto più leggero, quindi il tuo sito si caricherà più velocemente.

Headless WordPress riduce anche al minimo il rischio per i tuoi contenuti poiché i tuoi dati vivono separati dalla tua consegna front-end. È meno esposto agli attacchi web. E il vantaggio principale è che l'architettura headless di WordPress consente agli editori di continuare a beneficiare dell'eccezionale esperienza di pubblicazione fornita da WordPress, consentendo allo stesso tempo agli sviluppatori e ai visitatori del sito Web di sfruttare le capacità tecniche offerte dalle moderne applicazioni JavaScript.

Ora, scaviamo nel codice di un vero sito headless. Ho pre-registrato una panoramica del nuovo sito WordPress headless di Atlas Blueprints. La nuova funzionalità Blueprints in Atlas offre un modo davvero semplice per rendere operativo un sito WordPress headless completo. Sono dotati di codice iniziale, plug-in, modelli di contenuto e struttura della pagina per far decollare la tua app più velocemente.

Quindi creiamo un nuovo sito Blueprint in modo da poterci immergere nel codice. Dall'interno della dashboard di WP Engine, andremo ad Atlas. Fare clic su Crea app. Selezionare Inizia con Blueprint. E poi selezioneremo il progetto che vogliamo usare. Sceglierò il progetto del portfolio.

Quindi collegherai il tuo account WP Engine al tuo account GitHub e clonerai quel progetto in un nuovo repository. Ci vorranno un paio di secondi per costruire. Infine, dovrai solo selezionare il nome del repository che hai appena creato, la regione in cui ti trovi più vicino e quindi fare clic su Crea app.

Ora, se fai clic sull'URL Atlas, possiamo verificare come appare il nostro sito WordPress headless. Siamo particolarmente interessati alla pagina Post. Come puoi vedere, il sito sta inserendo tutti i post più recenti in questa pagina del nostro blog. E ogni post ha anche la sua pagina di visualizzazione individuale. Ma da dove vengono tutti questi dati?

Se torniamo alla dashboard di WP Engine, vedremo un pulsante per WP Admin. C'è il back-end per il nostro sito WordPress headless. Se faccio clic su Posts, vedrai lo stesso elenco in cui l'app Web stava entrando. Ora possiamo aprire il repository GitHub in cui è stato clonato il nostro Blueprint. E cloniamo quel repository nel nostro ambiente locale.

Quindi aprirò questo repository in Visual Studio Code, il mio editor di codice preferito. Eseguendo il drill nella directory del progetto, il file per la pagina del blog può essere trovato su SRC, pagine, post, Index.js. Questo progetto è realizzato utilizzando React, Next.js, Faust.js e WPGraphQL. Se non hai familiarità con React o anche con JavaScript, all'inizio questo potrebbe sembrare confuso.

Nella prima sezione, il file sta solo importando le cose di cui ha bisogno da fonti interne ed esterne. La seconda sezione che definisce i campi di prepass dei nodi post è dove sono elencati tutti i dati di cui abbiamo bisogno. L'esecuzione di questo tramite prepass assicura che i dati siano presenti quando ne abbiamo bisogno e non si verificano richieste a cascata.

Quindi abbiamo la funzione pagina. All'inizio si tratta solo di raccogliere i dati di cui abbiamo bisogno in poche variabili diverse, vale a dire le impostazioni generali e un elenco impaginato di post. I tag all'interno dell'istruzione return sono il codice che verrà reso visivamente sulla pagina web. Innanzitutto, abbiamo il componente per l'intestazione. Quindi, all'interno di questo componente principale, abbiamo un componente di intestazione della voce, ed è ciò che mostra il grande titolo che dice Ultimi post nella parte superiore della pagina.

Infine, arriviamo al componente post, che accetta come parametro l'elenco impaginato dei post. Diamo un'occhiata a cosa fa il componente post con queste informazioni. Qui sta scorrendo ogni post contenuto nell'elenco dei post che ha ricevuto. Per ogni post, mostra la vista simile a una scheda sulla pagina dell'ultimo post. Questo primo è costituito da un componente immagine in primo piano racchiuso in un collegamento alla pagina del singolo post del blog, un'intestazione del titolo del post e un componente di informazioni sul post costituito dalla data e dall'autore del post.

Tornando al file Index.js che mostra tutti i post, lo completiamo visualizzando il componente Carica altro nella parte inferiore della pagina per recuperare più post se richiesto e un piè di pagina. L'ultima funzione, getStaticProps, è una funzione di generazione del sito statico di Next.js che indica di eseguire il pre-rendering di questa pagina in fase di compilazione utilizzando gli oggetti di scena restituiti dalla funzione. E questo è tutto.

Grazie a Blueprints per aver gestito la configurazione Headless per noi. È stato semplice suddividere ciò che va nella pagina del post per ottenere dati dal backend di WordPress utilizzando WPGraphQL e visualizzare i post utilizzando i componenti React. Grazie per esserti sintonizzato. Puoi trovarmi su Twitter @graceerixon.

Dai un'occhiata a developer.wpengine.com per ulteriori contenuti su Headless WordPress. Abbiamo un tutorial su come creare da zero il tuo primo sito Headless WordPress utilizzando Faust.js e stiamo lavorando a una serie di contenuti Headless 101 in questo momento. Puoi ottenere tutti gli strumenti offerti da Atlas se ti registri per un account Sandbox gratuito. Ora lo passerò a Steve per parlare di più del motivo per cui Haus ha scelto Headless WordPress per il suo progetto leoburnett.com.

STEVE SCAVO: Grazie, Grazia. Ciao, sono Steve Scavo, CTO di Haus. Siamo uno studio e un'agenzia di tecnologia creativa con sede a Los Angeles, in California. Questo intervento è appropriatamente intitolato Headless 101 for WordPress Developers. E per dirla tutta, non sono uno sviluppatore di WordPress di professione, ma penso che questo faccia parte della bellezza di un'architettura senza testa.

Quindi avremmo potuto facilmente chiamare questo Headless 101 per gli sviluppatori non WordPress che hanno bisogno di sfruttare WordPress. Potrebbe essere stato un titolo altrettanto appropriato. Questo è il bello dei senza testa. È una vittoria vincente da tutte le parti, come vedrai.

Allora perché senza testa? Ci sono così tante ragioni di alto livello di cui potremmo parlare, ma penso che parlare di esempi di produzione reale ed esempi del mondo reale di quando brilla sia davvero utile. E mi piacerebbe mostrare un progetto che abbiamo fatto per Leo Burnett usando headless sotto un'architettura headless. Per il contesto, Leo Burnett è un'agenzia pubblicitaria leggendaria di Chicago, ma ha molti uffici in tutto il mondo e in tutto il mondo. Quindi hanno molti contenuti, molto lavoro.

Il vecchio sito funzionava su un unico tema WordPress. Era davvero frammentato, un po' lento, non funzionava bene. È stato difficile da aggiornare e non mostrava del tutto il tipo di prestigio e il marchio che Leo Burnett voleva trasmettere. Quindi questo è ciò con cui siamo andati a lavorare dal punto di vista del design. E abbiamo scelto headless per modernizzare davvero il loro stack.

Volevamo solo che sembrasse vivo e fresco e avesse quel tipo di capacità di cui abbiamo bisogno per mettere insieme un'esperienza utente e un'interfaccia utente meravigliose. Volevamo aumentare il loro potere editoriale. Volevamo aumentare la cadenza con cui possono pubblicare i contenuti. Volevamo ristabilire l'identità del marchio e avere un'interfaccia utente e un'interazione, la sensazione del sito Web che trasudava davvero Leo Burnett e tutti questi piccoli tocchi e una sorta di punti editoriali, tipografici e di interazione che volevano trasmettere.

E volevamo preparare la base di codice e il sito Web per il futuro. Non volevamo solo che il sito fosse rilevante per i prossimi 12 mesi. Vogliamo che sia rilevante per il prossimo decennio, forse. E penso che questa architettura senza testa, questo stack senza testa lo faccia davvero.

Quindi uno dei problemi iniziali con headless è che ci sono sempre molte decisioni in merito all'hosting, alla distribuzione e all'infrastruttura, ed è sempre stato un enorme punto dolente. Quindi queste decisioni sullo stack sono sempre state lasciate allo sviluppatore. E dai un'occhiata in giro e ti fai un'idea, OK, quale applicazione di terze parti, forse CI/CD devi usare? Lo ospiteremo su AWS? Come lo facciamo? Quali servizi? E poi in un certo senso implementi questo tipo di potenzialmente, queste soluzioni ad hoc attorno a quel flusso.

Bene, la piattaforma Atlas e WordPress Engine Atlas risolve davvero questo problema. È qui che entra in gioco. Abbiamo scelto di andare con Atlas per tutti questi motivi e hanno questa infrastruttura di servizi gestiti. Standardizzano la pipeline CI/CD. Non devi davvero pensarci.

Esistono migrazioni di dati tra gli ambienti che sono essenzialmente ridotte a un flusso con un clic. Questo è sempre stato storicamente un grosso problema con il passaggio dal controllo qualità alla messa in scena alla produzione. Essenzialmente il motore WordPress e la piattaforma Atlas lo hanno ridotto a un solo clic.

E poi c'è solo questa fatica per i microservizi e DevOps. C'è solo un pesante carico cognitivo su quanto devi pensare e supportare ed esserne consapevole come sviluppatore e mantenerlo attivo e funzionante. Sono tutte cose che la piattaforma Atlas ti toglie davvero di mano e risolve in modo vantaggioso.

Parliamo quindi di alcune delle dinamiche che penso che gli headless promuovano davvero e che sottolineino davvero. Il primo pilastro qui– ce ne sono tre. Il primo pilastro è l'esperienza degli sviluppatori. Ci permette di scegliere lo strumento giusto per il lavoro. E quando dico noi, intendo gli sviluppatori.

Ci consente di scegliere uno stack in cui vogliamo scrivere il codice. E questo è, per noi, è in Haus, è Next.js e React. Next.js è solo un meraviglioso framework attorno ad alcune convenzioni davvero carine per il routing, le prestazioni e l'architettura dell'applicazione. E volevamo anche implementare un sistema di design, e non solo un sistema di design visivo ma un sistema di design codificato. Questo è qualcosa che mantiene la nostra applicazione coerente, testata, bella.

Le interazioni sono coerenti. Ci consente di creare nuove pagine e funzionalità in quell'ecosistema anche in futuro, e mantenerlo e mantenere quella coerenza. Ci consente anche di scrivere codice espressivo dichiarativo e React lo approva come libreria. Ma crediamo anche in quello stile di scrittura come squadra. Ci consente di scegliere quello stack per noi sul front-end, mentre forse un tradizionale sito WordPress basato su temi, non abbiamo davvero lo stesso lusso.

Abbiamo anche bisogno di molto margine creativo. Puoi vedere quando visiti leoburnett.com, ci sono bellissime transizioni di pagina. Ci sono– non siamo vincolati al tradizionale stack di WordPress su come le cose dovrebbero essere visualizzate. WordPress non è più responsabile del rendering del frontend.

Il nostro headroom è virtualmente illimitato. Possiamo scegliere le nostre librerie di animazione. Possiamo scegliere il modo in cui i nostri componenti interagiscono tra loro. È un enorme vantaggio sul lato DX.

L'esperienza di amministrazione è elevata e penso che l'abbiamo ottimizzata perché non ci siamo mai allontanati dalla loro vecchia familiarità. Non c'è back-end cutover. Siamo passati da WordPress a WordPress. Non abbiamo dovuto esportare dati e scrivere script per passare a un altro sistema proprietario. Quindi la familiarità è enorme. Volevamo mantenere quel tipo di flusso per gli attuali amministratori di leoburnett.com.

Adozione e documentazione: se trascorri cinque minuti sul Web, probabilmente hai toccato un back-end di WordPress e questo semplicemente non può essere sopravvalutato. Leo Burnett ha anche molti punti di contenuto molto specifici e campi personalizzati. WordPress offre questo e ti dà quel potere, ma siamo stati in grado di implementare il plug-in Advanced Custom Fields, che è davvero una bella convenzione per regolare l'interfaccia utente di amministrazione per renderla davvero amichevole e utilizzabile. Quindi è stata una vittoria per l'esperienza di amministrazione.

Ora, ovviamente, il terzo pilastro è l'esperienza dell'utente. È ciò che conta davvero. Utenti, penso proprio come crediamo che le applicazioni web di Haus dovrebbero sembrare applicazioni native, non dovrebbero esserci abbandoni. Penso che anche gli utenti lo apprezzino molto.

Sono senza soluzione di continuità. Sono reattivi. Si sentono solo bene. E penso che volevamo che Leo Burnett e tutte le nostre applicazioni si sentissero in quel modo. Essere in grado di scegliere lo stack che vogliamo sul front-end ci consente di farlo.

Le app native sono intrinsecamente disaccoppiate dalle loro infrastrutture di contenuto back-end, così come le nostre app web. E questo è ciò che promuove Atlas. Questo è ciò che promuove l'architettura senza testa in generale. Promuove anche le prestazioni. Possiamo rendere universalmente la nostra interfaccia utente. Ciò significa che il caricamento iniziale è sul lato server. E dopo, il cliente prende il sopravvento.

Ci sono molti vantaggi qui. Uno è che rende felici i motori di ricerca. Sono contenuti lato server. È veloce. Ci consente inoltre di pre-renderizzare virtualmente istantaneamente la pagina successiva e di effettuare tali richieste in base a ciò che è nel viewport una sola volta.

Per Leo Burnett, in termini di Content API che abbiamo scelto di utilizzare, abbiamo impostato un endpoint GraphQL. Ciò significa che ci sono carichi utili più snelli che tornano. Stiamo definendo esplicitamente esattamente il contenuto di cui abbiamo bisogno. C'è meno idratazione dopo il rendering lato server nel rendering lato client.

Ciò significa meno codice in arrivo, meno risposta, tempi di risposta più rapidi. È sicuramente una vittoria, e suggerirei che se hai intenzione di passare a un flusso di lavoro Atlas o a un flusso di lavoro senza testa, dai un'occhiata all'utilizzo dell'API GraphQL rispetto forse a qualcosa come un'API REST.

E dal punto di vista dell'utente, vede contenuti nuovi e tempestivi. Si tratta di un flusso di pubblicazione ottimizzato per l'anteprima del contenuto. È ottimizzato per recuperare rapidamente i contenuti sul lato di staging e anteprime e quindi promuoverli nella produzione. Gli amministratori di Leo Burnett sono estremamente contenti di quanto sia facile aggiornare i contenuti e questo rende felici gli utenti.

Qual è il risultato? Questo è solo un po 'per arrotolare tutto. Ha ispirato sviluppatori, amministratori produttivi e utenti felici. Questa è la triade e la speranza a cui penso che tutti i team di sviluppo web si battano davvero.

Quando gli sviluppatori sono ispirati, utilizzano un set ottimizzato di strumenti. Ci si sente bene. Sono felici. Scrivono codice migliore.

Gli amministratori sanno che stanno producendo contenuti in un bellissimo ecosistema. È veloce. Spedisce rapidamente. E gli utenti vedono quel contenuto aggiornato e stanno sperimentando un front-end moderno, bello, ben funzionante e ottimizzato.

Penso di concludere, solo alcuni pensieri finali che mi piacerebbe che tu tenessi a mente. Penso che il brief, di per sé, manchi sempre di linguaggio. Penso che troppo spesso si parli solo di, ehi, costruiscimi un bel sito web. Costruiscimi un fantastico sito web. Voglio che sembri e si senta, e abbiamo eseguito tutte queste revisioni con i clienti.

E tutti si entusiasmano, e poi arriva V1, ed è lanciato. E poi le persone che devono rilevare quel sito web dicono, mi hai dato un pasticcio. Come mi prendo cura di questo? È un flusso ad hoc che hai concepito?

Non vuoi costruire un bel sito web e consegnare un fardello. Siamo molto orgogliosi qui a Haus di non farlo. E penso che la cosa meravigliosa di Atlas e Atlas come piattaforma sia che lo risolve.

Ti dà la sicurezza di spedire un ecosistema e un sistema di pubblicazione web che ha effettivamente senso dal punto di vista dell'infrastruttura e dal punto di vista della distribuzione del codice. Fornisce una prova documentata al team IT e al team di ingegneri o al team di marketing che sai cosa stai facendo e che ora sono in buone mani con questo nuovo sito Web che hai creato per loro.

Perché ricorda, non stiamo solo costruendo un sito web. Stiamo creando un sistema di pubblicazione dei contenuti, ed è fondamentale comprenderlo e riconoscerlo fin dal primo giorno. E ancora, è qui che entra in gioco Atlas.

Quindi spero che quel piccolo bocconcino ti aiuti a concepire strategicamente il tuo stack senza testa in futuro. Se questa è la direzione che vuoi prendere, ti consiglio caldamente di dare un'occhiata ad Atlas. Spero che la sessione vi sia piaciuta e vi ringrazio molto.