CMS senza testa: Gatsby JS con WordPress

È risaputo che WordPress copre circa un terzo dei primi 1 milione di siti Web al mondo con una quota di mercato superiore al 50% nei sistemi di gestione dei contenuti. Di recente, nel 2016, WordPress ha deciso di introdurre un'API REST per fornire ad altre applicazioni un migliore accesso ai contenuti nel database di WordPress. Di conseguenza, fornendo agli sviluppatori la possibilità di sfruttare WordPress come CMS headless.

Ciò implicava inevitabilmente che gli ingegneri non si sarebbero più limitati a utilizzare il livello di presentazione convenzionale (frontend) di WordPress, ma ora avrebbero potuto sfruttare qualsiasi applicazione frontend per fornire i propri dati. Alla luce di ciò, la maggior parte di questo blog esplorerà la relazione di WordPress e Gatsby.js per quanto riguarda l'esecuzione di CMS senza testa.

Una breve storia di CMS

Mentre facciamo un passo indietro per comprendere la rivoluzione dei CMS senza testa, penso che sia degno di nota ricapitolare la storia dei sistemi di gestione dei contenuti (CMS). Tradizionalmente, all'inizio degli anni '90, le pagine Web statiche erano il modo principale per eseguire siti Web in cui un webmaster modificava direttamente i file HTML e li caricava su un server tramite FTP. Alla fine, a metà degli anni '90, la tecnologia web ha iniziato ad evolversi e i contenuti sono diventati più dinamici, portando all'emergere dei primi sistemi di gestione dei contenuti monolitici.

In sostanza, un CMS monolitico è un'applicazione software che include tutto il necessario per modificare e pubblicare contenuti sul web. Il primo di questi sistemi era limitato ad aziende come EpiServer, tuttavia, in seguito sono apparse variazioni open source come WordPress, Drupal e Joomla. Il resto è storia poiché WordPress ha guadagnato la maggior quota di mercato nel tempo.

Tuttavia, più tardi, durante la rivoluzione degli smartphone, i dispositivi mobili hanno iniziato a influenzare il modo in cui i contenuti web venivano consumati e distribuiti. Questa è stata una sfida per i tradizionali CMS monolitici progettati per fornire contenuti Web per laptop e desktop.

Per mitigare ciò, è nato il design reattivo che ha portato a layout del sito Web adattabili alle dimensioni dello schermo. Di conseguenza, ciò ha anche fornito l'opportunità di separare la gestione dei contenuti dal livello di visualizzazione. È qui che entrano in gioco i nostri CMS Headless.

CMS senza testa

Come accennato in precedenza, un CMS senza testa è uno senza un livello di presentazione. Di conseguenza, il contenuto viene distribuito tramite un'API (RESTful o GraphQL) per separare l'applicazione front-end che poi lo presenta. L'API rende i contenuti disponibili per qualsiasi canale e dispositivo utilizzando una varietà di strumenti e linguaggi di programmazione con un livello più elevato di sicurezza e scalabilità.

In sostanza, il CMS è disaccoppiato dalle preoccupazioni del front-end, il che a sua volta consente agli sviluppatori di creare esperienze avanzate per gli utenti finali, utilizzando la migliore tecnologia disponibile. Una modalità "senza testa" o "disaccoppiata" è attualmente supportata dalla maggior parte dei CMS, che ha aperto la strada ai siti di Gatsby.

Quindi, per sfruttare un CMS headless, dovrai prima creare il tuo sito o applicazione, quindi utilizzare l'API del CMS per collegare i tuoi contenuti.

L'esecuzione di WordPress Headless CMS

Rispetto alla cronologia degli eventi condivisa sopra, abbiamo visto come WordPress ha finito per realizzare un CMS Headless. WordPress contiene un'API (Application Programming Interface) che ti consente di estenderla con plugin (essenzialmente come un 'framework di applicazioni'). In particolare, ciò si ottiene tramite l'API REST, come vedremo in seguito.

Tuttavia, uno dei concetti chiave dell'API di WordPress sono gli hook. Fondamentalmente, gli hook consentono ai plugin di modificare le funzionalità principali di WordPress. In pratica, gli Hook funzionano in modo tale che quando si verifica un determinato evento in WordPress (ad esempio, caricamento della pagina o post-edit), WordPress chiama un determinato hook per eseguire la funzione.

In particolare, gli hook sono suddivisi in "Azioni" e "Filtri". Le azioni possono essere sfruttate per eseguire determinate funzioni PHP in determinati eventi, sebbene le funzioni non debbano restituire nulla. Mentre i filtri possono essere utilizzati per eseguire funzioni attraverso le quali WordPress passa i dati durante determinati eventi con queste funzioni che raccolgono i dati come parametro e restituiscono una versione modificata dei dati.

WordPress e l'API REST

Il Representational State Transfer (REST) ​​si basa sul protocollo HTTP e fornisce una semantica di interfaccia uniforme per creare, leggere, aggiornare ed eliminare dati (CRUD).

In generale, l'esecuzione dell'API REST in WordPress consente agli sviluppatori di accedere ai dati in un database WordPress in remoto inviando e ricevendo oggetti JSON (JavaScript Object Notation). Di conseguenza, ciò offre agli sviluppatori l'opportunità di creare, leggere, aggiornare ed eliminare i dati di WordPress da altre applicazioni che non sono progettate con WordPress. Ad esempio, applicazioni Web JavaScript o app mobili native.

Tuttavia, man mano che approfondiamo la comprensione della relazione Headless WordPress CMS con le API REST e Gatsby, dovremo notare alcuni concetti fondamentali dell'API di WordPress:

• Percorsi ed endpoint: i percorsi sono percorsi a cui è possibile accedere tramite una chiamata HTTP mentre un endpoint è un metodo HTTP (come get, post, put o delete) mappato su tale percorso.
• Richiesta: quando avvii una richiesta HTTP a un percorso REST registrato, WordPress creerà automaticamente un oggetto richiesta. I dati specificati nella richiesta determineranno quale risposta riceverai.
• Risposta: Un oggetto Response è un dato che si riceve quando si effettua una richiesta. Può comprendere dati richiesti o messaggi di errore.
• Schema: uno schema si riferisce alla struttura dei dati nell'endpoint. Ciascun endpoint può avere una struttura di dati leggermente o significativamente diversa che può restituire. Di conseguenza, uno schema determinerà tutte le possibili proprietà che un endpoint può restituire e tutti i possibili parametri che può ricevere.
• Classi controller: le classi controller consentono agli sviluppatori di gestire e registrare endpoint e route, consentendo loro anche di gestire richieste, utilizzare schemi e generare risposte.

Il "quadro" della reazione

Mentre ora entriamo nel vivo della relazione tra Gatsby.js e WordPress, per più contesto, dobbiamo decifrare questo panorama tecnologico da basi più storiche. React è la chiave di questa storia in quanto è la libreria/framework di frontend JavaScript in più rapida crescita. Resi famosi da Facebook (i suoi sviluppatori principali), altri grandi siti Web utilizzano React per il loro frontend come: Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace e Tesla.

Di conseguenza, poiché React è in pratica una libreria (poiché manca ancora di caratteristiche degne di nota di un framework a tutti gli effetti), ciò significa che è possibile progettare altri "framework" su di esso. Di conseguenza, uno di questi è Gatsby.js.

Presentazione di Gatsby

Secondo il suo sito Web principale, Gatsby.js è un framework JavaScript gratuito e open source basato su React che aiuta gli sviluppatori a creare siti Web e app veloci. In linea di principio, Gatsby.js genera pagine HTML statiche dalle applicazioni per il caricamento iniziale, quindi procede come un'applicazione React (SPA) a pagina singola.

Attributi di Gatsby.js

In tali circostanze, Gatsby sfrutta i principi dell'app Web progressiva (PWA) per recuperare prima solo gli elementi richiesti, quindi caricare il resto dell'applicazione in background in un secondo momento. Inoltre, per garantire che vengano caricati solo i dati richiesti, Gatsby sfrutta il linguaggio di query GraphQL (anch'esso di Facebook) per caricare i dati dalla sorgente. Mantiene anche un'eccezionale ottimizzazione dell'immagine.

L'unione di tutte queste funzionalità offre agli sviluppatori gli strumenti necessari per creare siti Web e app Web più veloci possibili poiché carica solo HTML, CSS, dati e JavaScript critici. Quindi, una volta caricata una pagina, Gatsby precarica le risorse per le pagine collegate e quindi la navigazione nel sito è piuttosto veloce.

Inoltre, poiché le pagine vengono generate al momento della compilazione, prima del posizionamento online, non hai più bisogno di potenti server PHP e puoi servire file statici (HTML, JS e CSS, direttamente dallo storage del bucket). Inoltre, poiché Gatsby è alimentato da React, sarai in grado di strutturare bene tutto con i componenti. Questo aspetto modulare consente agli sviluppatori di riutilizzare facilmente i componenti.

Altre caratteristiche significative di Gatsby includono:

• Generatore di siti statici
• Accesso offline
• Precaricamento delle pagine collegate
• Cache della pagina
• Nessun recupero di codice estraneo
• Esporta come codice
• Contenuto di ricarica a caldo
• Codice di ricarica a caldo
• Componentizzazione
• Associazione dati unidirezionale
• Query dati API dichiarative (GraphQL)
• Interfaccia utente dichiarativa
• Caricamento progressivo delle immagini
• Caricamento reattivo dell'immagine
• Inlineing del CSS critico
• Auto-hosting dei caratteri
• Senza server
• Condutture di asset
• Estensioni CSS (SaSS)
• Sintassi JavaScript avanzata
• Ecosistema dei componenti di reazione

Plugin Gatsby

In sostanza, i plug-in Gatsby sono fondamentalmente pacchetti Node.js che utilizzano l'API Gatsby. Questi plugin possono aggiungere origini dati, trasformare i dati in altri formati e aggiungere servizi di terze parti. Sebbene Gatsby.org mantenga una libreria di plug-in che include molti plug-in già realizzati realizzati dal team principale di Gatsby o da terze parti. Idealmente, per installare un plug-in per un progetto Gatsby, gli sviluppatori utilizzano il Node Package Manager (NPM) sul loro terminale UNIX ed eseguono il comando npm install.

Come GraphQL Comes si collega a Gatsby.

GraphQL ruota attorno all'idea che puoi descrivere all'API esattamente i dati che desideri esattamente e riceverai esattamente questo. Di conseguenza, è più efficiente di REST. A tal fine, Gatsby utilizza Webpack e GraphQL. Ancora più importante, con GraphQL come linguaggio di query, tutto è definito dal lato del client che esegue la query, con il client ignaro del funzionamento insufficiente dell'applicazione.

Questa implementazione unica consente agli sviluppatori di connettere qualsiasi origine dati a Gatsby. Ad esempio, i post del blog possono provenire da file Markdown, fogli di Google o persino da un altro sito Web WordPress. Quindi, fornendo una maggiore flessibilità con la consegna dei contenuti.

Meccanismo Gatsby-WordPress (plugin di origine)

Man mano che scompattiamo ulteriormente questa relazione, dobbiamo comprendere i plug-in di origine. I plug-in di origine sono plug-in speciali che funzionano all'interno del sistema di dati di Gatsby. Come suggerisce già il nome, traggono dati da posizioni diverse, locali o remote. Di conseguenza, i dati vengono quindi trasformati in ciò che Gatsby chiama nodi e campi nodo. Fondamentalmente, i campi dei nodi rappresentano un singolo pezzo di dati all'interno di un nodo e, in definitiva, è possibile accedere a questi nodi tramite una query GraphQL.

Nella stessa ampiezza, attraverso i plug-in di origine, Gatsby supporta dozzine di opzioni CMS senza testa, avvalendosi dei team di progettazione e contenuti del comfort e della familiarità della sua interfaccia di amministrazione preferita con l'esperienza degli sviluppatori migliorata e i vantaggi in termini di prestazioni dell'utilizzo di Gatsby, GraphQL e React per creare un fine frontale.

Il plug-in "Gatsby-source-WordPress" è creato e gestito dal core team di Gatsby e estrae i dati da siti WordPress self-hosted o WordPress.com. Implica anche l'autenticazione OAuth all'API di Word-Press.com e consente inoltre agli sviluppatori di interrogare immagini reattive.

In sostanza, questo plug-in supporta tutte le entità sull'API REST di WordPress come post, pagine, tag, categorie, media, tipi, utenti, stati, tassonomie, metadati del sito e tipi di post personalizzati. Inoltre, sono supportate anche le entità Advanced Custom Fields (ACF) e le informazioni sul linguaggio Polylang e WPML, oltre ad altri meta post registrati nell'API REST.

Quindi, con questo plugin, gli sviluppatori possono scegliere quali percorsi recuperare, sebbene per impostazione predefinita recuperi tutti gli endpoint di wpjson. Quindi, gli sviluppatori possono recuperare i dati da WordPress con GraphQL utilizzando il meccanismo di cui sopra.

In pratica, lo strumento "Gatsby-source-WordPress" fornisce uno slug per tutti i post e altre entità. E quindi, tutto ciò che un ingegnere deve fare è creare una pagina che chiama la funzione "createPage". Questo viene eseguito nel file Gatsby-node.js, di solito eseguendo prima la query per l'origine dati e quindi chiamando "createPage" per ogni nodo trovato, quindi impostando un file modello da utilizzare come componente.

CI/CD e automazione del rilascio delle applicazioni.

Quando si implementa un CMS WordPress headless con Gatsby, il modo in cui viene eseguita la distribuzione è estremamente critico. In genere, tali esecuzioni richiedono che la distribuzione di un'applicazione sia automatizzata utilizzando Application Release Automation (ARA).

In generale, ARA comporta funzioni primarie:

• Distribuzione di dati, codice applicativo e artefatti.
• Implementazione di configurazioni specifiche per ogni ambiente
• Progettazione del flusso di lavoro di processo per l'automazione delle attività e delle fasi di distribuzione.
• Infine, la modellazione dell'ambiente e/o il provisioning dei binari

Poiché Gatsby produce siti statici, è fondamentale impostare una pipeline ARA in modo che quando il contenuto viene aggiornato in WordPress, possa essere aggiornato di conseguenza nel sito Gatsby. In genere, la distribuzione continua viene attivata solo quando il codice cambia, tuttavia, per questa istanza, è consigliabile attivarla quando i dati cambiano. Quindi, per questo, ti consigliamo di utilizzare Netlify in quanto possiede straordinarie capacità di distribuzione continua integrate ed è facile da configurare.

Interrogazione da WordPress utilizzando GraphQL e gatsby-source-WordPress

A titolo illustrativo, gatsby-source-WordPress funziona in modo da recuperare prima tutto sul tuo endpoint utilizzando REST. Quindi genererà un'API GraphQl interna basata su quei dati. Successivamente, esaminerà le tue query e raccoglierà i dati dall'API GraphQL interna. Quindi, in pratica, la tua build finisce solo con i dati che hai chiesto e nient'altro.

Vantaggi dello sviluppo di WordPress senza testa con Gatsby.js

Dato che abbiamo parlato dello sviluppo di WordPress senza testa con Gatsby, ora possiamo analizzare i vantaggi di questo tipo di approccio tecnico. Questo dovrebbe essenzialmente guidare la tua decisione sull'adozione o meno di Gatsby!

• Il primo vantaggio è la possibilità di avere un sito statico prerenderizzato. Questo è il modo più efficiente per eseguire il rendering di una pagina Web e poiché Gatsby utilizza GraphQL per eseguire la quantità minima di dati necessaria, ciò fornisce una maggiore efficienza per il tempo successivo al caricamento iniziale.
• Visibilità SEO migliorata: le pagine statiche sono facili da leggere per i motori di ricerca poiché tutto è prerenderizzato e indicizzabile. Questo è un aspetto positivo, in contrasto con altri meccanismi senza testa in cui il rendering di pagine con JavaScript è un problema relativo all'ottimizzazione dei motori di ricerca (SEO).
• Velocità di sviluppo relativamente rapida: rispetto ad altri approcci senza testa, Gatsby ha un modo unificato e di facile comprensione per recuperare i dati indipendentemente dalla fonte. Ciò rende lo sviluppo piuttosto semplificato in quanto puoi concentrarti sul tuo sito reale e lasciare che Gatsby si occupi della maggior parte del lavoro pesante.
• Hosting più economico: puoi ospitare la tua applicazione Gatsby ovunque poiché serve solo file statici, riducendo così le spese di hosting. Inoltre, poiché WordPress viene chiamato solo durante il processo di compilazione e mai durante la sessione utente, può essere ospitato anche su una soluzione di hosting conveniente.
• Sicurezza avanzata: in generale, i generatori di siti statici sono estremamente sicuri poiché non esiste una connessione diretta a un database, dipendenze, dati utente o altre informazioni sensibili.
• Senza plug-in: dal punto di vista di un non sviluppatore, WordPress è abbastanza facile da usare grazie ai plug-in disponibili. Tuttavia, ciò limita l'implementazione di funzionalità personalizzate. Sfortunatamente, anche troppi plugin possono rallentare un sito poiché diventa pesante e difficile da renderizzare. Un'esecuzione di Gatsby elude essenzialmente tutti questi colli di bottiglia.

Altre sfaccettature che possono motivarti a considerare Gatsby con WordPress:

• Pannello di amministrazione di WordPress facile da gestire.
• Sistema di accesso utente pronto all'uso e autorizzazione.
• Con l'editor di Gatsby e Gutenberg, puoi creare un costruttore di siti Gatsby con trascinamento.

Svantaggi dello sviluppo di WordPress senza testa con Gatsby.js

• Limitazioni di aggiornamento: quando il contenuto cambia da zero, imposta restrizioni sulla frequenza con cui il tuo sito può essere aggiornato. Inoltre, possono essere necessari fino a 10 minuti per eseguire la build di Gatsby se il tuo sito contiene molti dati, il che può essere un problema per i siti che si aggiornano frequentemente.
• Aggiornamenti regolari Hustles: Inoltre, poiché Gatsby è un generatore di siti statici, non può essere semplicemente "modificato", poiché anche una piccola modifica del testo richiederà una nuova distribuzione. Quindi, se disponi di una pagina che richiede molte modifiche giornaliere dinamiche ai contenuti, questo può richiedere molto tempo e diventare un trambusto.
• Ritardi: in genere devi attendere diversi minuti per vedere le modifiche ai tuoi contenuti mentre vengono pubblicati.
• Mancanza di anteprime: a differenza delle tradizionali applicazioni WordPress, in Gatsby non hai alcun tipo di anteprima. Purtroppo, questo è stato il problema più grande che i creatori di contenuti hanno riscontrato con Gatsby. Dovrai compilare tutto, probabilmente con le pipeline CI/CD di Gitlab che compilano il sito Web e mettono tutto online.
• Curva di apprendimento ripida: in genere, se desideri lavorare con Gatsby e WordPress contemporaneamente, devi avere una certa familiarità con entrambi i linguaggi PHP e JavaScript. Poiché Gatsby unisce React e GraphQL, questa può essere una curva di apprendimento ripida per molti.

Pensieri finali.

In conclusione, grazie alle sue prestazioni e ai vantaggi aziendali, sempre più aziende stanno implementando Gatsby come parte del proprio stack tecnologico. Anche se è importante ricordare che unendo Gatsby con WordPress, WP diventa solo back-end, il che implica che perderai alcune delle sue funzionalità e abilità.

Inoltre, gli sviluppatori esperti con lo sviluppo di WordPress troveranno Gatsby come un ottimo strumento con i suoi moderni vantaggi in termini di prestazioni, scalabilità, sicurezza e velocità di sviluppo. Tutto questo consentendo loro di mantenere l'interfaccia utente familiare per la creazione di contenuti offerta da WordPress.

Tuttavia, prima di avviare questa tecnologia, si dovrebbero sempre considerare le specifiche e gli obiettivi del progetto. Ad esempio, se l'enfasi è su scalabilità, prestazioni, velocità di sviluppo, lungo ciclo di vita, Gatsby lo farà. Tuttavia, se l'enfasi è quella di avere maggiore flessibilità e strumenti per i creatori di contenuti non programmatori con contenuti aggiornati al secondo o al minuto, allora puoi prendere in considerazione un approccio alternativo.