Un sito statico (static site generator) potrebbe essere la risposta a molti utenti che hanno bisogno di un sito web sempre performante per la pubblicazione dei loro articoli/recensioni. Vediamo in breve di cosa si tratta

BENVENUTI

Prima di tutto vorrei dare il benvenuto a tutti quegli utenti che atterreranno su questo post riguardante al mio nuovo blog. Si tratta di un sito che avrà lo scopo di approfondire argomenti riguardante il mondo della programmazione, web development, gestione di server in remoto, iOT e argomenti che vanno di pari passo.

STATIC SITE GENERATOR (SSG)

I primi siti, semplici e banali, che ho creato erano in php e per evitare di ripetere di scrivere sezioni di codice molteplici volte in varie pagine del sito (primo su tutti il menu nell’header) esse venivano incluse in un file principale e ripetute più facilmente. Questo risultava in un guadagno di tempo e rendeva il progetto più mantenibile nel tempo.

Il server web inseriva in realtime i vari files e produceva l’output richiesto qualvolta la richiesta veniva effettuata. Venivano combinati i vari templates e contenuti, loops e logiche, per ottenere la pagina richiesta.

Questo sistema aveva un grosso problema: il server doveva diventare proporzionalmente più potente in base a quanto il sito diventava popolare.

Le caratteristiche principali

Uno Static Site Generator (SSG) è similmente comparabile a un sito web tradizionale. Dati e contenuto sono suddivisi in templates assemblati tra di loro per generare la pagina che l’utente dal proprio PC/smartphone visita.

La grande differenza tra il metodo tradizionale e SSG è che nel primo caso la pagina viene generata ondemand, cioè nel momento in cui viene richiesta dall’utente, mentre in un sito statico la pagina viene assemblata precedentemente ed è sempre disponibile, già pronta.

Pensate a un Static Site Generator come a uno script che ha come input testo, contenuti, immagini e templates, li processa e produce in una cartella separata i files assemblati e pronti da servire all’utente che ne chiede la visione.

I benefici sono molteplici, ma il più importante riguarda il carico del server in cui viene ospitato il sito web: essendo le pagine create precedentemente e non al momento del bisogno, il carico del server risulta irrisorio e non è più proporzionale in base al numero di richieste soddisfatte.

Perché usare un sito statico

I vantaggi di gestire un sito statico sono molteplici: I principali, credo, sia questi:

• Sicurezza
• Scalabilità
• Performance

Sicurezza

Servendosi solo di assets statici (semplificando: le pagine html, le immagini) che possono essere serviti da semplici server o CDN, la sicurezza è molto elevata. Infatti per visualizzare le pagine del sito, essendo create precedentemente e pronte per essere servite agli users, l’infrastruttura impiegata può essere drasticamente semplificata eliminando molti vettori di possibili attacchi informatici. Rimuovendo il bisogno di server che effettuano operazioni logiche e lavori difficoltosi, come ad esempio database, si riducono possibili opportunità di inserire codice maligno beneficiando di meno attori nell’infrastruttura e aumentando la sicurezza in generale.

Scalabilità

La bellezza di un sito già generato è che ogni pagina è pronta per essere servita senza un lavoro addizionale da parte del server per ogni richiesta. Non c’è bisogno di aggiungere maggiore potenza di calcolo al server all’aumentare del traffico perché non si sta compilando nulla prima di inoltrare la pagina all’utente.

Servire un sito in questa modalità è simile alla gestione di un’architettura cache tradizionale, solitamente aggiunta come un ulteriore layer all’infrastruttura presente e utilizzata con la differenza che non si deve aggiornare la cache del sito in base a molteplici parametri. Con un server statico si può ottenere lo stesso risultato: infatti tutto può essere inserito nella cache di un CDN e servito direttamente da li. Per questo motivo l’architettura è scalabile di default.

Performance

Il tempo necessario per una richiesta per essere evasa dipende dalla distanza del server al device dell’utente, dal numero di sistemi informatici coinvolti e dal lavoro che ogni sistema deve svolgere.

Quando si utilizza un sito statico, l’utente non deve interagire con nessun server; la richiesta verrà evasa da un CDN rendendo breve la distanza tra esso e il device, ed escludendo totalmente qualsiasi interazione con dei classici server web.

HUGO

Tra i tanti software per creare siti statici, ho preferito affidarmi a Hugo.

Hugo è il framework per costruire site web statici più veloce al mondo. Come è scritto nella homepage del loro sito:

The world’s fastest framework for building websites

È sviluppato in GO, un linguaggio di programmazione open source creato da Google.
Usando GO per creare backend conoscevo già:

• le super prestazioni di questo linguaggio;
• le goroutine previste fin dall’inizio del suo sviluppo rendendo il codice concorrenziale senza troppe difficoltà;
• la facilità di programmazione con questo linguaggio.

Questi lati positivi mi hanno spinto a provare Hugo anche se non è necessario conoscere il linguaggio di programmazione in cui è scritto, è solamente necessario conoscere Markdown, ma con apposite modifiche si può evitare di usare anche quello!

Caratteristiche

Le caratteristiche principali di Hugo sono:

• Tempo di scrittura per pagina < 1 ms;
• Utilizzo di Markdown per la scrittura dei post e di shortcodes per avere maggiore flessibilità;
• Possibilità di creazione di siti multilingua;
• Flessibilità nel core di Hugo senza la necessità di installazione di plugin;
• Built-in templates in modo da velocizzare la pubblicazione;
• Custom output: non solo html, ma anche json, amp o personalizzato.

Principali Comandi

Hugo presenta molti comandi, per una lista completa è meglio affidarsi alla documentazione completa

Compilare il sito

hugo è il programma principale per costruire il sito

hugo [flags]

Server

hugo ha al suo interno un server molto performante

hugo server [flags]

Nuovo contenuto

Per creare un nuovo post nel sito

hugo new [path] [flags]

Flags

 -b, --baseURL string             hostname (and path) to the root, e.g. http://spf13.com/
  -D, --buildDrafts                include content marked as draft
  -E, --buildExpired               include expired content
  -F, --buildFuture                include content with publishdate in the future
      --cacheDir string            filesystem path to cache directory. Defaults: $TMPDIR/hugo_cache/
      --cleanDestinationDir        remove files from destination not found in static directories
      --config string              config file (default is path/config.yaml|json|toml)
      --configDir string           config dir (default "config")
  -c, --contentDir string          filesystem path to content directory
      --debug                      debug output
  -d, --destination string         filesystem path to write files to
      --disableKinds strings       disable different kind of pages (home, RSS etc.)
      --enableGitInfo              add Git revision, date and author info to the pages
  -e, --environment string         build environment
      --forceSyncStatic            copy all files when static is changed.
      --gc                         enable to run some cleanup tasks (remove unused cache files) after the build
  -h, --help                       help for hugo
      --i18n-warnings              print missing translations
      --ignoreCache                ignores the cache directory
      --ignoreVendor               ignores any _vendor directory
      --ignoreVendorPaths string   ignores any _vendor for module paths matching the given Glob pattern
  -l, --layoutDir string           filesystem path to layout directory
      --log                        enable Logging
      --logFile string             log File path (if set, logging enabled automatically)
      --minify                     minify any supported output format (HTML, XML etc.)
      --noChmod                    don't sync permission mode of files
      --noTimes                    don't sync modification time of files
      --path-warnings              print warnings on duplicate target paths etc.
      --print-mem                  print memory usage to screen at intervals
      --quiet                      build in quiet mode
      --renderToMemory             render to memory (only useful for benchmark testing)
  -s, --source string              filesystem path to read files relative from
      --templateMetrics            display metrics about template executions
      --templateMetricsHints       calculate some improvement hints when combined with --templateMetrics
  -t, --theme strings              themes to use (located in /themes/THEMENAME/)
      --themesDir string           filesystem path to themes directory
      --trace file                 write trace to file (not useful in general)
  -v, --verbose                    verbose output
      --verboseLog                 verbose logging
  -w, --watch                      watch filesystem for changes and recreate as needed

… e Wordpress??

Wordpress potrebbe essere considerata un’alternativa ma non l’ho neanche preso in considerazione per un semplice fatto: per gestire un blog, composto da pagine e articoli come rmazzu.com, non ho bisogno di un sito dinamico come me lo creerebbe Wordpress. Non ho bisogno di plugin, temi che per velocità di realizzazione si possono creare con un drag-and-drop, passare più tempo a fare un tuning del sito per renderlo veloce abbastanza da non far scappare gli utenti che pensare a contenuti da scrivere. No, se ho bisogno di un blog non ho bisogno di CMS (Content Managements Systems).

E queste motivazioni valgono anche per siti creati con Wordpress.

Ho già intenzione di creare un articolo in cui spiego le differenze tra un Static Site Generators e Content Managements Systems.

Stay Tunez..