SAP Composable Storefront: Architecture, Features, and How It Works

The Composable Storefront is what your customers actually touch. Every other piece of Commerce Cloud (the type system, the extension mechanism, the commerce modules) feeds into this one layer. If you don’t understand how the storefront works architecturally, you’ll make bad decisions about customisation, performance, and frontend strategy that haunt you for years.

Here’s how it’s built and how it connects to Commerce Cloud’s backend.

TL;DR: The SAP Composable Storefront (formerly Spartacus) is an Angular-based, open-source headless frontend for SAP Commerce Cloud. It communicates with the backend exclusively through OCC REST APIs, supports Progressive Web App (PWA) capabilities, server-side rendering (SSR) for SEO, and CMS-driven page composition. Mobile commerce reached $2.07 trillion in 2024 — 57% of total e-commerce (Oberlo, 2025). The storefront is designed to serve that mobile-first reality.

What Is the Composable Storefront?

Mobile commerce reached $2.07 trillion in 2024, representing 57% of total e-commerce sales. That share is projected to reach 59% ($2.51 trillion) by 2025 (Oberlo, 2025). If your storefront can’t perform on mobile, it’s not a viable storefront. Full stop.

The Composable Storefront (used to be called Spartacus, and most developers still call it that) is SAP’s recommended frontend for Commerce Cloud. Here’s what defines it:

• Built on Angular with NgRx for state management
• Open-source on GitHub under Apache 2.0 licence
• Headless: communicates with Commerce Cloud exclusively through OCC REST APIs
• CMS-driven: page layouts managed through SmartEdit, not hardcoded in templates
• PWA-capable: offline support, installability, the works
• SSR-enabled: server-side rendering for SEO and faster initial page loads

It replaced the old Accelerator templates. JSP-based, server-side rendered, tightly coupled to the backend. If you lived through the Hybris era, you remember. I reckon the shift from Accelerator to Composable Storefront is the single biggest change in Commerce Cloud’s frontend story.

How Does the Architecture Work?

Gartner has named SAP a Leader in the Magic Quadrant for Digital Commerce for 11 consecutive years (SAP News, 2025). The headless architecture is a big reason why. It separates concerns properly.

Three layers:

1. Commerce Cloud backend handles the business logic: cart, checkout, pricing, orders, product management, search. Everything exposed through OCC REST APIs.

2. OCC API layer is the set of RESTful endpoints the storefront calls. Product search, cart operations, checkout, customer account management. The storefront never touches the database directly.

3. Composable Storefront is the Angular application running in the browser (or SSR on the server). It renders the UI, manages client-side state with NgRx, calls OCC APIs for data.

What this separation gives you:

• Update the frontend without touching the backend
• Deploy frontend and backend on independent release cycles
• Swap out the entire frontend for a different framework if needed
• Serve the same backend to multiple frontends (web, mobile app, kiosk)

The cleanest implementations we’ve seen treat the Composable Storefront as a pure API consumer. Customise through Angular components. Leave the OCC endpoints alone.

What Are the Key Features?

Global retail e-commerce reached $6.334 trillion in 2024, crossing 20% of all retail sales for the first time (eMarketer, 2024). The Composable Storefront packs features designed for that scale. Let me go through the ones that matter.

CMS-driven page composition. Pages are composed of content slots and CMS components defined in SmartEdit. Your marketing team can swap banners, product carousels, text blocks, and page layouts without a developer touching code. No deployments needed. For a team trying to move fast, this is a big deal.

Server-side rendering (SSR). Angular Universal renders the initial page on the server, then hydrates it in the browser. Search engines see fully rendered HTML, users get a fast first paint. Solid default for SEO.

Progressive Web App (PWA). Offline caching, add-to-home-screen prompts, push notification capabilities. PWA closes the gap between web and native app experiences. For many use cases it’s good enough that you don’t need a native app at all.

Lazy loading. Modules and components load on demand. Your product listing page doesn’t pull in the checkout module’s JavaScript until the user actually starts checking out. Smaller initial bundle, faster time-to-interactive.

Internationalisation (i18n). Built-in support for multiple languages and locales. Translation files loaded per locale, storefront switches languages based on URL path or user preference.

Extensibility. You customise by overriding Angular components, services, and modules. Not by modifying source code. SAP’s extension mechanism uses Angular’s dependency injection to let you replace any component with your own version. Prima vista it sounds limiting, but in practice it keeps your code clean and upgradeable.

How Does CMS Integration Work?

SmartEdit gives content managers a WYSIWYG editor to compose pages visually. The storefront renders those compositions dynamically:

1. Content managers create pages with content slots (header, body, footer, sidebar)
2. Each slot contains CMS components (banners, product carousels, text blocks, navigation)
3. The storefront fetches the page structure from the CMS API
4. Angular components render each CMS component type
5. Changes in SmartEdit show up on the storefront immediately. No deployment needed.

This CMS-driven approach is what makes the storefront “composable” in the marketing sense. Pages aren’t hardcoded templates. They’re assembled from components that marketers control. In practice, it changes how fast your team can move. I’ve seen marketing teams go from “file a Jira ticket and wait 2 weeks” to “do it yourself in 20 minutes.” That kind of shift matters.

FAQ

What’s the difference between Spartacus and the Composable Storefront?

Same product, different name. SAP renamed Spartacus to “SAP Commerce Cloud, Composable Storefront” with the 2211 release. The codebase, architecture, and features are identical. Most developers still call it Spartacus. I reckon that’ll stick for a while yet.

Can I use React instead of Angular?

Absolutely. The OCC APIs are technology-agnostic. Build a custom storefront with React, Vue, Next.js, whatever your team prefers. You lose SAP’s pre-built components, CMS integration, and SSR setup, but you gain full control. For a decision framework, see our pros and cons guide.

How does performance compare to Accelerator?

The Composable Storefront generally performs better. Headless architecture enables CDN caching, SSR improves initial load, lazy loading reduces bundle sizes. With Accelerator, server-side rendering competed for resources with business logic on Commerce Cloud’s application servers. That bottleneck is gone now.

What Angular version does the Composable Storefront use?

It tracks Angular’s release cycle, typically 1-2 versions behind the latest. Check SAP’s release notes for the specific version. Angular upgrades are managed through SAP’s continuous delivery process.

Do I need Angular expertise to customise the storefront?

Yes. No way around it. Customisation means writing Angular components, services, and modules. Your frontend team needs solid Angular, TypeScript, and RxJS experience. If your team is mostly Java-focused, plan for training or bring in frontend specialists. We’ve seen teams try to wing it without Angular expertise and it gets messy fast.