L’architettura headless — separare il layer di gestione contenuti (backend) dal layer di presentazione (frontend) — è diventata lo standard per progetti web seri. Ma la scelta dei componenti giusti fa la differenza tra un’architettura elegante e una fonte di complessità inutile.
La combinazione Astro + Directus è quella che usiamo in Marfcode per la maggior parte dei progetti content-driven: siti corporate, portali informativi, e-commerce a catalogo, blog aziendali. Questo articolo spiega perché e come funziona nella pratica.
Il Problema con le Architetture Tradizionali
Un sito WordPress tradizionale è un monolite: il CMS gestisce contenuti, logica applicativa, template e rendering nella stessa applicazione. Funziona, ma ha limiti strutturali:
- Le performance dipendono dal server PHP che esegue la logica a ogni richiesta
- La sicurezza è esposta alle vulnerabilità del core e dei plugin
- La scalabilità richiede infrastruttura server dedicata
- Il frontend è vincolato ai template del CMS
L’architettura headless risolve questi problemi separando i ruoli: il CMS si occupa solo dei dati (e li espone via API), il frontend li consuma e produce HTML ottimizzato. I due layer possono scalare, aggiornarsi e deployarsi indipendentemente.
Perché Astro per il Frontend
Islands Architecture: JavaScript Solo Dove Serve
Il principio fondamentale di Astro è che la maggior parte delle pagine web non ha bisogno di JavaScript interattivo ovunque. Una pagina prodotto ha un carosello di immagini interattivo (serve JavaScript) e del testo descrittivo (non serve JavaScript). Un articolo ha commenti dinamici (serve JavaScript) e il corpo dell’articolo (non serve JavaScript).
Astro chiama “islands” i componenti interattivi in un mare di HTML statico. Solo le islands ricevono JavaScript. Il resto è markup puro, servito direttamente dal CDN senza alcun costo computazionale runtime.
Il risultato pratico: un sito Astro con Directus come sorgente dati produce punteggi di performance Lighthouse spesso tra 95 e 100 su performance, SEO e accessibilità — senza ottimizzazioni manuali aggressive.
Multi-Framework Support
Astro è agnostico al framework delle islands: puoi usare componenti Svelte, React, Vue o Solid per le parti interattive, mantenendo il resto in Astro nativo. Questo significa che componenti esistenti scritti in React possono essere riusati senza riscrittura — una scelta pragmatica che abbassa il costo di migrazione da architetture esistenti.
Integrazione Nativa con CMS Headless
Astro ha integrazioni ufficiali con decine di CMS headless. Con Directus, il flusso è diretto: al build time (o con ISR), Astro fetcha i contenuti dall’API Directus, genera le pagine HTML statiche e le pusha sul CDN. L’utente riceve HTML pre-renderizzato, non una pagina vuota che aspetta JavaScript.
Content Collections
Per contenuti strutturati (blog, documentazione, news), Astro ha un sistema di Content Collections con validazione dei tipi tramite Zod. Questo garantisce type safety tra il dato in Directus e il template che lo renderizza — eliminando una categoria intera di bug runtime.
Perché Directus come CMS Headless
Database-First, Non Schema Rigido
Directus funziona in modo inverso rispetto alla maggior parte dei CMS: si installa sopra un database SQL esistente (PostgreSQL, MySQL, SQLite) e genera automaticamente API REST e GraphQL per ogni tabella. Non c’è un “content model” predefinito da cui partire: il modello dei dati è esattamente quello che serve al progetto.
Questo ha conseguenze concrete:
Il cliente non è vincolato al vendor: i dati sono in un database SQL standard. Se tra cinque anni si vuole cambiare CMS o costruire un’applicazione diversa sopra gli stessi dati, è possibile senza migrazioni complesse.
Il data model si adatta al business: si possono creare relazioni complesse tra entità, campi computed, viste personalizzate — esattamente come in un database relazionale, con l’interfaccia visuale di un CMS.
Il pannello admin è configurabile: Directus non ha un “editor di contenuti” fisso. Il pannello può essere configurato per assomigliare a qualsiasi gestionale — con campi custom, layout personalizzati, flussi di approvazione, ruoli e permessi granulari.
API Flessibile
Directus espone ogni risorsa via REST e GraphQL con filtri, ordinamento, paginazione e relazioni in un’unica chiamata. Non è necessario un layer GraphQL aggiuntivo per query complesse: ?filter[status][_eq]=published&fields=*,autore.nome,categorie.titolo è una chiamata REST che restituisce dati normalizzati con relazioni incluse.
Per frontend come Astro che fetchano dati a build time, questa flessibilità riduce il numero di chiamate API necessarie e la complessità del layer di data fetching.
Self-Hosted o Cloud
Directus può essere self-hosted (su un VPS, su Docker, su Cloudflare con adattamenti) o usato come servizio cloud gestito. Per la maggior parte delle PMI, la versione self-hosted su un VPS da 20–40€/mese copre qualsiasi esigenza di contenuto senza costi ricorrenti legati al volume di dati o di API call.
L’Architettura Completa: Come Si Connettono
Editor (Directus Admin)
↓
Directus API (REST/GraphQL)
↓
Astro (build time fetch)
↓
HTML Statico + Islands JS
↓
Cloudflare Pages (CDN globale)
↓
Utente (latenza <50ms globale)
Il flusso di un aggiornamento contenuto è:
- L’editor modifica o pubblica un contenuto nel pannello Directus
- Un webhook Directus notifica Cloudflare Pages
- Cloudflare Pages avvia un nuovo build Astro
- Astro fetcha i contenuti aggiornati dall’API Directus
- Genera le pagine HTML statiche aggiornate
- Le distribuisce sul CDN globale Cloudflare
Il tempo tra la pubblicazione del contenuto e la disponibilità sul sito è tipicamente 2–4 minuti per un sito di media dimensione. Per siti con migliaia di pagine dove il rebuild completo sarebbe lento, si usa ISR (Incremental Static Regeneration) per rigenerare solo le pagine modificate.
Vantaggi Concreti per il Cliente
Sicurezza intrinseca: il sito pubblico è HTML statico su CDN — non c’è un server applicativo esposto, non ci sono query database live, nessuna superficie di attacco per SQL injection o exploit di plugin. Directus gira separatamente, accessibile solo dall’admin panel con autenticazione.
Performance garantite: HTML pre-renderizzato su CDN globale. Il TTFB è sotto i 100ms da qualsiasi posizione geografica. Non dipende da un server che “deve scalare”.
Autonomia degli editor: il pannello Directus è configurabile per essere intuitivo per utenti non tecnici. Gli editor pubblicano contenuti senza toccare codice, senza rompere layout, senza passare dal team tecnico per ogni modifica.
Costi infrastrutturali contenuti: Cloudflare Pages ha un piano gratuito generoso e un piano Pro a 20$/mese che copre la quasi totalità dei progetti PMI. Directus self-hosted su VPS costa 20–40€/mese. L’infrastruttura totale per un sito di media complessità: meno di 60€/mese.
Quando Questa Architettura Non è Quella Giusta
L’architettura Astro + Directus non è adatta quando:
- Il sito ha contenuti altamente personalizzati per utente in tempo reale (applicazioni web dinamiche, dashboard, social network)
- Il rebuild time è inaccettabile per la frequenza degli aggiornamenti (news in tempo reale con centinaia di aggiornamenti al giorno)
- Non c’è un processo di pubblicazione definito (se i contenuti cambiano ogni ora, conviene un approccio SSR o ISR più granulare)
Per questi casi, SvelteKit con Directus (in modalità SSR o API-first) è l’alternativa appropriata nello stesso ecosistema.
Conclusione
Astro + Directus non è la combinazione più diffusa nel mercato delle agenzie web italiane — e questo è esattamente uno dei motivi per cui la usiamo. Produce risultati tecnici superiori agli approcci tradizionali, con costi infrastrutturali contenuti e autonomia reale per il cliente nella gestione dei contenuti.
È una scelta che richiede competenze specifiche. Non è installare un tema WordPress. Ma per un cliente che vuole un asset digitale performante, sicuro e manutenibile nel tempo, il confronto con le alternative è impietoso.
→ Parla con Marfcode del tuo prossimo progetto web
Articolo correlato: SvelteKit vs Next.js: confronto tecnico per scegliere il framework giusto | Cloudflare come piattaforma di deploy