SAP Composable Storefront: Architecture, Pros, Cons and When You Need It

The SAP Composable Storefront (formerly Spartacus) is SAP’s Angular front end for Commerce Cloud and its recommended choice for new projects. It is a good default, but not an automatic one: it needs Angular skills, changes how your team works and adds a server-side rendering layer to operate. For many companies that pays off; for some, a custom headless front end or a different approach is the better fit.

This guide covers what the storefront is, how the architecture works, what a project needs before it starts, the real advantages and disadvantages, and a framework for the decision.

TL;DR: The Composable Storefront is an Angular application that talks to SAP Commerce Cloud only through the OCC REST APIs, with server-side rendering, CMS-driven pages from SmartEdit and B2B and B2C components. It is included in the Commerce Cloud licence. Choose it when you want SAP’s components and upgrade path and have (or will build) Angular skills; choose a custom React or Next.js front end when design freedom or an existing frontend stack matters more. The old JSP-based Accelerator is deprecated and scheduled for removal in September 2027.

What is the SAP Composable Storefront?

The Composable Storefront is the headless front end for SAP Commerce Cloud. Many developers still call it Spartacus, the name of the open-source project it comes from. From release 5.0, SAP ships the official libraries as “SAP Commerce Cloud, composable storefront”, and since version 2211.19 its version numbers follow Commerce Cloud itself (SAP Help: About Composable Storefront).

What defines it:

• Angular, with NgRx for state management. SAP moves the storefront to a new major Angular version once a year, in February.
• Headless: it communicates with Commerce Cloud exclusively through the OCC REST APIs.
• CMS-driven: page layouts come from SmartEdit instead of hard-coded templates.
• Server-side rendering (SSR) for search engines and a fast first page load, plus progressive web app features.
• Licensing: included in the Commerce Cloud licence. Cloud customers install the libraries from SAP’s repository; the source code remains open on GitHub.

It replaces the Accelerator storefront, the JSP templates rendered on the Commerce Cloud application servers and tightly coupled to the back end. SAP has deprecated the Accelerator UI templates and planned their removal and end of mainstream maintenance for September 2027, with an extended adoption period to September 2028 (SAP Help: Deprecation of Accelerator UIs).

How does the architecture work?

Three layers with a clear division of labour:

1. Commerce Cloud back end: cart, checkout, pricing, orders, product management and search. All of it exposed through APIs. (For the back-end layers themselves, see our SAP Commerce Cloud overview.)
2. OCC API layer: the REST endpoints the storefront calls for product search, cart, checkout and account management. The storefront never touches the database.
3. Composable Storefront: the Angular application in the browser, or on a Node.js server for SSR. It renders the UI, holds client-side state and calls the OCC APIs.

This separation lets you release the front end independently of the back end, serve several front ends (web, app, kiosk) from one back end and, if you ever need to, replace the front end entirely.

How the CMS integration works

1. Content managers create pages with content slots (header, body, footer, sidebar) in SmartEdit.
2. Each slot holds CMS components: banners, product carousels, text blocks, navigation.
3. The storefront loads the page structure from the CMS API.
4. Each CMS component type is mapped to an Angular component that renders it.
5. Changes in SmartEdit appear on the storefront without a deployment.

That is what makes the storefront “composable” in practice: pages are assembled from components that the marketing team controls.

Features that matter in projects

• SSR: the server renders the first page, the browser then takes over. Crawlers get complete HTML, users get a fast first paint.
• Lazy loading: modules load on demand, so the product list does not pull in the checkout code.
• Internationalisation: translation files per locale, language switching by URL or user preference.
• Extensibility: you replace SAP components with your own through Angular dependency injection instead of editing SAP’s source. It looks restrictive at first, and it is what keeps upgrades manageable.

What does a project need before it starts?

Technical prerequisites

• A Commerce Cloud environment with the OCC endpoints enabled for products, cart, checkout, CMS and users.
• Node.js and Angular CLI versions that match your storefront release (SAP’s compatibility information lists them; check it before writing code).
• Access to SAP’s repository for the storefront libraries.

Team prerequisites

• Angular, TypeScript and RxJS experience. This is not optional: teams with React experience who assumed Angular would be close enough have lost weeks on RxJS and dependency injection alone.
• Understanding of OCC authentication (OAuth 2.0).
• Access to Backoffice and SmartEdit for the CMS configuration.

Setup in five steps: scaffold the application with SAP’s schematics; configure the back-end URL, base site, language and currency; map CMS component types to Angular components (SAP provides the standard mappings, custom components need your own); configure SSR; then brand and extend. SAP’s community has a step-by-step installation walkthrough for the current 2211 releases.

The mistakes we see most often

• Version mismatch between storefront libraries and back end. Check compatibility first; it can cost a full sprint.
• SSR added late. SSR affects performance, social previews and load behaviour. Set it up from the start; retrofitting it is painful.
• Hard-coded content instead of CMS components, which creates deployments for simple content changes.
• Everything loaded eagerly. Review which modules load up front; on mobile the difference adds up.
• Desktop first. Test custom components on mobile from the beginning.

Keep your own code in feature modules, component overrides via dependency injection, shared modules and style overrides with CSS custom properties. SAP updates the storefront regularly, and code tangled into SAP’s turns every upgrade into a project.

What are the real advantages?

Independent releases. A promotion banner, a checkout change or a rendering fix ships without a full platform release, so the front end can move at its own release rhythm while the back end stays stable.

Frontend flexibility. Because the storefront talks to Commerce Cloud only through APIs, you can add components from elsewhere: product configurators, 3D viewers, chat.

SEO. With SSR, product and category pages are indexable without relying on client-side JavaScript.

Content autonomy. Marketing manages page layouts in SmartEdit without developer tickets.

SAP’s roadmap. SAP’s storefront development goes into the Composable Storefront, while the Accelerator templates are on their way out.

What are the real disadvantages?

Angular dependency. Your front-end team needs Angular, TypeScript and RxJS. Most SAP Commerce teams are Java-centred, so plan for hiring or training. A Java developer usually needs several months to become fully productive with the storefront; Angular’s component model and reactive patterns do not map to JSP development.

Higher initial effort. SSR, build pipeline, deployment and CMS mapping take more work than starting from Accelerator templates. Plan a few extra weeks.

An extra runtime. The SSR server is one more thing to deploy, monitor and keep healthy under load.

More code for small changes. Overriding Angular components and working with NgRx takes more code than editing a JSP template.

Components are a starting point. SAP’s components cover the standard flows, but rarely match your brand as delivered. Expect to override a large share of them for a distinctive design.

How do you decide?

Criterion	Composable Storefront	Custom headless (React, Next.js)	Accelerator
Framework	Angular	Your choice	JSP (legacy)
Time to a standard storefront	Four to eight weeks	Longer: checkout, account and CMS rendering built yourself	Existing builds only
CMS	SmartEdit, integrated	Integrate SmartEdit content or an external CMS yourself	SmartEdit
SAP support	Storefront and APIs	APIs only	Deprecated, removal planned for September 2027
Design freedom	Medium	Full	Limited

Choose the Composable Storefront if you are starting fresh, have Angular developers or are ready to build that capability, want SmartEdit out of the box and value SAP’s upgrade path.

Choose a custom headless front end if your team is strong in React or Next.js, your brand needs a fully bespoke design or you have already committed to an external CMS. Our detailed comparison of the Composable Storefront and React/Next.js walks through that trade-off. At Distrelec, decoupling the front end from SAP Commerce through a clean API layer cut time to market by 70%.

Stay on Accelerator only as a transition, and plan the move now. Our Accelerator to Composable Storefront migration guide describes a step-by-step approach. If the storefront decision is part of a larger platform change, see what actually happens in a Commerce Cloud implementation or talk to our SAP Commerce Cloud team.

FAQ

What is the difference between Spartacus and the SAP Composable Storefront?

It is the same product under a new name. From release 5.0, SAP publishes the official Spartacus libraries as “SAP Commerce Cloud, composable storefront”. The architecture is the same, and since version 2211.19 its version numbers follow SAP Commerce Cloud.

Does the Composable Storefront cost extra?

No. It is included in the SAP Commerce Cloud licence at no additional cost. Cloud customers get the libraries from SAP’s repository-based shipment channel; the source code remains open source on GitHub. What does cost money is the front-end team that builds and maintains your storefront.

Can I use React or Next.js instead of Angular?

Yes. The OCC REST APIs are technology-agnostic, so you can build a custom headless front end in React, Vue or Next.js. You give up SAP’s pre-built storefront components, the ready-made CMS rendering and SAP’s upgrade path, and you gain full design and technology freedom.

Can Accelerator and Composable Storefront run side by side?

Yes. During a migration both storefronts can run against the same Commerce Cloud back end, with traffic routed by URL or domain. Plan the switch-over: SAP has deprecated the Accelerator UI templates and scheduled their removal for September 2027.

How long does it take to build a Composable Storefront?

A basic storefront runs within a few days. A production-ready standard B2C storefront built from SAP’s components typically takes four to eight weeks, eight to twelve weeks with significant customisation, and B2B features add two to four weeks. These figures assume a team that already knows Angular.

Does the Composable Storefront support B2B commerce?

Yes. B2B features cover organisation and budget management, approval workflows, checkout with purchase order, quick order entry and saved carts. B2B and B2C modules can live in one build or in separate builds if the experiences differ a lot.