Da un paio d’anni, ogni volta che discuto di roadmap con un merchant su Adobe Commerce, prima o poi arriva la domanda: “Dobbiamo andare headless?”. La parola gira nei webinar, nelle slide dei vendor, nelle chat dei developer. E gira spesso con più entusiasmo di quanto la sostanza tecnica, a metà 2021, giustifichi.
Ho lavorato su Magento dal 2011 e ho seguito da vicino la transizione verso Adobe Commerce. Ho messo le mani su PWA Studio, ho valutato Vue Storefront in almeno due progetti reali, ho visto ScandiPWA girare in produzione. Quello che segue non è una panoramica neutra: è la mia lettura, con le riserve del caso, su dove sta davvero il headless su Adobe Commerce oggi e su quando ha senso per il mid-market.
Cosa intendiamo con “headless” su Adobe Commerce
Sgombriamo il campo. Headless, in questo contesto, significa una cosa precisa: il frontend (il head) è disaccoppiato dal monolite PHP di Magento e comunica con il backend attraverso API, quasi sempre GraphQL. Il backend continua a fare quello che sa fare (catalogo, carrello, ordini, promozioni), ma non renderizza più le pagine. Le renderizza un’applicazione JavaScript separata, tipicamente una PWA.
La ragione per cui questo è possibile oggi ha un nome: l’API GraphQL introdotta con Magento 2.3 e maturata lungo la linea 2.4. È la fondazione su cui poggiano tutte le opzioni di cui parlo qui. Ed è anche il primo punto onesto da fare: la copertura GraphQL a metà 2021 è buona sul percorso principale ma incompleta. Catalogo, ricerca, carrello, checkout base funzionano. Ma appena tocchi funzionalità di secondo livello — certi scenari B2B, alcune estensioni di terze parti, feature specifiche di Adobe Commerce — trovi buchi che devi colmare a mano scrivendo resolver custom. Nessun vendor te lo dice nella demo.
PWA Studio e Venia: la via ufficiale Adobe
PWA Studio è la risposta ufficiale di Adobe. È un set di strumenti React basati su un layer chiamato Peregrine, con una storefront di riferimento, Venia, che serve da punto di partenza e da vetrina delle best practice.
Il vantaggio è evidente: è mantenuto da Adobe, segue il ciclo di rilascio del prodotto, e in teoria è la scelta più a prova di futuro. Se punti a restare dentro l’ecosistema ufficiale, è qui che guardi.
La realtà del campo, però, è più ruvida. Venia è una reference, non un tema pronto per la produzione: aspettati di riscrivere molto per arrivare a qualcosa che assomigli al tuo brand. La community di estensioni terze compatibili con PWA Studio è ancora sottile rispetto al parco moduli del frontend tradizionale Luma. E React qui non è opzionale: se il tuo team non lo conosce, stai comprando un problema di competenze insieme alla piattaforma. La mia impressione, dopo averci lavorato, è che PWA Studio a metà 2021 sia promettente ma ancora giovane per un mid-market senza un team frontend solido.
Vue Storefront: il concorrente platform-agnostic
Vue Storefront nasce fuori dal recinto Adobe, come progetto open-source basato su Vue.js e pensato per essere agnostico rispetto al backend. Ha guadagnato attenzione perché offre un’esperienza di frontend molto curata e performance di caricamento notevoli, e perché non ti lega a React.
Va detto con chiarezza che il progetto sta attraversando una transizione importante: la seconda generazione riscrive l’architettura attorno a un layer di integrazione che parla con Adobe Commerce via GraphQL. È un lavoro serio, ma è anche materia in movimento: chi adotta ora adotta qualcosa che sta ancora stabilizzandosi. In due valutazioni che ho seguito, il fascino della demo si è scontrato con la domanda scomoda — chi mantiene il connector nel tempo, e cosa succede quando Adobe rilascia una versione che cambia lo schema GraphQL?
La mia posizione: Vue Storefront è tecnicamente valido e il team frontend spesso lo preferisce, ma introduce un livello di integrazione in più da manutenere, e quel livello non è gratis.
ScandiPWA: il compromesso pragmatico
ScandiPWA, sviluppato da Scandiweb, prende una strada diversa e a mio avviso sottovalutata. È una PWA React che gira dentro Magento, distribuita come tema. Usa GraphQL come gli altri, ma resta molto più vicina al monolite: niente infrastruttura Node separata da gestire, deploy più simile a quello a cui i team Magento sono abituati.
Per un merchant che vuole i benefici di una PWA — velocità percepita, esperienza app-like — senza aprire il cantiere di una seconda infrastruttura, ScandiPWA è spesso il compromesso più ragionevole. Paghi con meno flessibilità architetturale e con una dipendenza forte da un singolo vendor per il progetto open-source. Ma per molti casi mid-market questo trade-off è accettabile.
Il costo che nessuno mette in slide: la manutenzione
Qui sta il punto che mi preme di più. Andare headless non è una decisione di frontend: è una decisione di architettura e di costo di gestione pluriennale.
Quando disaccoppi, ti prendi in casa: due codebase invece di una, un layer API da tenere allineato a ogni upgrade di Adobe Commerce, un’infrastruttura di rendering aggiuntiva (spesso Node) da monitorare, e la responsabilità di ricostruire a mano funzionalità che nel frontend tradizionale avevi “gratis” via modulo. Ho visto un merchant fashion di taglia media entusiasta della PWA in fase di demo ritrovarsi, sei mesi dopo, con un backlog di piccole feature — un filtro, un badge promozionale, un blocco CMS — che nel vecchio tema erano cinque minuti e in headless erano mezza giornata di sviluppo ciascuna.
Il conto della manutenzione headless si paga ogni mese, non solo al lancio. E si paga in competenze: servono developer JavaScript veri, non solo template Magento.
La mia posizione per il mid-market, oggi
Sarò netto. A metà 2021, la maggior parte dei merchant mid-market su Adobe Commerce non ha bisogno di andare headless, e molti di quelli che lo vogliono lo vogliono per le ragioni sbagliate — perché è di moda, o perché un vendor ha mostrato numeri di performance senza mostrare la bolletta di manutenzione.
Ha senso andare headless quando ricorre almeno una di queste condizioni: performance frontend che sono davvero un vincolo di business misurabile e non un capriccio; un team con competenze JavaScript/React o Vue già dentro casa; l’esigenza reale di servire più touchpoint (web, app, chiosco) dallo stesso backend; oppure un frontend così custom da rendere il tema tradizionale una gabbia.
Se nessuna di queste ricorre, il mio consiglio è impopolare ma concreto: ottimizza il frontend tradizionale, che con Adobe Commerce 2.4 è più capace di quanto si dica, e tieni GraphQL come opzione futura. Il headless non scappa. Sarà più maturo tra un anno di quanto lo sia oggi, e nel frattempo non avrai pagato il conto della manutenzione per un vantaggio che forse non ti serviva.
Mini-FAQ
PWA Studio è pronto per la produzione a metà 2021?
Gli strumenti sì, ma Venia è una reference da riscrivere, non un tema finito. Serve un team React solido per arrivare in produzione senza sorprese.
Vue Storefront e ScandiPWA funzionano con Adobe Commerce?
Sì, entrambi si integrano via GraphQL. ScandiPWA gira dentro Magento come tema; Vue Storefront usa un layer di integrazione separato che sta ancora stabilizzandosi.
Il headless migliora la SEO?
Non automaticamente. Migliora le performance percepite se fatto bene, ma richiede attenzione a server-side rendering e indicizzazione: fatto male, la SEO peggiora.
Quanto costa mantenere uno storefront headless?
Più del frontend tradizionale: due codebase, un’infrastruttura di rendering aggiuntiva e un layer API da riallineare a ogni upgrade. È un costo ricorrente, non una spesa una tantum.
Su di me. Sono Fabio Canovi, mi occupo di e-commerce enterprise su Magento e Adobe Commerce dal 2011. Sono tra i primi professionisti in Italia certificati Adobe Commerce e lavoro accanto ai merchant su architettura, performance e scelte di piattaforma. Su questo blog scrivo quello che penso davvero, senza slide di vendita.