Drupal: first-class citizen nel mondo PHP.

Drupal è più vivo che mai, con una community sempre più ampia e un numero di realizzazioni in aumento costante.

Il 21 settembre 2021, grazie alla collaborazione con GrUSP abbiamo dedicato una mezza intensa giornata all’evoluzione di Drupal in questi ultimi due anni, un’evoluzione che lo ha portato ad avere un’anima da framework, tanto da poter essere utilizzato nativamente headless, abbinato a qualunque altro framework JS per un frontend disaccoppiato, e a costituire la solida base di una delle più flessibili DXP (Digital Experience Platform) disponibili sul mercato.

L’evento ha avuto un grande successo, all’interno della sua nicchia, ed è riuscito a raccogliere l’attivissima e vivace community Drupal italiana, digiuna di incontri da troppo tempo (si sente la mancanza di un Drupal Day ben fatto e in-person).

SparkFabrik ha portato due talk:

• Cloud-Native Drupal: A survival guide, di Noemi Mancini
• Headless Drupal: A modern approach to (micro)services and APIs, di Matteo Stendardi Turini 

Già dal titolo di entrambi risulta evidente quanta strada abbia fatto Drupal verso le più moderne soluzioni di sviluppo e architetturali developer-friendly, diventando una possibile base su cui costruire applicazioni cloud-native e offrendo a chi sviluppa un ambiente di lavoro moderno per modellare dati ed esporli via API nativamente. Vediamo più in dettaglio?

Cloud-Native Drupal: A survival guide

Perché vogliamo trasformare Drupal in un’applicazione Cloud-Native e come possiamo farlo?

Per rispondere dobbiamo risalire la corrente e andare a capire a monte perché il Cloud e quali sono le sue promesse. Le infrastrutture Cloud oggi ci permettono di superare una serie di problematiche vive fino a poco tempo fa (siti che crollavano per picchi di traffico, tempi da definire per il fermo macchine da dedicare a nuovi deployment, disallineamenti tra le versioni di software in ambiente di sviluppo e produzione, per nominare alcuni tra i tanti esempi che ogni developer ha vissuto nella propria vita).

Le promesse che ci fanno il Cloud e l’approccio cloud-native sono di vario tipo:

• la possibilità di razionalizzare le nostre risorse;
• l’ottimizzazione dei costi perché vengono utilizzate le risorse che servono quando servono (picchi e flessi di traffico saranno più facilmente gestibili grazie al fatto che le risorse sono scalabili) ;
• migliori performance generali;
• possibilità di continuous delivery & deployment (senza più dover mettere il sito in manutenzione per ore)
• semplificazione dell’onboarding di nuovi membri del teame apertura facilitata a chi si occupa di sviluppo esternamente  Questo permetterà di non perdere più giornate a configurare l’ambiente locale qualora ci fossero nuovi ingressi nel team di sviluppo

Dopo aver brevemente identificato i benefici della trasformazione, il talk affronta con estrema concretezza i vari passaggi operativi rispondendo puntualmente alla domanda di partenza: come costruire un’immagine Docker che servirà a dar vita ai container, come gestire le dipendenze, lo storage, la persistenza dei dati, la creazione delle pipeline, la gestione del possibile multicloud. 

Grande attenzione viene data al monitoraggio. Sappiamo bene che per chi si occupa di sviluppo  il lavoro non finisce quando un sito o un prodotto digitale più in generale vanno online: il monitoring è importante, i dati da raccogliere sono numerosissimi. Oltre i log, si deve tenere sotto controllo l’utilizzo delle risorse, perché è attivo l’autoscaling, ma è necessario anche capire quanto scalino effettivamente, e dobbiamo raccogliere lo status report di Drupal, senza entrare nell’istanza di Drupal. A fronte di una tale pletora di dati, si avrà bisogno di strumenti per gestirli, organizzarli e filtrarli. Ogni vendor ne mette a disposizione alcuni, senza contare servizi esterni che possono essere configurati previa identificazione delle metriche giuste: senza le idee chiare in questo senso, si rischia di essere sommersi di log e dati inutilmente. 

Particolarmente interessanti sono, poi,  le considerazioni finali: quanto Drupal risulta “collaborativo”? Da Drupal 8 in poi, portarsi in Cloud in ottica Cloud Native è piuttosto facile. La configurazione è esportabile su file, quindi può essere versionata e far parte della build, e D8 utilizza Composer per gestire le dipendenze (non conviene utilizzare Drupal senza Composer, questo il nostro accorato consiglio). Ad oggi Drupal rispetta la maggior parte degli standard PHP e può essere considerato a tutti gli effetti un framework moderno, basato in gran parte su componenti di Symfony.  Ciò detto, che non ci si disperi davanti a un sito Drupal 7. Richiederà sicuramente uno sforzo maggiore, perché sarà necessario sopperire a tutte quelle funzionalità che soltanto dall’8 abbiamo a disposizione, ma rimane comunque una strada percorribile. Non dobbiamo rinunciare per forza a un D7 cloud-native, soltanto mettere in conto un effort maggiore.

Headless Drupal: A modern approach to (micro)services and APIs

Quali sono gli strumenti e i pattern che Drupal mette a disposizione per sviluppare un CMS headless?

Prima un ripassino: Drupal è un software free e open-source scritto in PHP, nato agli inizi degli anni 2000 come progetto universitario dello studente belga Dries Buytaert. Nel corso del tempo si è evoluto da CMS fino a diventare un vero e proprio framework; infatti, oggi si parla frequentemente di Drupal come CMF – Content Management Framework – più che come CMS.

Premesso questo, Drupal mette a disposizione diverse possibilità per diventare base di dati per un CMS headless. Il talk ne ha trattato una in particolare, più completa e supportata rispetto alle altre, e che soprattutto permette di raggiungere lo scopo senza aggiungere codice custom, ma solo tramite l’utilizzo di moduli core o contrib appositamente configurati. Questo approccio ruota intorno al modulo core JSON:API. 

Facendo un passo indietro, nel 2016 è stato dato il via a quella che ha preso il nome di API-first initiative. In pratica, l’obiettivo era quello di rendere Drupal un framework che potesse essere utilizzato con sicurezza anche come CMS headless. Nel corso dei mesi – e poi degli anni – questa iniziativa si è spostata sempre più nettamente verso l’integrazione di JSON:API all’interno del core, finalizzata a marzo del 2019 con la versione 8.7 di Drupal.

JSON:API è una specifica che definisce uno standard per l’esposizione e la gestione di dati in formato JSON tramite HTTP. La sua prima stesura risale al maggio 2013, e oggi è alla versione 1.0.

Ha un proprio MIME media type registrato, ed è progettato per minimizzare le richieste fra client e server. La specifica è stata definita indipendentemente da Drupal che, in questo senso, si limita ad implementarla nel proprio modulo core. Va comunque sottolineato che uno dei responsabili della API-first initiative per Drupal, Gabe Sullice, è anche diventato manutentore della specifica stessa.
Il modulo Drupal JSON:API si trova nel core (anche se non è attivo di default), e permette di esporre i nostri dati in formato JSON:API su endpoint appositi. I moduli successivi sono moduli contrib, ed estendono le funzionalità del modulo core in modo da rispondere a specifiche necessità di sviluppo. Tutti questi moduli sono supportati da Acquia, l’organizzazione dietro a Drupal, o da altre aziende importanti e attive nel settore, come ad esempio Lullabot o Centarro.

Chiaramente questo non è l’unico modulo o ecosistema disponibile per ottenere il nostro scopo. 

Nel core di Drupal abbiamo un altro modulo, RESTful Web Services, che per un po’ di tempo è stato il diretto concorrente di JSON:API per diventare lo standard de facto per questa casistica d’uso. Alla fine si è affermato JSON:API, principalmente per la semplicità con cui riesce a coprire la maggior parte degli use case – JSON:API permette di esporre tutte le entità presenti sul sito senza praticamente effort aggiuntivo. Rispetto a quest’ultimo, RESTful Web Services richiede una configurazione custom più complessa, le opzioni per il filtering dei dati sono più limitate e complicate da configurare, le richieste per le risorse sono meno strutturate rispetto a quelle di JSON:API, e le collection possono essere esposte solo previa configurazione di apposite viste. Insomma, un buon modulo, ma che rimane indietro su alcuni rispetto alla semplicità e flessibilità di JSON:API. D’altro canto, per specifici casi d’uso, come ad esempio operazioni con logiche custom o che non siano legate strettamente alle entità, RESTful Web Services offre un framework sicuramente più flessibile da poter sfruttare, al costo appunto di una maggiore complessità generale.

Non hai avuto modo di partecipare a Drupal @ localhost?

Rivivi l’intero evento qui.

Il 23 Novembre vi aspettiamo per un’ altra intensa mattinata, questa volta dedicata a reactnative con un altro evento gratuito organizzato da GrUSP e sponsorizzato da SparkFabrik.

Articolo scritto da