SAP Composable Storefront vs React/Next.js: Quando Scegliere Cosa

Questa domanda emerge in ogni workshop di strategia frontend per SAP Commerce Cloud che conduciamo. Il team di progetto si siede, disegna due riquadri sulla lavagna. A sinistra: Composable Storefront, il frontend headless Angular di SAP. A destra: un progetto React o Next.js personalizzato che consuma le stesse API OCC. Poi qualcuno chiede quale scegliere. E la risposta onesta è sempre la stessa — dipende da cinque fattori che non hanno nulla a che fare con le preferenze di framework.

L’e-commerce globale ha raggiunto 6,3 trilioni di dollari nel 2024, in crescita dell’8,4% anno su anno (eMarketer, 2025). Il vostro frontend non è un dettaglio tecnico. È ciò che i vostri clienti toccano. È dove il fatturato si concretizza o no.

TL;DR: SAP Composable Storefront vi porta sul mercato più velocemente (8-12 settimane) con oltre 200 componenti commerce pre-costruiti, integrazione SmartEdit e SEO nativo. Un build React/Next.js personalizzato offre piena libertà di design, un bacino di talenti più ampio e ottimizzazione delle performance superiore — ma costa il 40-60% in più inizialmente e richiede 12-20 settimane. Scegliete Composable Storefront per B2B/B2C standard, velocità e allineamento all’ecosistema SAP. Scegliete React/Next.js per esperienze B2C differenziate, team React esistenti e flessibilità a lungo termine. L’approccio ibrido — Composable Storefront come nucleo con micro-frontend React — spesso offre il meglio di entrambi.

La Decisione in 30 Secondi

Scegliete SAP Composable Storefront se:

• Dovete lanciare velocemente (meno di 12 settimane)
• Il vostro caso d’uso è B2B o B2C commerce standard
• L’integrazione SmartEdit è importante per il team contenuti
• I vostri sviluppatori conoscono Angular o possono formarsi
• L’allineamento all’ecosistema SAP è una priorità strategica

Scegliete React/Next.js se:

• La differenziazione UX è un vantaggio competitivo centrale
• Avete già un team React/frontend forte
• Servite controllo pixel-perfect su ogni interazione
• L’ottimizzazione delle performance all’edge (ISR, Streaming SSR) è critica
• Pianificate di servire più brand o canali da un’unica codebase

Considerate un approccio ibrido se:

• Volete le fondamenta commerce del Composable Storefront ma avete bisogno di esperienze personalizzate per pagine specifiche (PDP, landing page, configuratori)

Confronto Architetturale

Entrambi gli approcci consumano lo stesso backend. SAP Commerce Cloud espone le sue funzionalità attraverso API REST OCC. Lo storefront è un puro consumatore di API. Questa separazione è il motivo stesso per cui questa scelta esiste.

Architettura Composable Storefront

Browser → Angular App (Composable Storefront)
           ├── Composizione pagine CMS-driven (SmartEdit)
           ├── NgRx state management
           ├── 200+ componenti commerce pre-costruiti
           └── SSR via Angular Universal
                 ↕ OCC REST APIs (JSON)
           SAP Commerce Cloud (Backend)

Lo storefront include componenti che mappano direttamente sulla struttura CMS di Commerce Cloud. SmartEdit controlla il layout. Angular Universal gestisce il rendering lato server. L’integrazione è stretta e intenzionale — SAP ha progettato questi sistemi per lavorare insieme.

Architettura React/Next.js

Browser → Next.js App
           ├── Libreria componenti personalizzata (la costruite voi)
           ├── State management (a vostra scelta: Zustand, Redux, etc.)
           ├── SSR / SSG / ISR / Streaming (Next.js integrato)
           └── Headless CMS (Contentful, Storyblok, Sanity, etc.)
                 ↕ OCC REST APIs (JSON)
           SAP Commerce Cloud (Backend)

Costruite voi i componenti commerce. Scegliete il vostro CMS, state management e strategia di rendering. Le API OCC sono le stesse. Tutto il resto è a vostra discrezione.

Per uno sguardo approfondito sui layer backend di Commerce Cloud, consultate la nostra guida all’architettura Commerce Cloud.

SAP Composable Storefront: Cosa Ottenete Out-of-the-Box

Composable Storefront (il prodotto precedentemente noto come Spartacus) viene fornito con una quantità sostanziale di funzionalità pre-costruite. Questo è il suo vantaggio principale: partite con commerce funzionante, non con una tela bianca.

200+ componenti pre-costruiti. Product listing page, product detail page, carrello, checkout, il mio account, storico ordini, gestione organizzazioni B2B, workflow di approvazione, carrelli salvati, ordine rapido. Non sono componenti demo. Sono implementazioni pronte per la produzione che mappano direttamente sulle funzionalità backend di Commerce Cloud.

Integrazione SmartEdit. Il vostro team contenuti può riorganizzare i layout delle pagine, cambiare banner e gestire promozioni attraverso l’editor visuale di SAP senza toccare codice. Questo conta più di quanto la maggior parte dei team tecnici ammetta. Per un approfondimento su SmartEdit e l’architettura CMS, consultate la nostra guida alle funzionalità del Composable Storefront.

SEO nativo. Meta tag, URL canonici, dati strutturati, rendering lato server per la crawlability. Non perfetto, ma funzionale dal primo giorno. Lo ottimizzerete, ma non lo costruirete da zero.

Internazionalizzazione (i18n). Multi-lingua, multi-valuta, formattazione specifica per locale. Tutto integrato. Il backend Commerce Cloud gestisce i contenuti per locale; lo storefront li renderizza.

Funzionalità PWA. Supporto offline, installazione da homescreen, caching con service worker. Utile per scenari B2B mobile dove i rappresentanti lavorano in magazzini con connettività instabile.

Accessibilità (a11y). Conformità WCAG 2.1 AA integrata nella libreria componenti. Navigazione da tastiera, label ARIA, gestione del focus. Non impeccabile, ma un punto di partenza solido rispetto alla costruzione da zero.

Il rovescio della medaglia: è Angular. Se il vostro team conosce React ma non Angular, la curva di apprendimento è reale. Il state management NgRx è più verboso rispetto alle moderne librerie React. E l’SSR di Angular Universal non è maturo quanto quello di Next.js per strategie di rendering complesse.

React/Next.js: Cosa Costruite Voi

Scegliere React/Next.js significa scegliere libertà — e responsabilità. Ecco cosa Next.js offre che Composable Storefront non ha, e cosa dovrete costruire da soli.

Server-Side Rendering, fatto meglio. Next.js 15 supporta generazione statica (SSG), server-side rendering (SSR), incremental static regeneration (ISR) e streaming con React Suspense. Potete combinare strategie per route. Una product listing page può essere generata staticamente e rivalidata ogni 60 secondi. Una pagina carrello può essere completamente dinamica. Questa granularità non esiste nell’approccio Angular Universal del Composable Storefront.

Ottimizzazione immagini. Next.js Image gestisce dimensioni responsive, lazy loading, conversione formato (WebP/AVIF) e integrazione CDN automaticamente. I siti commerce sono ricchi di immagini. Fa la differenza.

Edge Runtime. Deploy su Vercel, Cloudflare Workers o AWS Lambda@Edge. Eseguire la logica di rendering vicino all’utente. L’SSR di Composable Storefront gira su un server Node.js — nessuna opzione di edge deployment.

React Server Components. Ridurre il JavaScript lato client spostando data fetching e rendering sul server. Meno JS inviato al browser. Time to Interactive più veloce.

Ampiezza dell’ecosistema. Headless CMS (Contentful, Storyblok, Sanity, Builder.io), librerie di componenti (Radix, shadcn/ui), animazioni (Framer Motion), testing (Playwright, Testing Library) — l’ecosistema React è enorme.

Cosa costruite da soli: ogni singolo componente commerce. PLP, PDP, carrello, checkout, il mio account, flussi B2B, carrelli salvati, workflow di approvazione. Consumate le stesse API OCC, ma scrivete ogni componente, ogni integrazione API, ogni pattern di state management. Sono oltre 200 componenti che Composable Storefront fornisce gratuitamente.

Per una prospettiva più ampia sui pattern headless e composable, il nostro approfondimento headless vs composable commerce copre il pensiero strategico dietro queste architetture.

Confronto Funzionalità

Confronto Performance

Le performance sono il punto in cui l’argomento React/Next.js diventa convincente. Quando fatto bene.

Core Web Vitals. Composable Storefront offre punteggi discreti out-of-the-box. La performance Lighthouse tipica si attesta su 70-85 per un’implementazione standard. Il bundle Angular è più pesante di un’app React ben ottimizzata, e l’hydration di Angular Universal aggiunge overhead. Un build Next.js ottimizzato con React Server Components, streaming SSR e edge rendering raggiunge regolarmente 90+ su Lighthouse. È un divario significativo per storefront rivolti ai consumatori. Google ha confermato che i Core Web Vitals restano un segnale di ranking e i merchant con siti più veloci registrano il 15-20% in più di conversion rate (Google Web.dev, 2024).

First Contentful Paint (FCP). Composable Storefront: 1,5-2,5s tipico. Next.js con SSG/ISR: 0,5-1,2s tipico. La differenza viene dalla generazione statica — Next.js può servire HTML pre-costruito da un CDN senza attendere un render lato server.

Largest Contentful Paint (LCP). Le product detail page con immagini pesanti sono il banco di prova. Next.js Image con priority loading e format negotiation supera costantemente l’approccio di Angular. Risparmi di 0,5-1,5 secondi sono comuni.

Total Blocking Time (TBT). La change detection di Angular e il state management NgRx generano più lavoro sul main thread rispetto a un setup React snello. I React Server Components mirano precisamente a questo, spostando il rendering fuori dal client.

L’avvertenza. Un sito Next.js costruito male performa peggio di un Composable Storefront ben configurato. Questi numeri presuppongono un’implementazione competente su entrambi i fronti. L’ecosistema React offre più leve per le performance, ma dovete utilizzarle.

Il Fattore Talento

Questo è il fattore che la maggior parte dei documenti di architettura ignora. Spesso è quello decisivo.

Il Stack Overflow Developer Survey 2025 posiziona React come il framework web più popolare, utilizzato dal 39,5% degli sviluppatori professionisti, mentre Angular si attesta al 17,1% (Stack Overflow, 2025). È un divario di 2,3 volte nel bacino di talenti.

Cosa significa in pratica:

• Assunzioni. Una posizione per sviluppatore frontend React attrae circa il doppio dei candidati rispetto a una posizione Angular equivalente. Nei mercati competitivi (Zurigo, Monaco, Londra), questo conta.
• Stipendi. Sviluppatori Angular specializzati con esperienza SAP richiedono un premio. Gli sviluppatori React sono più disponibili, il che mantiene le tariffe di mercato più competitive.
• Disponibilità di contractor. Se dovete scalare rapidamente con contractor esterni o agenzie, il bacino React è sostanzialmente più profondo.
• Trasferimento di conoscenze. I nuovi membri del team si ambientano più velocemente nei progetti React perché è più probabile che abbiano esperienza pregressa.

Il controargomento. Gli sviluppatori Angular tendono ad avere più esperienza con pattern enterprise (dependency injection, servizi tipizzati, RxJS). Se il vostro team conosce già Angular, cambiare a React per seguire un trend di mercato è costoso e rischioso. Usate ciò che il vostro team conosce.

Confronto Costi

Numeri reali da progetti frontend Commerce Cloud comparabili. Ipotesi: uno storefront B2B o B2C standard con 50-100 prodotti, checkout standard, multi-lingua e integrazione con un fornitore di pagamento.

La sfumatura. React/Next.js costa di più inizialmente e nel primo anno. Ma se gestite più storefront, la libreria di componenti condivisa si ammortizza su tutte le proprietà. Al terzo anno, una libreria React ben gestita che serve tre storefront può costare meno per storefront rispetto a tre personalizzazioni Composable Storefront separate.

L’Approccio Ibrido

Ecco cosa raccomandiamo più spesso nel 2025 e 2026: usare entrambi. Non in modo disordinato. Strategicamente.

Il pattern: Composable Storefront gestisce il percorso commerce principale — product listing, product detail, carrello, checkout, il mio account. È dove i 200+ componenti guadagnano il loro spazio. Poi costruite esperienze specifiche ad alto impatto in React e le montate come micro-frontend all’interno dello shell dello storefront.

Dove i micro-frontend React trovano spazio:

• Configuratori di prodotto. Configuratori 3D complessi o product builder personalizzati dove il modello a componenti di React e l’ecosistema (Three.js, React Three Fiber) hanno un chiaro vantaggio.
• Landing page. Pagine specifiche per campagne con animazioni personalizzate, storytelling interattivo o layout ricchi di contenuti dove la libertà di design conta di più.
• App mobile. React Native condivide la logica dei componenti con il vostro codice React web. Composable Storefront non ha una storia mobile nativa.
• Engine di personalizzazione. Widget di raccomandazione in tempo reale o esperienze guidate dall’IA costruite con streaming React Server Components.

Come funziona tecnicamente: Il CMS di SAP Commerce Cloud supporta componenti personalizzati. Registrate un micro-frontend React come componente CMS, e SmartEdit può posizionarlo su qualsiasi pagina accanto ai componenti standard di Composable Storefront. Il micro-frontend si carica indipendentemente e comunica con il parent tramite custom event o un bus di stato condiviso.

Questo approccio garantisce l’80% del vantaggio time-to-market di Composable Storefront preservando la flessibilità di React dove conta di più.

Framework Decisionale

Percorrete queste cinque domande in ordine. Ognuna restringe la scelta.

1. Qual è la vostra timeline? Meno di 12 settimane al go-live? Composable Storefront. I componenti pre-costruiti e l’integrazione SmartEdit fanno risparmiare 4-8 settimane rispetto a un build personalizzato. Nessuna quantità di talento React compensa questo quando il tempo è il vincolo.

2. Cosa conosce il vostro team? Team Angular esistente con esperienza SAP? Composable Storefront. Team React esistente senza esperienza Angular? React/Next.js. Il costo di riconversione è reale: 2-3 mesi di produttività ridotta mentre gli sviluppatori imparano un nuovo framework, pattern di state management e approccio al testing. Team misto? Considerate l’ibrido.

3. Lo storefront è un differenziatore di marca o uno strumento funzionale? Portale ordini B2B, self-service clienti, funzionalità di riordino? Composable Storefront gestisce questo con personalizzazione minima. Esperienza di marca consumer-facing dove ogni interazione è progettata? React/Next.js offre il controllo a livello di pixel. La distinzione conta. La maggior parte degli storefront B2B sono strumenti funzionali. La maggior parte delle esperienze B2C ambiziose sono differenziatori di marca.

4. Quanto è importante SmartEdit? Se il vostro team marketing deve gestire contenuti, layout e promozioni senza coinvolgimento degli sviluppatori, l’integrazione SmartEdit è un vantaggio significativo. Replicare questo con un headless CMS (Contentful, Storyblok) funziona, ma è un sistema separato con la propria curva di apprendimento, costo di licenza e lavoro di integrazione.

5. Qual è il vostro piano a 3 anni? Storefront singolo, requisiti stabili, investimento nell’ecosistema SAP? La roadmap allineata SAP di Composable Storefront è un vantaggio. Storefront multipli, evoluzione frontend rapida, potenziale migrazione di framework? React/Next.js con una libreria di componenti condivisa offre più flessibilità.

Cosa Vediamo in Pratica

Negli ultimi tre anni, abbiamo realizzato frontend Commerce Cloud con entrambi gli approcci. Il pattern è chiaro: Composable Storefront vince su velocità e costi per commerce standard. React/Next.js vince su flessibilità e performance per esperienze differenziate. L’ibrido vince quando servono entrambi.

L’errore più comune che vediamo: scegliere React/Next.js perché il team “preferisce React” e poi passare 16 settimane a ricostruire componenti che Composable Storefront fornisce out-of-the-box. La preferenza di framework è legittima. Ma non dovrebbe costare CHF 100’000 in sforzo duplicato.

Il secondo errore più comune: scegliere Composable Storefront e poi lottare con Angular per 6 mesi per costruire un’esperienza altamente personalizzata che React gestirebbe nativamente. Se il vostro team di design consegna file Figma che non assomigliano per niente a uno storefront standard, i componenti di Composable Storefront diventano un vincolo, non un acceleratore.

Adattate lo strumento al lavoro. Non il contrario.

Serve aiuto nella decisione? Conduciamo assessment di architettura frontend per SAP Commerce Cloud che valutano il vostro team, la vostra timeline e i vostri requisiti — e raccomandiamo l’approccio che genera valore più velocemente. Parlate con i nostri architetti commerce.

Per saperne di più sulle funzionalità di SAP Commerce Cloud, visitate la nostra pagina soluzioni E-Commerce.

Domande Frequenti

SAP Composable Storefront è la stessa cosa di Spartacus?

Sì. SAP ha rinominato Spartacus in “SAP Composable Storefront” nel 2023. Stesso prodotto, stessa codebase Angular, stessa integrazione API OCC di Commerce Cloud. Il nome è cambiato; la tecnologia no. La maggior parte degli sviluppatori dice ancora Spartacus in conversazione. La documentazione SAP usa esclusivamente “Composable Storefront”.

Posso usare React con SAP Commerce Cloud?

Sì. Commerce Cloud espone API REST OCC (Omni Commerce Connect) che qualsiasi framework frontend può consumare. React, Next.js, Vue, Svelte — qualsiasi cosa che possa fare richieste HTTP funziona. Il layer API OCC è framework-agnostico by design. Perdete l’editor visuale di SmartEdit e i componenti commerce pre-costruiti, ma guadagnate il controllo totale sull’architettura frontend.

Quale approccio è più rapido da implementare?

Composable Storefront è più rapido per scenari B2B/B2C standard: 8-12 settimane contro 12-20 settimane per un build React/Next.js personalizzato. Gli oltre 200 componenti pre-costruiti, l’integrazione SmartEdit e il mapping CMS Commerce Cloud esistente fanno risparmiare tempo di sviluppo significativo. Il divario si riduce per esperienze altamente personalizzate dove i componenti di Composable Storefront necessitano comunque di pesanti modifiche.

Quale approccio è più costoso?

Un React/Next.js personalizzato costa il 40-60% in più inizialmente perché ogni componente commerce va costruito da zero. Serve anche una licenza headless CMS separata (CHF 6’000-24’000/anno). Composable Storefront include SmartEdit e la libreria componenti. Su tre anni, la differenza di costo si riduce se gestite più storefront con una libreria React condivisa — ma per un singolo storefront, Composable Storefront è costantemente più economico.

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

Angular non sta morendo. È supportato da Google, vede sviluppo attivo (Angular 18 ha introdotto la reattività basata su segnali) e ha una vasta base utenti enterprise. Detto ciò, il bacino di talenti React è 2,3 volte più grande secondo i dati dei sondaggi tra sviluppatori. Questo influisce sulla velocità di assunzione e sulla disponibilità di contractor, non sulla vitalità del framework. Se avete già sviluppatori Angular, non c’è motivo di cambiare. Se state costruendo un team da zero, il bacino di talenti più ampio di React è un vantaggio pratico.