Ogni nuovo progetto Salesforce B2C Commerce (ex Commerce Cloud / Demandware) parte dallo stesso bivio architetturale: restare su SFRA o andare headless con PWA Kit / storefront composable? È una delle decisioni a più alto impatto del progetto, perché plasma costo, hiring, time-to-market e performance per anni. Ecco come la ragiono.
Le due opzioni in un paragrafo ciascuna
SFRA (Storefront Reference Architecture) è lo storefront tradizionale, renderizzato lato server. Rendering, business logic e templating vivono tutti dentro B2C Commerce, costruiti su controller, template ISML e il modello a cartridge della piattaforma. È maturo, ben documentato, e tutto lo storefront sta in un unico posto.
Headless / Composable (PWA Kit + SCAPI) disaccoppia il frontend dal backend. Il tuo storefront è un’applicazione React (PWA Kit, o una tua) che parla con B2C Commerce tramite le Salesforce Commerce API (SCAPI) e le API headless. Il motore di commerce resta; il layer di presentazione diventa un’app indipendente che ospiti e deployi separatamente.
I fattori di decisione che contano davvero
Team e competenze
- SFRA richiede sviluppatori a loro agio con la piattaforma Salesforce B2C Commerce (ISML, cartridge, il dev model B2C).
- Headless richiede ingegneri JavaScript/React moderni più qualcuno che conosca SCAPI. Se il tuo team (o il tuo mercato del lavoro) è pieno di full-stack JS, l’headless abbassa la barriera di hiring per il frontend.
Time-to-market
- SFRA è più rapido da lanciare: parti da uno storefront di riferimento funzionante e personalizzi.
- Headless ha un costo iniziale di build più alto — stai assemblando un’app storefront — ma può poi essere più veloce da iterare.
Performance e UX
- Headless / PWA brilla per esperienze ricche, app-like, mobile-first e per il controllo granulare sui Core Web Vitals.
- SFRA offre una UX e-commerce solida e convenzionale con meno sforzo ingegneristico, ma sei più vincolato dal rendering della piattaforma.
Complessità e operations
- SFRA = una cosa sola da gestire, dentro la piattaforma.
- Headless = più parti in movimento: un frontend ospitato separatamente, contratti API, strategia di caching e una propria CI/CD. Più potenza, più superficie operativa.
Costo
- SFRA: build iniziale più basso, potenzialmente più vincolato in seguito.
- Headless: investimento iniziale più alto, più flessibilità e indipendenza a valle. Il costo totale dipende molto da quanto frontend custom ti serve davvero.
La mia regola pratica
Scegli SFRA quando lo storefront è abbastanza convenzionale, il time-to-market conta e il team è platform-centrico. Scegli headless quando l’esperienza è un elemento differenziante, ti serve una UX app-like e velocità di frontend indipendente, e hai (o vuoi) un team JS moderno.
In concreto:
- Brand mid-market, catalogo standard, deve lanciare questo trimestre → SFRA.
- Brand in cui l’esperienza di storefront è il prodotto, mobile-first, più touchpoint → headless.
- Incerto / in evoluzione → SFRA ora, con una separazione pulita della business logic, così un passaggio futuro all’headless sarà un’evoluzione e non una riscrittura.
La trappola: scegliere headless per il motivo sbagliato
“Headless” e “composable” sono le parole di moda, e molti progetti ci vanno perché suona moderno, poi pagano una complessità che non usano mai. L’headless è un mezzo per un fine — UX app-like, indipendenza del frontend, riuso omni-canale delle commerce API. Se nessuno di questi è un requisito reale, SFRA ti porta sul mercato più in fretta e a meno costo, e non c’è nulla di cui vergognarsi.
Qui il lavoro dell’architetto non è scegliere l’opzione alla moda. È far combaciare l’architettura con l’ambizione dell’esperienza, il team e la timeline — e tenere la business logic abbastanza pulita da non far sì che la scelta di oggi precluda quella di domani.