Web, la parola d’ordine è decoupling: JAMstack vs Wordpress

Decoupling, ovvero disaccoppiamento, è un processo in atto nel mondo delle tecnologie web degli ultimi anni. Si tratta del superamento di complesse architetture software in favore di servizi agili e snelli, spesso forniti da terzi, inseriti in una semplice pagina html.

Ogni giorno nasce qualche nuovo utile strumento che possiamo integrare facilmente nelle nostre applicazioni e nei nostri siti, ma questo diventa difficile se i nostri portali su architetture monolitiche o CMS che gestiscono un po’ tutto.

Un sito moderno usa servizi esterni per quasi tutto: commenti, mail, newsletter, recensioni, marketing.
Di fatto nel web del futuro ci preoccupiamo di fornire solo i nostri contenuti e ci attacchiamo un ecosistema di applicazioni e servizi.
Più separiamo le funzioni, più eliminiamo infrastrutture (come server, proxy, database), meglio è a livello di programmazione e gestione.
Quello che può stupire è che anche i risultati e i risparmi sono notevoli.

Prima di lanciare Trame Digitali, abbiamo lavorato una vita per agenzie e progetti tra Prato, Firenze e Pistoia, creando app, software, e-commerce e, sì, siti Web per i clienti.

Abbiamo sperimentato diversi strumenti per la creazione di siti e, come la maggior parte delle agenzie e dei consulenti, abbiamo finito per scegliere i nostri CMS e attenerci ad essi. Usare un CMS era una strada obbligata: ti aiutava ad organizzare lo sviluppo e dava ai clienti la possibilità di gestire in autonomia il proprio sito.

Ma questo era anni fa..

Come innumerevoli sviluppatori, abbiamo presto sentito il peso di lavorare con un CMS.

Il problema principale era uno: i CMS tradizionali stavano solo cercando di fare… troppo.
Ci siamo resi conto di quanto fossero macchinosi e ingombranti. Continuavamo a ricevere richieste di supporto da parte di clienti che “semplicemente non riuscivano a capirlo”.
I pannelli di amministrazione user-friendly hanno iniziato ad essere infarciti di mille funzioni e quindi sempre meno friendly, dando fin troppo potere all’utente e aumentando quindi le probabilità di fare danni accidentali al sito.

Per non parlare delle performance. Se per pubblicare 10 pagine uso un sistema che impegna risorse per attivare altre 30 inutili funzionalità, quanto meno ho uno spreco non indifferente di risorse e di tempi di caricamento. I quali hanno comportato l’adozione di sistemi di cache sempre più complessi.

Con Wordpress la situazione migliora solamente perchè essendo molto diffuso ci siamo abituati al suo pannello di amministrazione, mentre i problemi di sicurezza si aggravano proprio per via della sua notorietà: girano più velocemente le notizie dei suoi bug che gli aggiornamenti e i fix.

Potresti aver sentito parlare di questo nuovo paradigma di sviluppo battezzato JAMstack (JavaScript, API e Markup), che fa della separazione delle funzioni la propria filosofia.
Grazie a browser moderni, generatori di siti statici, CDN e API, stiamo ora assistendo alla transizione degli sviluppatori Web da applicazioni server-side dinamiche a stack modulari lato client.
Questo sta comportando un significativo spostamento di attenzione dal backend al frontend, ora più potente grazie ai tanti strumenti disponibili.

JAMstack non è un insieme di strumenti o tecnologie specifiche. È un nuovo modo di creare siti web e app che offrono prestazioni migliori, maggiore sicurezza, minori costi di scalabilità e una migliore esperienza di sviluppo.

Sostanzialmente è un ritorno ai siti statici (si, quelli scritti in HTML e CSS), che attraverso Javascript e API offrono le stesse opportunità di pesanti CMS centralizzati. Questi ultimi per altro, per estendere le proprie funzionalità a loro volta spesso ricorrono a servizi esterni attraverso plugin creati ad hoc.

Il tuo progetto è costruito con JAMstack se soddisfa tre criteri chiave:

JavaScript
Qualsiasi parte dinamica durante il ciclo di richiesta / risposta è gestita da JavaScript, interamente eseguita sul client. Questo potrebbe essere qualsiasi framework di frontend (esempio REACT, Angular, Vue.js), libreria (jQuery) o anche vanilla JavaScript.
Se vi stavate già fregando le mani pensando di non dover programmare più, avrete capito che non è così: stiamo rendendo più “intelligenti” i nostri client/browser e più “stupidi” i nostri server (a volte forse inutili). Indovinate dove si annidano i costi maggiori…

API
Tutti i processi sul lato server o le azioni del database sono astratti in API riutilizzabili, accessibili tramite HTTPS dal JavaScript. Questi possono essere personalizzati o sfruttare servizi di terze parti. Ormai i fornitori di servizi ed API, proprio in virtù del diffondersi di stack di questo tipo, forniscono spesso il codice da integrare per interrogare e usare i propri contenuti.
Ci sono veri e propri CMS headless, che forniscono solo i contenuti e non le pagine, che si integrano. Immaginatevi uno wordpress in cui inserite gli articoli e basta e poi questi vengono utilizzati in maniera indipendente da uno o più siti internet indipendenti o dalle app del vostro cellulare. In cambio di pochi euro al mese potete dimenticarvi server, database e problemi di manutenzione.

Markup
Il markup dei template è “pre-compilato” in fase di distribuzione, solitamente si utilizza un generatore di siti statici o strumenti per applicazioni web.
Non venendo generato dinamicamente, in tempo reale, non ha bisogno quindi di girare con tutto il codice del generatore (il motore, il sistema, il cms), e quindi può essere diffuso direttamente da CDN o da hosting di risorse contenute.

Ecco un veloce riepilogo per comprendere le principali differenze tra i due approcci:

Flusso di lavoro tradizionale

→ Costruzione e hosting sono accoppiati.

→ Un utente richiede una pagina. Il file viene elaborato e servito dopo una (lunga) serie di interazioni tra un database, un codice di back-end, un server, un browser e livelli di memorizzazione nella cache.

→ Gli aggiornamenti principali vengono inviati ai server di produzione, spesso tramite FTP. Il database deve essere mantenuto o aggiornato.

→ Gli aggiornamenti dei contenuti vengono gestiti tramite CMS tradizionale, come WordPress o Drupal.

Flusso di lavoro JAMstack

→ Struttura e hosting sono disaccoppiati.

→ Un utente richiede una pagina. Il file è già compilato e viene fornito direttamente al browser da una rete CDN.

→ Gli aggiornamenti di base vengono inviati tramite Git; il sito viene ricostruito interamente tramite moderni strumenti di compilazione come generatori di siti statici e builder specifici per web app.

→ Gli aggiornamenti dei contenuti vengono inviati tramite Git o un CMS headless o un admin per il sito statico.

Ovviamente, quest’ultimo approccio porta molti vantaggi:

Il contenimento delle operazioni lato server e del database rimuove molti punti di errore e gli exploit di sicurezza.

Il contenuto statico offerto tramite CDN (possibile perché il contenuto è statico e precompilato) rende le esperienze utente più veloci.

La minore complessità dello sviluppo riduce i costi.

La riduzione della manutenzione più la flessibilità nei flussi di lavoro diminuiscono la depressione e l’alcolismo tra gli sviluppatori.

Scherzi a parte, c’è un sacco di valore nell’approccio JAMstack, sia per gli sviluppatori che per i clienti. Vuoi scavare più a fondo? Rimani in contatto con noi.

Io per primo preferisco ignorare le caratteristiche tecniche se non sono trasformabili in tangibili vantaggi commerciali.

Prendiamo ad esempio la rimozione delle query del database e il contenuto basato su CDN. Possiamo ridurre questa semplificazione ad un aumento di prestazioni. Ma che valore può avere per un cliente?

Per prima cosa, potresti aprire un’app di test della velocità su un servizio come Pingdom o testmysite.io e visualizzare due siti molto simili (o lo stesso), uno statico e uno dinamico. La differenza nei risultati è notevole. Il tempo di caricamento della pagina è diventato cruciale per la user experience e la SEO.
Una semplice associazione quindi ci spiega il primo beneficio:

→ Sito statico = sito più veloce = migliore esperienza utente e classifiche Google = più traffico = più €

Ora per le parti lato server, introduciamo l’argomento affidabilità: un sito dinamico è come un castello di carte a 6 piani, più vulnerabile al collasso perché ha più parti e una struttura più complessa. Un sito statico, d’altra parte è un castello di carte da 1 piano. Facile da costruire e mantenere.

→ Sito statico = sito più semplice = più sicuro e affidabile = meno spese imprevedibili e più tranquillità

E - ultimo ma non meno importante - è possibile tradurre nel bilancio i ridotti costi operativi e di sviluppo:

“Eliminando il server web più performante, i database, i plugin e la manutenzione costante, ti faremo risparmiare X migliaia di euro l’anno.”