SAP Composable Storefront vs React/Next.js: quando scegliere cosa

Questa domanda emerge in ogni workshop sul frontend di SAP Commerce Cloud che conduciamo. A sinistra sulla lavagna: lo SAP Composable Storefront, il frontend headless di SAP basato su Angular. A destra: un frontend React o Next.js su misura che usa le stesse API OCC. La risposta dipende da cinque fattori, e la preferenza per un framework non è tra questi.

In sintesi: lo SAP Composable Storefront porta online più rapidamente (circa 8-12 settimane per uno storefront tipico), con un’ampia libreria di componenti commerce predefiniti, integrazione con SmartEdit e rendering lato server inclusi. Un frontend React/Next.js su misura offre piena libertà di design, più opzioni di rendering e un bacino di sviluppatori più ampio, ma costa in genere dal 40 al 60 per cento in più e richiede 12-20 settimane. Il Composable Storefront è la scelta per B2B e B2C standard, rapidità e allineamento con SAP; React/Next.js per esperienze B2C distintive e team React già esistenti. Un approccio ibrido (Composable Storefront come base, micro-frontend React per pagine specifiche) spesso combina entrambi.

La decisione in 30 secondi

Scegliete lo SAP Composable Storefront se:

• dovete andare online in fretta (meno di 12 settimane);
• il vostro caso d’uso è un commercio B2B o B2C standard;
• SmartEdit è importante per il team dei contenuti;
• i vostri sviluppatori conoscono Angular o possono impararlo;
• l’allineamento con la roadmap di SAP è una priorità.

Scegliete React/Next.js se:

• un’esperienza utente distintiva è un vantaggio competitivo centrale;
• avete già un team React solido;
• vi serve il pieno controllo su ogni interazione;
• il rendering edge e la rigenerazione statica incrementale sono importanti;
• prevedete di servire più marchi o canali da un’unica libreria di componenti.

Valutate un approccio ibrido se volete la base commerce del Composable Storefront ma vi servono esperienze su misura per pagine specifiche, come configuratori di prodotto o pagine di campagna.

Confronto architetturale

Entrambi gli approcci usano lo stesso backend. SAP Commerce Cloud espone le sue funzioni tramite le API REST OCC e lo storefront è un puro consumatore di API. È proprio questo disaccoppiamento a rendere possibile la scelta.

Composable Storefront

Browser → App Angular (Composable Storefront)
           ├── Composizione delle pagine guidata dal CMS (SmartEdit)
           ├── Gestione dello stato con NgRx
           ├── Componenti commerce predefiniti
           └── Rendering lato server (Angular SSR su Node.js)
                 ↕ API REST OCC (JSON)
           SAP Commerce Cloud (backend)

I componenti dello storefront sono allineati direttamente alla struttura CMS di Commerce Cloud, SmartEdit controlla il layout e il rendering lato server di Angular genera la prima pagina. SAP ha progettato questi elementi per funzionare insieme (SAP Help: About Composable Storefront).

React/Next.js

Browser → App Next.js
           ├── Libreria di componenti propria (da costruire)
           ├── Gestione dello stato (a scelta: Zustand, Redux ...)
           ├── SSR / SSG / ISR / streaming (integrati in Next.js)
           └── CMS headless (Contentful, Storyblok, Sanity ...)
                 ↕ API REST OCC (JSON)
           SAP Commerce Cloud (backend)

I componenti commerce si costruiscono in proprio e si scelgono liberamente CMS, gestione dello stato e strategia di rendering. Le API OCC sono le stesse, tutto il resto è una vostra decisione. I livelli del backend dietro le API sono descritti nella nostra panoramica su SAP Commerce Cloud.

SAP Composable Storefront: che cosa si ottiene subito

Il Composable Storefront (in precedenza Spartacus) include molte funzionalità già operative. È il suo vantaggio principale: si parte da un commercio funzionante, non da una tela bianca.

Componenti commerce predefiniti. Elenchi e schede prodotto, carrello, checkout, area personale, storico ordini, gestione delle organizzazioni B2B, flussi di approvazione, carrelli salvati, ordine rapido. Sono componenti di produzione allineati alle funzioni del backend di Commerce Cloud, non dimostrazioni.

Integrazione con SmartEdit. Il team dei contenuti riorganizza i layout, cambia i banner e gestisce le promozioni nell’editor visuale di SAP senza toccare il codice. Conta più di quanto la maggior parte dei team tecnici ammetta. La nostra guida al Composable Storefront spiega in dettaglio l’architettura CMS.

SEO dal primo giorno. Meta tag, URL canonici, dati strutturati e rendering lato server per i crawler. Andrà affinato, ma non costruito da zero.

Internazionalizzazione. Più lingue e valute e formati locali; i contenuti per lingua arrivano dal backend.

Funzioni PWA. Supporto offline, installazione sulla schermata iniziale, caching tramite service worker. Utile negli scenari B2B con connettività debole, per esempio per il personale di magazzino.

Accessibilità. I componenti prevedono navigazione da tastiera, etichette ARIA e gestione del focus. Non perfetti, ma un vero punto di partenza rispetto a costruire tutto da zero.

Il rovescio della medaglia: è Angular. Se il team conosce React e non Angular, la curva di apprendimento è reale. NgRx è più verboso delle moderne librerie di stato per React e il rendering lato server di Angular offre meno strategie per singola route rispetto a Next.js. SAP porta lo storefront a una nuova versione principale di Angular una volta l’anno, a febbraio; con la release 2211.36, per esempio, è arrivato il passaggio ad Angular 19 e Node.js 22.

React/Next.js: che cosa si costruisce in proprio

React/Next.js significa libertà, con la responsabilità che ne deriva.

Più opzioni di rendering. Next.js supporta generazione statica (SSG), rendering lato server (SSR), rigenerazione statica incrementale (ISR) e streaming con React Suspense, combinabili per singola route. Un elenco prodotti può essere generato staticamente e riconvalidato ogni minuto, mentre il carrello resta completamente dinamico.

Ottimizzazione delle immagini. Next.js gestisce dimensioni responsive, lazy loading, conversione di formato (WebP, AVIF) e distribuzione via CDN. I siti commerce sono ricchi di immagini, e la differenza si somma.

Edge runtime. Distribuzione su Vercel, Cloudflare Workers o AWS Lambda@Edge, con rendering vicino all’utente. L’SSR del Composable Storefront gira su un server Node.js; SAP non offre un’opzione di rendering edge.

React Server Components. Recupero dei dati e rendering si spostano sul server, così al browser arriva meno JavaScript.

Ecosistema ampio. Opzioni di CMS headless, librerie di componenti (Radix, shadcn/ui), strumenti di animazione e di test. L’ecosistema React è molto vasto.

Che cosa si costruisce in proprio: ogni componente commerce. Elenchi prodotto, schede prodotto, carrello, checkout, area personale, flussi B2B, carrelli salvati, flussi di approvazione. Si usano le stesse API OCC, ma ogni componente, ogni integrazione API e ogni schema di stato che il Composable Storefront fornisce già pronti vanno scritti da zero. Per il dibattito architetturale più ampio c’è il nostro articolo sul composable commerce nel B2B.

Confronto delle funzionalità

Dimensione	Composable Storefront	React/Next.js
Time-to-market	Circa 8-12 settimane (B2B/B2C tipico)	12-20 settimane
Componenti commerce predefiniti	Ampia libreria, pronta per la produzione	Da costruire da zero
SmartEdit / CMS	Integrazione nativa	Serve un CMS headless (costi e integrazione aggiuntivi)
SEO	SSR, meta tag, URL canonici integrati	Più opzioni: SSG, ISR, SSR edge, streaming
Core Web Vitals	Buoni con l’ottimizzazione standard	Eccellenti se ben ottimizzati
Strategie di rendering	SSR (Angular)	SSR, SSG, ISR, streaming, edge
Bacino di sviluppatori	Più ridotto (Angular)	Più ampio (React)
Limite di personalizzazione	Alto, entro i pattern Angular	Illimitato
Mobile / PWA	Funzioni PWA integrate	PWA da configurare, opzione React Native
Accessibilità	Componenti accessibili come base	Da costruire (o Radix, Headless UI)
Gestione dello stato	NgRx (incluso)	A scelta (Zustand, Redux, Jotai)
Allineamento con SAP	Totale: roadmap, supporto e patch di SAP	Nessuno: tutto è a vostro carico
CDN / deployment edge	Server Node.js	Vercel, Cloudflare, AWS edge
Percorso di aggiornamento	Release gestite da SAP	Framework e codice proprio: li gestite voi
Costo iniziale	Più basso	In genere dal 40 al 60 per cento più alto

Confronto delle prestazioni

Sulle prestazioni l’argomento a favore di React/Next.js diventa convincente, se il lavoro è fatto bene.

Core Web Vitals. Il Composable Storefront offre risultati discreti di partenza. Il bundle Angular è più pesante di un’applicazione React ben ottimizzata e l’idratazione aggiunge lavoro. Una build Next.js curata con React Server Components, streaming e rendering edge può andare oltre. Per gli storefront rivolti ai consumatori la differenza conta, perché i Core Web Vitals fanno parte dei segnali con cui Google Search valuta l’esperienza sulla pagina.

Primo rendering. Con la generazione statica Next.js può servire HTML già pronto dal CDN senza attendere un rendering sul server, il che di solito riduce sensibilmente il First Contentful Paint.

Largest Contentful Paint. Le schede prodotto ricche di immagini sono il vero banco di prova. La gestione delle immagini di Next.js, con caricamento prioritario e negoziazione del formato, tende a fare meglio di una configurazione Angular standard.

Lavoro sul thread principale. Il change detection di Angular e NgRx generano più lavoro sul thread principale di una configurazione React snella; i React Server Components riducono proprio questo carico.

L’avvertenza. Un sito Next.js costruito male è più lento di un Composable Storefront ben configurato. L’ecosistema React offre più leve sulle prestazioni, ma bisogna saperle usare.

Il fattore competenze

È il fattore che la maggior parte dei documenti di architettura trascura, e spesso è quello decisivo.

Nello Stack Overflow Developer Survey 2024, il 39,5 per cento degli intervistati usava React e il 17,1 per cento Angular (Stack Overflow Developer Survey 2024), un rapporto di oltre due a uno.

Che cosa significa in pratica:

• Assunzioni. Le posizioni React attirano in genere molte più candidature di quelle Angular equivalenti, un aspetto che conta in mercati tesi come Zurigo o Monaco.
• Tariffe. Gli sviluppatori Angular con esperienza SAP sono richiesti e più costosi; gli sviluppatori React sono più facili da trovare.
• Collaboratori esterni. Per crescere rapidamente con sviluppatori esterni, il bacino React è molto più ampio.
• Inserimento. I nuovi membri del team conoscono più spesso React.

L’argomento contrario. Gli sviluppatori Angular hanno spesso più dimestichezza con i pattern enterprise (dependency injection, servizi tipizzati, RxJS). Se il team conosce già Angular, passare a React solo per seguire una tendenza di mercato è costoso e rischioso. Conviene usare ciò che il team sa fare.

Confronto dei costi

Valori indicativi per la pianificazione di uno storefront B2B o B2C standard con un catalogo di dimensioni moderate, checkout standard, più lingue e un fornitore di pagamento. Sono stime di orientamento, non offerte.

Voce di costo	Composable Storefront	React/Next.js
Realizzazione iniziale	CHF 120’000-180’000	CHF 180’000-300’000
Licenza CMS headless	Inclusa (SmartEdit)	CHF 6’000-24’000 all’anno
Manutenzione annua (sviluppo)	CHF 40’000-60’000 (1-2 sviluppatori)	CHF 60’000-100’000 (2-3 sviluppatori)
Licenza SAP	Inclusa in Commerce Cloud	Inclusa in Commerce Cloud
Hosting / CDN	Server Node.js su SAP Commerce Cloud	Vercel/Cloudflare (CHF 2’400-12’000 all’anno)
Totale su tre anni	CHF 240’000-360’000	CHF 370’000-600’000

La sfumatura. React/Next.js costa di più all’inizio e nel primo anno. Con più storefront, però, una libreria di componenti condivisa si ripartisce su più siti e al terzo anno può costare meno per storefront di diversi Composable Storefront personalizzati separatamente. Il budget complessivo della piattaforma è scomposto nella nostra guida a prezzi e TCO di SAP Commerce Cloud.

L’approccio ibrido

Ciò che dal 2025 raccomandiamo sempre più spesso: usare entrambi, in modo mirato.

Lo schema: il Composable Storefront gestisce il percorso commerce principale: elenchi prodotto, schede prodotto, carrello, checkout, area personale. È lì che i suoi componenti predefiniti rendono. Esperienze selezionate ad alto impatto si costruiscono in React e si inseriscono come micro-frontend nella struttura dello storefront.

Dove si inseriscono i micro-frontend React:

• Configuratori di prodotto. Configuratori 3D o strumenti di composizione del prodotto, dove l’ecosistema React (Three.js, React Three Fiber) ha un vantaggio netto.
• Pagine di campagna. Pagine con animazioni personalizzate, storytelling interattivo o layout ricchi di contenuti, dove la libertà di design conta di più.
• App mobili. React Native condivide la logica con il codice React per il web; il Composable Storefront non ha un’app nativa propria.
• Personalizzazione. Widget di raccomandazione in tempo reale o esperienze basate sull’IA.

Dal punto di vista tecnico: il CMS di Commerce Cloud supporta componenti personalizzati. Si registra un micro-frontend React come componente CMS e SmartEdit può collocarlo su qualsiasi pagina accanto ai componenti standard. Il micro-frontend si carica in modo indipendente e comunica con la struttura tramite eventi personalizzati o un canale di stato condiviso.

Così si conserva la maggior parte del vantaggio di tempo del Composable Storefront e React porta la sua flessibilità dove serve davvero.

Schema decisionale

Queste cinque domande vanno affrontate nell’ordine. Ognuna restringe la scelta.

1. Qual è la vostra tempistica? Meno di 12 settimane al go-live: Composable Storefront. I suoi componenti e l’integrazione con SmartEdit fanno risparmiare diverse settimane rispetto a un frontend su misura, e nessun talento React compensa questo vantaggio quando il tempo è il vincolo.

2. Che cosa sa fare il vostro team? Un team Angular con esperienza SAP: Composable Storefront. Un team React senza Angular: React/Next.js. La riqualificazione ha un costo: vanno messi in conto alcuni mesi di produttività ridotta mentre gli sviluppatori imparano un nuovo framework, un nuovo schema di stato e un nuovo approccio ai test. Un team misto: valutate l’approccio ibrido.

3. Lo storefront è un’esperienza di marca o uno strumento funzionale? Portali d’ordine B2B, self-service e riordini sono gestiti dal Composable Storefront con poche personalizzazioni. Un’esperienza di marca per i consumatori in cui ogni interazione è progettata richiede React/Next.js. La maggior parte degli storefront B2B sono strumenti funzionali; la maggior parte delle esperienze B2C ambiziose sono esperienze di marca.

4. Quanto conta SmartEdit? Se il marketing deve gestire contenuti, layout e promozioni senza sviluppatori, SmartEdit è un vantaggio notevole. Un CMS headless può sostituirlo, ma è un ulteriore sistema con la sua curva di apprendimento, la sua licenza e la sua integrazione.

5. Qual è il vostro piano a tre anni? Un solo storefront, requisiti stabili e un investimento in SAP: la roadmap del Composable Storefront allineata a SAP è un vantaggio. Più storefront, rapida evoluzione del frontend o un possibile cambio di framework in futuro: React/Next.js con una libreria di componenti condivisa lascia più margine.

Che cosa vediamo nella pratica

Abbiamo realizzato frontend per Commerce Cloud con entrambi gli approcci. Lo schema è costante: il Composable Storefront vince su rapidità e costi nel commercio standard, React/Next.js su flessibilità e prestazioni per esperienze distintive, e l’approccio ibrido quando servono entrambe le cose. Da Distrelec, il disaccoppiamento del frontend da SAP Commerce tramite un livello API pulito ha ridotto il time-to-market del 70%.

L’errore più frequente: scegliere React/Next.js perché il team preferisce React e poi passare mesi a ricostruire componenti che il Composable Storefront fornisce già pronti. La preferenza per un framework è legittima, ma non dovrebbe costare cifre a sei zeri di lavoro duplicato.

Il secondo errore più frequente: scegliere il Composable Storefront e poi combattere per mesi con Angular per costruire un’esperienza molto personalizzata che con React verrebbe più naturale. Se il team di design consegna progetti che non hanno nulla a che vedere con uno storefront standard, i suoi componenti diventano un vincolo invece che un acceleratore.

Lo strumento va scelto in base al lavoro, non il contrario. Se la scelta dello storefront fa parte di un progetto più ampio, il nostro articolo su che cosa succede davvero in un’implementazione di Commerce Cloud la inquadra.

---

Vi serve aiuto per decidere? Conduciamo valutazioni dell’architettura frontend per SAP Commerce Cloud che analizzano team, tempistiche e requisiti e raccomandano l’approccio che porta valore più rapidamente. Parlate con i nostri architetti commerce. Maggiori dettagli sul nostro lavoro con Commerce Cloud sono sulla pagina della soluzione SAP Commerce Cloud.

Domande frequenti

Lo SAP Composable Storefront è la stessa cosa di Spartacus?

Sì. Dalla release 5.0 SAP pubblica le librerie ufficiali di Spartacus come «SAP Commerce Cloud, composable storefront». È la stessa base di codice Angular con la stessa integrazione tramite API OCC; dalla versione 2211.19 la numerazione segue quella di Commerce Cloud. Molti sviluppatori dicono ancora Spartacus, la documentazione di SAP parla di Composable Storefront.

Si può usare React con SAP Commerce Cloud?

Sì. Commerce Cloud espone le API REST OCC (Omni Commerce Connect), utilizzabili da qualsiasi framework frontend: React, Next.js, Vue e altri. Si rinuncia al rendering delle pagine già pronto di SmartEdit e ai componenti commerce predefiniti di SAP, in cambio del pieno controllo sull’architettura frontend.

Quale approccio è più rapido da implementare?

Il Composable Storefront è più rapido negli scenari standard B2B e B2C: circa 8-12 settimane per uno storefront tipico personalizzato, contro 12-20 settimane per un frontend React/Next.js su misura. La maggior parte del tempo si risparmia grazie ai componenti predefiniti e alla mappatura CMS già esistente. Il divario si riduce per esperienze molto personalizzate, in cui i componenti standard vanno comunque modificati a fondo.

Quale approccio costa di più?

Un frontend React/Next.js su misura costa in genere dal 40 al 60 per cento in più da realizzare, perché ogni componente commerce va scritto e di solito serve un CMS headless separato. Il Composable Storefront è incluso nella licenza di Commerce Cloud e costa meno da realizzare, ma può richiedere molte personalizzazioni per un’esperienza utente molto distintiva. Su tre anni la differenza si riduce se più storefront condividono una libreria di componenti React; per un singolo storefront il Composable Storefront è di solito più economico.

Angular sta morendo? Devo preoccuparmi del framework del Composable Storefront?

No. Angular è sostenuto da Google, pubblica una nuova versione principale ogni sei mesi ed è molto diffuso nelle aziende; SAP porta lo storefront a una nuova versione di Angular una volta l’anno. React ha un bacino di sviluppatori più ampio, ma questo incide su assunzioni e disponibilità di collaboratori esterni, non sulla solidità del framework. Se avete già sviluppatori Angular non c’è motivo di cambiare; se costruite un team da zero, il bacino più ampio di React è un vantaggio pratico.