Un'architettura decoupled separa i contenuti dal frontend, cioè dalla parte del portale che i visitatori vedono: i contenuti restano su Drupal o su un altro CMS mentre un frontend Next.js disegna le pagine. Conviene quando il frontend frena il tuo portale. Puoi partire da un progetto nuovo oppure da un portale Drupal monolitico già in produzione, che passa al decoupled per gradi senza fermare il sito. Quando il decoupled non serve, te lo diciamo prima di cominciare.
Con un'architettura decoupled il frontend si può rifare o migliorare senza toccare i contenuti e il lavoro della redazione. Un'evolutiva che riguarda solo il frontend si rilascia senza toccare il backend, cioè la parte che gestisce contenuti e regole. Il portale non va rifatto ogni pochi anni: cresce sulla stessa base.
Il caso Flexform, più in basso, ne è un esempio: il portale è online da fine novembre 2023 ed evolve ogni anno.
In un monolite la gestione dei contenuti, la logica e la presentazione vivono nella stessa applicazione. Con Drupal vuol dire contenuti e tema nello stesso codice. Non è un difetto in sé: molti portali funzionano bene così. Il portale del Corpo Nazionale dei Vigili del Fuoco, che abbiamo ricostruito ed è online dal 2024, è un Drupal monolitico.
Decoupled vuol dire backend e frontend separati, che comunicano tramite un contratto: regole precise su quali dati passano dall'uno all'altro e in che forma. Nella versione progressiva Drupal continua a generare le pagine e un framework JavaScript gestisce solo alcune parti.
Un frontend separato, per noi Next.js, disegna tutte le pagine di sua competenza. I contenuti si creano e si gestiscono nel CMS, Drupal o un altro, dove continua a lavorare la redazione.
È un CMS che non produce pagine: espone i contenuti solo tramite API, cioè interfacce che il frontend interroga, a uno o più frontend. Decoupled e headless non sono sinonimi: Drupal per natura produce pagine, ma può essere usato in modo decoupled.
Una landing, un restyling o una nuova sezione toccano il tema del sito, così anche un cambiamento piccolo diventa un progetto.
Una modifica in un punto del portale rompe qualcosa altrove.
Si rimanda da tempo, perché tanto andrebbe rifatto tutto.
TTFB e LCP, cioè il tempo di risposta del server e quello con cui compare il contenuto principale, penalizzano l'esperienza. Migliorarli senza cambiare l'architettura sembra impossibile.
Il tuo team vorrebbe lavorare con React, ma il tema del CMS non lo permette.
Negli anni ci hanno lavorato persone diverse e nessuno sa più con certezza cosa succede se si tocca qualcosa.
Quando il portale è da costruire, la scelta del CMS viene dal progetto. Drupal resta il nostro centro tecnico ma non è l'unica strada: per Vivo Concerti abbiamo scelto Strapi, un CMS più leggero e più adatto al lavoro della loro redazione, con un frontend Next.js. Le altre piattaforme le valutiamo caso per caso, in base alle tecnologie e alle competenze che abbiamo. Se una piattaforma è fuori dalle nostre competenze, te lo diciamo subito.
Si parte da una call e da più scope plan, ciascuno con il perimetro di un obiettivo, cioè cosa serve agli utenti e al business, cosa c'è e cosa no. Insieme danno una prima proiezione, poco vincolante perché nasce prima dell'analisi tecnica, da cui arriva la proposta. Dopo l'avvio scriviamo la roadmap esecutiva, che è più precisa degli scope plan. È dettagliata sulle milestone vicine e lo è meno su quelle lontane, che si definiscono man mano alla luce di ciò che accade nel progetto. Si procede per milestone, di solito mensili.
Lo stesso percorso vale se il portale è su Drupal 7, fuori supporto dal 5 gennaio 2025. Non può fare da backend per un nuovo frontend, quindi va riprogettato. Il nuovo portale nasce già pronto per essere disaccoppiato.
Se il tuo portale è un Drupal monolitico in produzione, per disaccoppiarlo non serve rifarlo da zero. Una riscrittura integrale ferma il business per mesi e concentra tutto il rischio in una sola notte di rilascio. Usiamo invece lo Strangler Fig Pattern, una strategia di sostituzione incrementale in cui il nuovo sistema affianca il vecchio e ne prende in carico le funzioni una alla volta.
Qui un frontend Next.js affianca Drupal sullo stesso dominio e prende in carico il portale una famiglia di pagine alla volta, cioè un gruppo di pagine dello stesso tipo, con gli stessi URL. La chiamiamo migrazione incrementale, ma a passare a Next.js sono le pagine, non i dati: i contenuti restano in Drupal.
Ogni famiglia passa solo dopo otto verifiche approvate da una persona. Se serve, si riporta su Drupal con una modifica di configurazione, senza un nuovo rilascio del codice. Stiamo applicando il metodo a un portale da oltre 50.000 pagine.
Page Delivery è la suite di moduli Drupal, sviluppata da bmeme, su cui si appoggia la migrazione incrementale. Drupal eroga in JSON la pagina intera, contenuti compresi, che Next.js interpreta e disegna. JSON:API e GraphQL servono invece a chiedere i dati e convivono con Page Delivery.
I moduli saranno rilasciati come open source su drupal.org il 22 ottobre, in occasione del DrupalCamp Italy 2026, a Bologna, dove Adriano Cori, che ne è il maintainer, presenterà il metodo in un talk.
Layout, Composition, Route Ownership e Authentication. Insieme fanno sì che lo stesso indirizzo restituisca l'HTML al browser e la pagina intera in JSON, contenuti compresi, al nuovo frontend. È Drupal a decidere quali percorsi passano a Next.js.
Ogni portale ha sorgenti proprie, come view, blocchi, menu e archivi. Un adattatore di progetto le traduce nel formato dei moduli. È il lavoro su misura: paghi quello, non una licenza.
I moduli saranno open source e ogni milestone si chiude con la documentazione tecnica. Il codice dell'adattatore resta di tua proprietà e, se hai un team interno, lo affianchiamo finché non può proseguire da solo.
Il passaggio conviene se hai un Drupal moderno con contenuti strutturati in cui il freno è il tema. Conviene anche se vuoi un frontend Next.js con team e rilasci propri senza migrare i dati, oppure se i redattori devono continuare a comporre le pagine in Drupal. Un'app o altri canali da alimentare non sono un ostacolo, perché JSON:API e GraphQL convivono con Page Delivery.
Non conviene se il modello dei contenuti va comunque ripensato o se deve essere il frontend a decidere come si compone una pagina. Non conviene nemmeno se il tema non è un freno, oppure se il sito è così piccolo che mantenere due sistemi costa più di quanto rende. Se il portale è su Drupal 7 serve prima una reingegnerizzazione, come per un progetto nuovo.
A volte il passaggio è possibile, ma non subito. Se la logica delle pagine è sparsa nel tema, o ci sono moduli su misura fragili e versioni obsolete, si sistemano prima. Per questo partiamo da un assessment, cioè l'analisi completa del portale prima di intervenire.
Le aree riservate dopo un login restano su Drupal almeno all'inizio, perché il frontend pubblico non gestisce l'accesso dei visitatori. Mantenere per un periodo Drupal e il nuovo frontend ha un costo, perché servono competenze su entrambi. Per questo si lavora a milestone, con una fine definita.
I redattori continuano a usare Drupal come oggi, con lo stesso pannello, gli stessi flussi di pubblicazione e gli stessi permessi. Le regole su cosa appare in una pagina restano configurate in Drupal.
Gli URL, i canonical e gli hreflang restano gli stessi, i redirect sono 301 o 308 senza catene e la sitemap la genera sempre Drupal. La parità tecnica tra pagine vecchie e nuove è una condizione per far passare altre sezioni. Non promettiamo posizionamenti: ci assicuriamo di non rompere ciò che oggi funziona.
Durante il passaggio e i rilasci preserviamo i tracciamenti già attivi. Nel frontend implementiamo i requisiti che ci indica chi cura il tuo marketing.
Quarantacinque minuti, gratuiti, con chi progetta e non con un commerciale. Parliamo del tuo portale, di cosa ti blocca oggi e dei tuoi obiettivi. Esci con una prima idea di quanto il portale è pronto e di cosa va verificato. Ti diamo anche l'ordine di grandezza dell'investimento.
Due settimane di analisi e documentazione, a pagamento, senza toccare il codice. Ti consegniamo l'elenco dei bloccanti con le azioni per risolverli, una proposta di pilota calibrata sul tuo budget e un semaforo verde, giallo o rosso che dice se e come si può partire. Il documento resta tuo anche se poi non prosegui con noi.
Una famiglia di pagine passa in produzione su Next.js, scelta con te in base al budget: può essere anche un insieme di pagine più semplici. La prima famiglia arriva in produzione in genere in 2–3 mesi, così vedi un risultato reale prima di decidere il resto.
Una famiglia di pagine alla volta, al ritmo del tuo business. Le prime milestone sono le più impegnative, perché si costruiscono la pipeline di rilascio, i componenti, l'adattatore e le procedure. Dalle successive si riusa ciò che c'è già e il costo di ogni nuova sezione scende.
Un nuovo frontend, che nasca con un progetto nuovo o dal passaggio di un monolite, ha bisogno di un sistema di componenti. Il passo successivo può essere un Design System, cioè i componenti dell'interfaccia raccolti in un unico sistema che vive nel codice. Su questa base si ripensa l'esperienza, si costruiscono altre applicazioni coerenti con il portale e le interfacce evolvono senza accumulare differenze tra design e codice.
Drupal, Next.js, Decoupled, Continuous Integration
Nel 2022 il digitale stava diventando centrale per Flexform, e al portale servivano nuovi strumenti. La scelta: contenuti su Drupal e frontend ricostruito in Next.js. Dal 2023 il portale cresce ogni anno con nuove funzioni per utenti e rivenditori.
Strapi, Next.js, Decoupled, Continuous Integration, UX e UI
Siamo specialisti Drupal, e per Vivo Concerti abbiamo consigliato di non usarlo: alla loro redazione serviva un CMS più leggero e adatto al suo lavoro. Strapi gestisce i contenuti, mentre Next.js, separato, disegna le pagine e regge il traffico elevato.
No. Decoupled vuol dire che backend e frontend sono separati e comunicano tramite un contratto. Un CMS headless non produce pagine: espone i contenuti solo tramite API. Drupal le produce per natura e noi lo usiamo in modo decoupled con un frontend Next.js che disegna le pagine, mentre Drupal resta la fonte dei contenuti.
Il vantaggio principale è poter cambiare il frontend senza toccare contenuti e redazione. Se porti al decoupled un Drupal monolitico, il costo è la coesistenza: per un periodo si mantengono insieme Drupal e il nuovo frontend.
Se il portale è un Drupal monolitico, non serve rifare tutto. Con lo Strangler Fig Pattern un nuovo frontend Next.js affianca Drupal sullo stesso dominio e prende in carico una famiglia di pagine alla volta, con gli stessi URL. Puoi fermarti quando vuoi: le sezioni migrate funzionano, le altre restano su Drupal.
Quando un Drupal monolitico passa al decoupled, gli URL, i canonical, gli hreflang e la sitemap restano gli stessi. I redirect sono 301 o 308 senza catene e preserviamo i tracciamenti già attivi. Se la parità su questi punti manca, la sezione resta su Drupal. Non promettiamo posizionamenti.
Dipende dal punto di partenza. Se porti al decoupled un Drupal monolitico, la prima famiglia di pagine arriva in produzione in genere in 2–3 mesi. L'ordine di grandezza dell'investimento te lo diamo già nella call conoscitiva, gratuita e di 45 minuti, mentre la stima precisa arriva con l'assessment, che dura due settimane ed è a pagamento. Non devi approvare un progetto annuale per iniziare: parti da una sola sezione e decidi il resto dopo averne visto i risultati. In un progetto nuovo gli scope plan danno una prima proiezione, che dopo l'avvio diventa più precisa con la roadmap esecutiva.
Quando un redattore pubblica, Drupal invia al frontend una notifica firmata con HMAC che segna come obsoleti solo i dati interessati. Il visitatore successivo riceve subito la versione in cache, mentre quella aggiornata si rigenera in background. Le pagine si generano al primo accesso e poi restano in cache, quindi la durata della build non cresce con il numero di pagine. Se Drupal non risponde, per ogni funzione si decide in anticipo cosa mostrare: l'ultima versione in cache, una versione senza parti dinamiche o un messaggio di non disponibilità.
No. JSON:API e GraphQL servono al frontend per chiedere i dati, entità e campi, con cui poi compone la pagina. Con Page Delivery il frontend chiede invece la pagina intera, che Drupal compone come fa per l'HTML e Next.js interpreta e disegna. Le due strade convivono, quindi un'app o altri canali da alimentare possono continuare a usare JSON:API o GraphQL.
Parliamo di cosa frena il tuo portale, con chi lo progetterà