Qualche settimana fa ho passato un pomeriggio a guardare un merchant fashion (catalogo medio, poco sotto i 15M di GMV) discutere se rifare il proprio storefront su Magento in modalità headless. La domanda che giravano era sempre la stessa: “ma ha davvero senso adesso, o stiamo correndo troppo?”. Ci ho pensato su, e la mia risposta è che il 2020 sia il primo anno in cui questa domanda merita una risposta seria, e non un rinvio.
Provo a spiegare perché, senza vendervi nulla. Chi mi conosce sa che sul headless sono stato a lungo prudente: per anni su Magento è stata più una parola d’ordine da conferenza che una cosa messa in produzione con criterio. Qualcosa però è cambiato, ed è cambiato nella piattaforma.
Cosa ha davvero abilitato GraphQL su Magento 2
Il punto di svolta si chiama GraphQL, arrivato con Magento 2.3. Fino a quel momento, se volevate parlare con Magento da un frontend esterno avevate a disposizione le API REST e SOAP: funzionali, ma pensate per l’integrazione backend, non per costruire un’interfaccia utente veloce. Il problema classico era il tipico giro di chiamate per comporre una singola pagina prodotto: troppe request, troppi dati che non usavate (over-fetching) o troppo pochi (under-fetching).
GraphQL ribalta la logica. C’è un solo endpoint, ed è il client a dichiarare esattamente quali campi vuole. Volete nome, prezzo e le prime tre immagini di un prodotto? Chiedete quelli, e ricevete esattamente quelli, in una sola query. Per chi costruisce uno storefront questo cambia la vita: meno round-trip, payload prevedibili, contratto dati esplicito.
Va detto con onestà: la copertura non è ancora completa. GraphQL è nato coprendo il catalogo, e nelle release successive della linea 2.3 si è esteso a carrello, checkout e area cliente. Restano zone in cui vi tocca ancora appoggiarvi a REST o scrivere resolver custom. È un cantiere aperto, non un lavoro finito. Ma la parte che serve per il 90% di un percorso d’acquisto oggi c’è, ed è questa la differenza rispetto a dodici mesi fa.
PWA Studio: gli strumenti ufficiali, non più solo esperimenti
L’altra metà della storia è PWA Studio, il set di strumenti che Magento ha rilasciato insieme alla 2.3 per costruire Progressive Web App sopra la piattaforma. Qui il messaggio, per me, è più politico che tecnico: significa che la direzione ufficiale — e con Adobe alle spalle il peso non è poco — è un frontend disaccoppiato, scritto in JavaScript e React, che dialoga col backend via GraphQL.
PWA Studio è fatto di alcuni pezzi che vale la pena conoscere per nome:
- Venia, lo storefront di riferimento: non un tema da mettere in produzione così com’è, ma un punto di partenza in React da cui derivare il vostro.
- Peregrine, la libreria di componenti logici (in pratica gli hook che tengono lo stato e parlano con GraphQL).
- Venia UI, i componenti visuali.
- Buildpack e UPWARD, che si occupano di build e del layer server che serve la PWA (utile, tra l’altro, per non buttare via la SEO con un’app tutta client-side).
Attorno a questo, poi, c’è un ecosistema di alternative non ufficiali che stanno maturando in parallelo — Vue Storefront, ScandiPWA, DEITY — segno che il tema headless su Magento non è più roba di nicchia. Personalmente trovo sano che ci sia concorrenza: nessuna di queste soluzioni è ancora “quella definitiva”, e va bene così.
Cosa vuol dire, in concreto, uno storefront disaccoppiato
Provo a togliere l’astrazione. In un Magento tradizionale, il frontend e il backend sono la stessa cosa: il tema vive dentro Magento, le pagine si compongono con layout XML e template PHTML, e il server sputa fuori l’HTML già pronto. Comodo, integrato, ma anche rigido: ogni scelta di frontend passa dalle regole di Magento.
Nel modello headless tagliate quel legame. Magento resta il cervello — catalogo, prezzi, ordini, promozioni, integrazioni ERP — ma l’interfaccia diventa un’applicazione a sé, che gira per conto suo e chiede i dati via GraphQL. Il vantaggio che vedo più concreto è triplice: performance (una PWA ben fatta, con app-shell e caching, è di un’altra categoria sul mobile), libertà del team frontend (React, l’intero ecosistema npm, tooling moderno, deploy indipendenti) e riuso (lo stesso strato dati serve web, app, chioschi, un domani altri touchpoint).
Quando ha senso per un merchant — e quando no
Qui arriva la parte in cui rischio di rovinare la festa, ma preferisco essere netto: headless nel 2020 non è per tutti. È lo strumento giusto se vi ritrovate in questo profilo:
- La performance mobile e una UX su misura sono un vantaggio competitivo reale, non un vezzo.
- Avete in casa (o in agenzia) competenze JavaScript/React vere, non improvvisate.
- Il budget regge un progetto frontend che, di fatto, è un prodotto software a parte da mantenere nel tempo.
- Guardate a più touchpoint, non solo al sito.
Ed è la scelta sbagliata, oggi, se siete nell’altro profilo: catalogo semplice, budget limitato, e soprattutto una forte dipendenza dal tema nativo e dalle extension di terze parti. Questo è il punto che quasi nessuno vi dice apertamente: una fetta enorme dell’ecosistema di extension Magento inietta funzionalità via layout XML e PHTML, cioè lato server. In un frontend headless quel meccanismo semplicemente non esiste più. Quelle extension non “smettono di funzionare” — vanno riscritte o reimplementate nel nuovo frontend. Chi parte per headless sottovalutando questa voce di costo, prima o poi ci sbatte contro.
Il merchant fashion di cui parlavo all’inizio, alla fine, aveva il profilo giusto: traffico in larga parte mobile, un frontend team interno e la voglia di differenziarsi sull’esperienza. Per loro ha senso. Per il vicino di stand alla stessa fiera, con dieci extension server-side su cui gira mezzo business, la risposta onesta sarebbe stata “non ancora”.
Perché proprio il 2020
Metto insieme i pezzi. GraphQL ha raggiunto una copertura utilizzabile sul percorso d’acquisto. PWA Studio è uscito dalla fase puramente sperimentale e ha uno storefront di riferimento su cui lavorare. L’ecosistema alternativo cresce e tiene alta l’asticella. E la direzione della piattaforma, sotto Adobe, punta esplicitamente da questa parte. Nessuno di questi elementi, preso da solo, basterebbe. Tutti insieme, secondo me, fanno del 2020 il primo anno in cui headless su Magento è una decisione di business ragionevole e non una scommessa da early adopter. Il che non vuol dire che sia la scelta giusta per voi: vuol dire solo che finalmente è una scelta vera.
Mini-FAQ
GraphQL sostituisce le API REST di Magento?
No. Le affianca. GraphQL è pensato per costruire storefront e interfacce; REST e SOAP restano validi, soprattutto per le integrazioni backend. In un progetto headless è normale usarli insieme, coprendo con REST o resolver custom le aree che GraphQL non tocca ancora.
Serve per forza PWA Studio per andare headless su Magento?
No. PWA Studio è l’opzione ufficiale e il percorso che consiglio a chi vuole restare allineato alla direzione della piattaforma, ma esistono alternative come Vue Storefront, ScandiPWA e DEITY. La costante è GraphQL come strato dati.
Con headless perdo le mie extension Magento?
Quelle che agiscono sul frontend via layout XML e PHTML sì: vanno reimplementate nel nuovo storefront. Quelle che lavorano lato backend (logiche di prezzo, integrazioni, gestione ordini) continuano a fare il loro mestiere. Vanno mappate una per una prima di decidere.
Headless migliora la SEO o la peggiora?
Dipende da come lo fate. Una PWA tutta client-side può creare problemi di indicizzazione; per questo PWA Studio prevede un layer server (UPWARD) che serve contenuto già renderizzato. La SEO va progettata dall’inizio, non recuperata alla fine.
Sull’autore. Mi occupo di e-commerce su Magento e Adobe Commerce dal 2011, quando ho iniziato a lavorare su Magento 1. Sono tra i primi in Italia ad aver ottenuto la certificazione Adobe Commerce e tra i primi ad aver portato in produzione progetti su Adobe Commerce Cloud. Su questo blog racconto quello che vedo dal campo — cosa funziona davvero per chi vende online e cosa no — con casi reali sempre anonimizzati.