Introducing DatoCMS: CMS per siti statici

È passato un anno da questo post, e DatoCMS finalmente in beta pubblica! Crea il tuo primo sito totalmente statico con DatoCMS registrandoti su http://www.datocms.com

È questo il massimo che il settore IT riesce ad offrire? Dovremmo fare di meglio. Dobbiamo in realtà, perché possiamo. Da un mese a questa parte in Cantiere abbiamo deciso di occuparcene, possibilmente una volta per tutte: il risultato l'abbiamo chiamato DATO (code-name ancora provvisorio) che è stato ufficialmente aggiunto alla lista dei nostri prodotti.

DatoCMS è un CMS-as-a-Service: un servizio centralizzato che offre un'interfaccia web di modifica dei contenuti del proprio sito — esattamente alla stregua di Wordpress o qualsiasi similare. La differenza rispetto a Medium, Wordpress.com piuttosto che Tumbr? Almeno un paio:

• Un backend amministrativo perfettamente aderente alle specifiche esigenze di editing del proprio sito;
• Ogni modifica ai dati produce un sito 100% statico, pubblicato automaticamente in una CDN: rapido, economico, sicuro e scalabile.

Curiosi della motivazione alla base di quest'ultima scelta? Continua a leggere :)

Innanzitutto, che differenza c'è tra un sito statico ed uno dinamico? Nessuna, per un osservatore esterno: entrambe vengono visualizzate esattamente allo stesso modo. Ciò che cambia è la modalità con cui le pagine HTML che compongono il sito vengono scritte.

Un sito statico è composto da una serie di file HTML organizzati in differenti sotto-cartelle. Niente PHP, niente Ruby, niente database, niente CMS. Semplici, vecchi, noiosi file testuali che all'atto della pubblicazione vengono caricati su uno spazio hosting, e che da quel momento possono essere visualizzati così come sono da un visitatore.

Un sito dinamico è invece un sito in cui le pagine HTML vengono "scritte" on-demand ad ogni nuova visita che viene effettuata sul sito. Da chi vengono scritte? Da un software che risiede nello spazio hosting e che rimane costantemente in ascolto di nuove richieste da soddisfare.

Un sito web, per essere in grado di presentare informazioni differenti a seconda del visitatore che lo naviga, non può che passare per questa strada, e proprio per questo motivo, in questo momento, la quasi totalità dei siti che navighiamo quotidianamente segue esattamente questa logica.

Questo drastico cambiamento, da statico a dinamico, è stata la leva che ha permesso la rivoluzione digitale che stiamo vivendo in questa decade, ma non è stato certo un cambiamento senza svantaggi o costi:

1. Hosting e performance. Un sito statico può essere hostato in maniera estremamente semplice su di una CDN, ovvero un network di server dislocato uniformemente nel globo. Una CDN è in grado di garantire tempi di risposta estremamente rapidi e senza disservizi: se uno dei server del network va giù, il traffico viene semplicemente rediretto verso un altro server. Se possiedo un sito Wordpress hostato presso Aruba, ed il server Aruba subisce un incendio, il mio sito rimane offline (ogni riferimento a fatti o persone è puramente casuale).
2. Sicurezza. Un sito statico non ha "parti mobili", dunque non è fisicamente possibile che sia soggetto ad attacchi di alcun genere. Punto. Una volta online, un sito statico rimane online per sempre.
3. Velocità e semplicità. Essendo già confezionato a monte, un sito statico non ha bisogno di alcuno sforzo ingegneristico per ottimizzare i tempi di renderizzazione di una pagina. Inoltre, svanisce totalmente la necessità di manutenzione nel tempo: non è necessario aggiornare server o software, in quanto assenti dall'architettura.
4. Costi. Scalare, ovvero essere in grado di garantire il corretto funzionamento del sito all'aumentare del numero dei visitatori, è molto, molto, molto più economico con un sito statico. Non è necessario acquistare servizi di hosting più capienti o gestire spike incontrollati di traffico: tutto viene gestito automaticamente dalla CDN.

Riprendiamo il filo da dove l'avevamo lasciato, ovvero: la quasi totalità dei siti che navighiamo quotidianamente sono dinamici. La domanda che sorge spontanea, alla luce di questi dati inconfutabili, è la seguente: non ci siamo fatti prendere un po' troppo la mano con i siti dinamici? :)

Escludiamo per un attimo Facebook, Twitter, Google e gli altri giganti del web, e focalizziamoci sul 98% rimanente della Rete: quanti di questi siti presentano effettivamente informazioni differenti a seconda del visitatore, o subiscono aggiornamenti in tempo reale? Quanti invece, a voler esagerare, vengono aggiornati non più di una volta al giorno?

La parte "dinamica" dell'architettura, per tutti questi siti, viene sfruttata davvero solo dagli admin, durante la navigazione nel backend del proprio CMS, in concomitanza con l'aggiornamento del proprio sito.

Per il resto del tempo, decine di milioni di server in giro per il mondo continuano a produrre ad ogni visita la medesima pagina prodotta un secondo prima, ed i visitatori "subiscono" una architettura dinamica che produce solo effetti negativi sulla loro esperienza: lentezza, instabilità, potenziali vulnerabilità.

È importante realizzare come l'architettura "dinamica", per la stragrande maggioranza dei siti web, non sia che un enorme costo ingiustificato: quello di cui abbiamo bisogno come standard per il sito medio è una architettura "semi-statica", in grado di unire il meglio dei due mondi.

1. offrire un CMS in cui chiunque è in grado di aggiornare il proprio sito in autonomia, senza alcuna competenza informatica avanzata;
2. conseguentemente ad ogni atto di modifica dei contenuti del sito da parte di un admin, generare automaticamente le nuove pagine statiche HTML una-tantum, e servirle tramite CDN fino alla successiva modifica.

L'ultimo punto, fortunatamente, è un problema già risolto da tool denominati static site generators, letteralmente "generatori di siti statici". Ne esistono a centinaia, per tutti i gusti e in ogni possibile linguaggio di programmazione. Il problema è oggi sono destinati ad una nicchia di utenza, fatta principalmente di programmatori. È necessario saper lanciare comandi da terminale, maneggiare file Markdown, modificare file di configurazione... nulla di complesso, ma semplicemente improponibile per un'utenza non tecnica e giustamente abituata alla semplicità e l'immediatezza di un CMS web-based.

Abbiamo immaginato un servizio in grado di risolvere tutti questi problemi, e l'abbiamo realizzato in piena ottica MVP: il minimo indispensabile per validare l'idea alla base. Quello che stiamo per condividere è il risultato delle prime 100 ore di sviluppo.

Supponiamo di voler sfruttare DatoCMS per il sito del Rubyday 2015 (http://www.rubyday.it). DatoCMS è in grado di generare quelli che abbiamo chiamato Spazi: veri e propri backend amministrativi, attraverso il quale poter gestire contenuti di qualsiasi genere e forma.

Il primo passo è far puntare un dominio di secondo livello a nostra scelta (es. `http://admin.rubyday.it) verso uno specifico Spazio attraverso un'entry CNAME. A questo punto è possibile associare al nostro Spazio un numero illimitato di editori, che potranno loggarsi per poter gestire il sito in autonomia.

Login all'admin DATO

Una volta loggati, questo è quello che ci si trova di fronte:

La home page admin di DATO

Sponsor, Talk, Post, Pagine di servizio... lo sviluppatore è in grado di configurare nel giro di pochi minuti l'esperienza di editing sulle specifiche esigenze del sito, con la possibilità di impostare Tipologie di Contenuto customizzate con l'esatto numero di campi necessari.

Ad oggi DatoCMS mette a disposizione le seguenti tipologie di campo (opzionalmente in multi-lingua):

• Testo (Titolo con slug, Stringa, Textarea, WYSIWYG)
• Numeri (interi, float)
• Booleani (checkbox)
• Data/ora
• Immagini (Drag & drop con upload AJAX su Amazon S3 ed image processing tramite Imgix)
• Informazioni SEO (campi meta title, description, Twitter Card, Facebook Opengraph, ...)
• Relazioni tra record (uno a molti, molti a molti)
• Inserimento di coordinate geografiche tramite Google Maps

Nuovi campi arriveranno ovviamente non appena ne sentiremo la necessità. Le Tipologie di Contenuto possono generare collezioni di Record (es. gli articoli del blog) o essere di tipo "singleton", ovvero permettere l'editing di un solo Record (es. impostazioni relative alla Homepage).

Una form di un modello con i campi esposti dall'API

DatoCMS espone una API che può essere utilizzata da un qualsiasi static-site generator per ottenere tutti i dati presenti nel backend. Ad oggi è stato creato un primo plugin per Middleman che permette di lavorare con DatoCMS alla stregua dei suoi Data files locali. Sono presenti anche helper in grado di generare in automatico le informazioni SEO per ciascuna pagina.

DatoCMS lavora in sincronia con un sistema di Continuous Deployment (ad oggi è stato implementato un adapter per GitlabCI): non appena viene prodotta una modifica sui dati da parte dell'editor, DatoCMS avvisa l'utente della necessità di pubblicare le modifiche ed è in grado di richiedere attraverso un webhook una nuova staticizzazione e pubblicazione su Amazon S3 del sito entro pochi secondi:

Quando un contenuto viene modificato da qualunque utente, appare un alert.

La fase di pubblicazione genera i contenuti statici e li pubblica sulla CDN in circa 30 secondi.

Il sito è online, yeah!

Certo, 100 ore di sviluppo sono poche e c'è tanto lavoro ancora da fare, ma sono state ore sufficienti per vedere con i nostri occhi, in produzione, il potenziale di una simile architettura:

• siti indistruttibili, a prova di prime-time televisivo;
• costi praticamente nulli di hosting;
• una semplicità di editing che non ha nulla da invidiare a qualsiasi altro CSM;
• tempi di sviluppo per un sito radicalmente ridotti (grazie Middleman!);