01
Risoluzione univoca
Drupal identifica senza ambiguità rotta, lingua, entità, tema e famiglia di pagine.
Migrazione incrementale con Strangler Fig Pattern: disaccoppiare Drupal senza fermare il business
Rifare da zero un portale Drupal richiede mesi prima di produrre valore e concentra tutto il rischio in una sola notte di rilascio. Con lo Strangler Fig Pattern un nuovo frontend Next.js affianca Drupal sullo stesso dominio e ne sostituisce il tema una sezione alla volta.
A cura del team bmeme
- Adriano CoriSoftware Engineer
Il metodo completo in un white paper di 21 pagine
Il white paper è gratuito e senza registrazione. Se decidi, ti bastano dieci minuti; se progetti, trovi le scelte architetturali, le otto verifiche e, solo nel PDF, un'autovalutazione in otto domande da compilare con il tuo team. Il PDF è per la lettura e la stampa; questa pagina è la versione web.
Cos'è lo Strangler Fig Pattern applicato a Drupal?
Lo Strangler Fig Pattern è una strategia di migrazione incrementale: un nuovo sistema sostituisce quello esistente una parte alla volta, mentre il vecchio continua a funzionare. Applicato a Drupal, significa affiancare al portale un frontend Next.js sotto lo stesso dominio, che ne sostituisce il tema una famiglia di pagine alla volta: per esempio tutte le schede prodotto, o tutte le notizie.
Il nome viene dal fico strangolatore, una pianta che cresce attorno a un albero fino a sostituirlo. Martin Fowler lo ha usato per descrivere questo tipo di migrazione.
Nel nostro caso Drupal non sparisce. Resta l'unica fonte dei contenuti e lo strumento quotidiano dei redattori: a essere sostituito, sezione dopo sezione, è il suo tema. Il risultato è un’architettura Drupal decoupled: sulle pagine migrate, quando cambia solo il frontend, il backend non si tocca.
Quando ha senso disaccoppiare un portale Drupal?
Quando il frontend è diventato il freno del tuo business. Se ti sei riconosciuto in almeno due punti, continua a leggere. Se in nessuno, probabilmente oggi non ti serve un disaccoppiamento. Va bene così.
Ogni novità richiede settimane
Una landing, un restyling o una nuova sezione toccano il tema Drupal, e i tempi si allungano.
I rilasci fanno paura
Una modifica in un punto rompe qualcosa altrove.
Il redesign è fermo
Resta nel cassetto perché "tanto andrebbe rifatto tutto".
Le prestazioni penalizzano
TTFB e LCP peggiorano l'esperienza, e migliorarli senza toccare il monolite sembra impossibile.
Il team vuole lavorare con React
Il tuo team frontend vorrebbe usare React, ma il tema Drupal non lo permette.
Nessuno conosce più il sito
È cresciuto negli anni con mani diverse, e nessuno sa con certezza cosa succede se si tocca qualcosa.
Perché riscrivere tutto da zero è la scommessa sbagliata?
Perché concentra tutto il rischio nel momento peggiore. Una riscrittura integrale richiede mesi prima di produrre valore: nel frattempo il business aspetta, i requisiti cambiano e il nuovo sistema insegue un bersaglio che si sposta.
Al go-live il rischio accumulato si scarica tutto insieme: dati, funzionalità, integrazioni, indicizzazione. Se qualcosa va storto, tornare indietro significa rinunciare a mesi di lavoro.
Con una migrazione incrementale il rischio non sparisce. Si divide in tanti piccoli rilasci, ciascuno reversibile per conto suo.
Drupal e Next.js convivono sotto lo stesso dominio. Chi naviga non si accorge del passaggio.
Cosa cambia durante la migrazione?
Durante la transizione una parte delle pagine arriva da Drupal, come oggi, e una parte da Next.js. Le sezioni passano al nuovo frontend una alla volta, quando sono pronte, e gli URL restano gli stessi.
In questa fase Drupal ha due ruoli: serve le pagine non ancora migrate e fornisce al nuovo frontend le pagine migrate, contenuti compresi.
Per i redattori
Nulla di nuovo da imparare: stesso pannello, stessi flussi di pubblicazione, stessi permessi. Le regole su cosa appare in una pagina restano in Drupal e valgono per le pagine vecchie e per quelle nuove.
Per il business
Parti da una sola sezione e decidi il resto quando hai visto i risultati: non serve approvare un progetto annuale. Puoi fermarti quando vuoi, e il sito continua a portarti traffico e contatti mentre lavoriamo.
Per i motori di ricerca
Stessi URL e canonical, sitemap sempre generata da Drupal, redirect senza catene. Garantiamo la parità tecnica tra pagine vecchie e nuove. Non promettiamo posizionamenti: ci assicuriamo di non rompere ciò che oggi funziona.
Come convivono Drupal e Next.js sullo stesso dominio
Si dividono le pagine senza che il visitatore se ne accorga. Ogni richiesta passa da un proxy Nginx esteso con Lua, che legge su un'istanza Redis dedicata la mappa delle rotte migrate e decide chi risponde. Se il sistema che smista il traffico ha un problema, tutto torna su Drupal.
Le quattro scelte progettuali
Drupal resta l'unica fonte di verità
Contenuti, tassonomie, regole di visibilità e configurazione dei layout stanno solo in Drupal. Il frontend non duplica dati e non ricostruisce regole: riceve pagine già risolte e le disegna.
Next.js lavora stateless
Il nuovo frontend genera le pagine lato server (SSR con App Router) e non gestisce sessioni dei visitatori. Il browser non parla mai direttamente con Drupal: ogni richiesta passa dal server Next.js, secondo il modello Backend For Frontend.
Il traffico si smista all'edge
La decisione su chi risponde non passa da Drupal, quindi non pesa sul Time To First Byte (TTFB). Se Redis non risponde, la richiesta va a Drupal: nel dubbio, il sito funziona come prima.
Stesso URL, due formati
Lo stesso indirizzo restituisce la stessa pagina: in HTML al browser, in JSON al frontend, in base all’header Accept. Page Delivery non aggiungerà API parallele con percorsi propri.
Per i team tecnici
La mappa in Redis è una proiezione ricostruibile da Drupal, non una fonte autorevole. Un errore di Next.js non ricade automaticamente su Drupal: chi serve una rotta è una decisione esplicita, non un effetto collaterale, e questo evita comportamenti incoerenti verso i crawler. La stessa pagina si chiede in due modi: il browser con Accept: text/html, il server Next.js con Accept: application/vnd.drupal.page-composition+json.
Come si decide quando una sezione passa a Next.js?
02
Struttura pronta
La variante di layout richiesta esiste nel nuovo frontend.
03
Componenti coperti
Ogni blocco che può comparire nella pagina ha il suo componente React validato.
04
Regioni compatibili
Le regioni prodotte da Drupal sono supportate dalla variante di destinazione.
05
Stesso accesso, stesso ordine
Visibilità, ordinamento e regole contestuali coincidono con la pagina attuale.
06
Variabili dichiarate
Parametri e varianti linguistiche che cambiano la pagina sono elencati esplicitamente.
07
Cache definita
Sono stabiliti i cache tag e le regole di aggiornamento della rotta.
08
Test superati
Test funzionali e visivi confrontano la pagina attuale con quella nuova su rotte campione.
Il contratto
Nessuna sezione cambia sistema per sbaglio: ogni passaggio è verificato, approvato da un responsabile tecnico e reversibile. Le verifiche si basano su un contratto. Drupal restituisce la pagina intera in un JSON diviso in cinque regioni (beforeMain, navigation, main, aside, afterMain): ogni regione elenca in ordine i componenti, con i loro contenuti. Il frontend riceve la pagina già risolta, senza markup HTML, e la disegna con componenti React conosciuti e validati. Se arriva un componente sconosciuto o un dato non conforme allo schema, la pagina non viene pubblicata a metà: l’errore è esplicito e visibile nei log.
Se manca una verifica, la sezione resta su Drupal. Non è un fallimento: è ciò che rende sicura la migrazione. E tornare indietro è una modifica di configurazione, senza un nuovo rilascio del codice.
Come restano aggiornati i contenuti e affidabili i rilasci?
I contenuti pubblicati compaiono subito e i rilasci non si allungano quando il sito cresce. Se un rilascio peggiora le prestazioni, si torna indietro in automatico.
Aggiornamenti guidati dagli eventi
Quando un redattore pubblica, Drupal invia a Next.js una notifica firmata 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 (stale-while-revalidate). Gli spostamenti di rotta seguono l'Outbox Pattern, così nessun cambio si perde a metà strada.
Se Drupal non risponde
Un circuit breaker smette di insistere su un backend in difficoltà. Per ogni funzionalità si decide in anticipo cosa mostrare: l'ultima versione in cache, una versione senza parti dinamiche o un messaggio esplicito di non disponibilità.
Build a tempo costante
La build di Next.js non chiama Drupal (Zero Build-Time Fetching): che il portale abbia mille pagine o centomila, la pipeline dura uguale. Ogni rilascio va su un ambiente gemello e, se TTFB, LCP o tasso di errore superano le soglie, il traffico torna automaticamente all'ambiente precedente.
Per i team tecnici
I cache tag si dichiarano prima della fetch, a partire da identificativi noti. L'header X-Drupal-Cache-Tags non è un'alternativa: è un header diagnostico e in produzione resta disattivato. Su pagine complesse elenca centinaia di tag, appesantisce ogni risposta e può superare i limiti di dimensione degli header di proxy e CDN. In ogni caso arriverebbe tardi: quando si legge la risposta, la fetch è già in cache senza tag.
Cosa non risolve lo Strangler Fig Pattern?
La coesistenza ha un costo
Per un periodo mantieni due stack, e servono competenze su Drupal e su React. Per questo la migrazione si pianifica a milestone, con una fine definita. Se ti fermi prima, le sezioni migrate restano su Next.js e le altre su Drupal.
Non tutto si migra subito
Le sezioni più complesse o stratificate restano su Drupal finché i loro componenti non sono mappati. È una scelta deliberata.
Il Blue/Green ha una finestra delicata
Se i redattori modificano contenuti mentre si prepara un rilascio, può crearsi un breve disallineamento. Si gestisce con una riconciliazione prima dello switch o con un blocco temporaneo delle scritture.
Le aree riservate sono un discorso a parte
Il frontend pubblico non gestisce login dei visitatori: le aree che richiedono autenticazione restano, almeno all'inizio, su Drupal.
Lo Strangler Fig riduce il rischio, ma non lo azzera. E il punto di partenza conta: logiche sparse nel tema, moduli custom fragili o versioni obsolete vanno sistemati prima. Per questo partiamo sempre da un assessment.
Sei ancora su Drupal 7?
Lo Strangler Fig presuppone un Drupal moderno che faccia da backend per il nuovo frontend. Drupal 7 è fuori supporto da gennaio 2025 e non può ospitare i moduli Page Delivery. Nel tuo caso serve una reingegnerizzazione, e l'assessment di aggiornamento serve a progettare la nuova piattaforma già pronta per il disaccoppiamento.
Cos'è Page Delivery?
Page Delivery è la suite di moduli Drupal con cui applichiamo il metodo. I moduli Page Delivery saranno rilasciati come open source su drupal.org il 22 ottobre, in occasione del DrupalCamp Italy 2026, con licenza GPL. Conviveranno con le API già presenti in Drupal, JSON:API e GraphQL comprese. Gli strumenti saranno gratuiti e pubblici. La parte su misura è l'adattatore di progetto, che traduce le sorgenti del tuo portale (view, blocchi, menu, archivi) nel contratto di Page Composition. Paghi il lavoro sull'adattatore.
I quattro moduli di Page Delivery
Page Delivery Layout
Definisce layout logici e mappa le regioni del tema Drupal sulle regioni del contratto.
Page Delivery Composition
Restituisce la pagina intera in JSON, contenuti compresi, sullo stesso URL della versione HTML, in base all’header Accept.
Page Delivery Route Ownership
Stabilisce quali path passano a Next.js, per match esatto o per prefisso, e pubblica la mappa di routing su Redis. Drupal resta il default.
Page Delivery Authentication
Protegge, se attivato, il JSON delle pagine. La chiamata parte dal server Next.js, che si autentica verso Drupal con uno dei provider di autenticazione già presenti. Così il JSON delle pagine è leggibile solo dal tuo frontend, non da chiunque.
Come si parte, e quanto tempo serve?
01
Call conoscitiva, gratuita, 45 minuti
Parliamo del tuo portale, di cosa ti blocca oggi e dei tuoi obiettivi. Esci con una prima idea di quanto il sito è pronto e di cosa va verificato.
02
Assessment, a pagamento, 2 settimane
È analisi e documentazione: non tocchiamo il codice. Ti consegniamo l'elenco dei bloccanti con le azioni per risolverli, una proposta di pilota calibrata sul tuo budget e un semaforo che dice se e come si può partire. Il documento resta tuo, anche se decidi di non proseguire con noi.
03
Pilota
Una famiglia di pagine passa in produzione su Next.js. La scegliamo con te in base al budget, e può essere anche un insieme di rotte più semplici. Vedi un risultato reale e decidi con i dati alla mano.
04
Estensione a milestone
Una famiglia di pagine alla volta, al ritmo del tuo business. Le prime milestone sono le più impegnative; dalle successive si riusa quello che c'è già, e il costo di ogni nuova sezione scende.
Il semaforo dell'assessment
Verde · Codice conforme
Architettura solida, database Drupal standard, nessun codice critico. Si parte con tempi e costi previsti.
Giallo · Debito tecnico
Alcune parti non standard vanno bonificate prima di partire. La bonifica si stima a parte.
Rosso · Incompatibilità
Sistema instabile o non aggiornabile, dati alterati da sistemi esterni o codice non documentato. Ci fermiamo e valutiamo un rifacimento.
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, la stima precisa con l'assessment.
Chi c'è dietro il metodo?
bmeme è una Digital Tech Boutique di dodici persone che progetta e sviluppa architetture Drupal e web, dall'analisi dei requisiti alla manutenzione. Siamo piccoli per scelta: siedi allo stesso tavolo di chi progetta l'architettura e scrive il codice, senza intermediari. Nel team ci sono persone che lavorano con Drupal dal 2009.
Dal 2022 rilasciamo in produzione portali decoupled ad alto traffico, con o senza Drupal, comprese migrazioni da Drupal monolitico a decoupled fatte senza bloccare il sito. Page Delivery nasce da lì: abbiamo generalizzato quello che avevamo costruito per casi specifici. Oggi stiamo applicando il metodo su un portale di oltre 50.000 pagine.
Il tuo portale non dipende da noi: i moduli saranno open source, il codice dell'adattatore è tuo e ogni milestone si chiude con la documentazione tecnica. Se hai un team interno, lo affianchiamo finché non è autonomo.
Domande frequenti sulla migrazione incrementale di Drupal
Quanto dura una migrazione incrementale di un portale Drupal?
La prima famiglia di pagine arriva in produzione in genere in 2–3 mesi. La durata complessiva dipende da quante sezioni vuoi migrare e dal ritmo del tuo business, perché la migrazione si pianifica a milestone, con una fine definita.
Quanto costa?
Non c'è un listino: l'ordine di grandezza te lo diamo nella call conoscitiva, la stima precisa con l'assessment. I moduli Page Delivery saranno gratuiti, quindi paghi solo il lavoro sul tuo portale. Il costo di ogni nuova sezione scende con il riuso.
I redattori devono cambiare strumento?
No. Continuano a usare Drupal con lo stesso pannello, gli stessi flussi di pubblicazione e gli stessi permessi, sia per le pagine già migrate sia per le altre.
La migrazione mette a rischio il posizionamento sui motori di ricerca?
Garantiamo la parità tecnica tra pagine vecchie e nuove: stessi URL, canonical, hreflang e dati strutturati, sitemap generata da Drupal, redirect senza catene. Non promettiamo posizionamenti, ma la parità su questi punti è una condizione per estendere la migrazione a nuove sezioni.
Si può applicare a un sito su Drupal 7?
No, non direttamente. Drupal 7 è fuori supporto da gennaio 2025 e non può ospitare i moduli Page Delivery: serve una reingegnerizzazione, che progettiamo già pronta per il disaccoppiamento.
Posso fermarmi a metà?
Sì. Le sezioni migrate continuano a funzionare su Next.js, le altre restano su Drupal, e ogni sezione può tornare su Drupal con una modifica di configurazione.
Il nostro team interno può proseguire da solo?
Sì. I moduli saranno open source, il codice dell'adattatore è di tua proprietà e ogni milestone si chiude con la documentazione tecnica. Servono competenze su Drupal e su React, e affianchiamo il tuo team finché non è autonomo.
Le aree riservate con login si possono migrare?
Almeno all'inizio restano su Drupal. Il frontend pubblico non gestisce l'autenticazione dei visitatori, e le aree riservate vanno valutate a parte.
Quando conviene usare Page Delivery e quando no?
Conviene se hai un Drupal moderno, con contenuti strutturati, e il freno è il tema; se vuoi un frontend Next.js con team e rilasci propri, senza migrare i dati; se i redattori devono continuare a comporre le pagine in Drupal. Non conviene se il modello dei contenuti va ripensato comunque, se deve essere il frontend a decidere come si compone una pagina, se sei su Drupal 7, se il tema non è un freno o se il sito è così piccolo che due sistemi costano più di quanto rendono. Un’app o altri canali da alimentare non sono un ostacolo: JSON:API e GraphQL restano disponibili.
Perché non JSON:API o GraphQL?
Perché le due strade rispondono a domande diverse. Con JSON:API e GraphQL il frontend chiede i dati che gli servono, entità e campi, e compone la pagina. Con Page Delivery il frontend chiederà la pagina: Drupal la compone, come fa per l’HTML, Next.js la interpreta e la disegna. Non devi scegliere: Page Delivery convivrà con JSON:API e GraphQL.
Per capire se il metodo vale per il tuo portale, parliamone: la call conoscitiva è gratuita e dura 45 minuti.
Presentiamo il metodo al DrupalCamp Italy 2026
Il 22 ottobre a Bologna, dalle 17:05 alle 17:45, Adriano Cori, Software Engineer di bmeme, presenta il talk «Evoluzione Enterprise senza "Big Bang": lo Strangler Fig Pattern con Drupal». Nella stessa occasione rilasceremo i moduli Page Delivery come open source.