Introduction
As commerce landscapes evolve toward composability, frontend architectures must deliver speed, modularity, resilience, and seamless integration with enterprise ecosystems.
SAP Composable Storefront, built on Angular and powered by OCC APIs, offers a modern, headless, and flexible foundation for B2B/B2C experiences — but building it for production requires deliberate architectural choices and strong engineering discipline.
In this blog, I provide a practical and deeply technical blueprint for designing, implementing, and running a production-ready SAP Composable Storefront application. Whether you’re an architect, senior engineer, or SAP Commerce integrator, these guidelines will help you scale efficiently, avoid common pitfalls, and achieve high performance on the edge.
1. Architectural Overview
SAP Composable Storefront is essentially an Angular application composed from Spartacus libraries with custom modules layered on top. It communicates with SAP Commerce Cloud via:
OCC REST APIs (product, cart, checkout, CMS)
Third-party services (identity, search, payments, analytics)
Edge/CDN layers (for caching & performance)
High-Level Flow
User request hits the CDN. If an SSR HTML page is cached → return instantly.
If not cached, request is forwarded to the SSR Node server pool.
Once delivered, the Angular client hydrates and fetches additional data from Commerce APIs.
Connectors, adapters, and interceptors handle mapping, authentication, and context (site/catalog/currency).
Design Goals
Modular, maintainable features
Clean separation of concerns
Efficient API mapping & error handling
Strong observability and operational readiness
High performance on edge delivery
2. Project Setup & Recommended Foundation
A solid foundation begins with the right scaffolding. The recommended project initialization:
ng new my-storefront –routing –style=scss
cd my-storefront
ng add /schematics –ssr
After running Spartacus schematics:
Configure environment.ts with occBaseUrl, site, and API prefix
Validate Commerce Cloud compatibility matrix
Choose feature libraries (B2B, Wishlists, CDS, CDC, etc.)
Establish a multi-env config strategy: dev / staging / prod / SSR / preview
3. Folder Structure & Module Strategy
A clean folder structure is critical for scalability in large storefront implementations.
src/
app/
core/ → interceptors, guards, root services
shared/ → UI components, directives, pipes
features/ → cart, product, checkout, account, etc.
config/ → all Spartacus + application configs
styles/ → SCSS tokens, global mixins, theming
server/ → Angular Universal SSR code
assets/ → images, i18n, icons
Core Principles
CoreModule contains all singletons.
SharedModule contains pure components, no business logic.
Feature Modules are route-based and lazily loaded.
Config Modules centralize Spartacus and custom configurations.
This organization prevents module bloat and ensures low coupling.
4. Theming, Styling & Asset Strategy
Use SCSS with centralized variables/tokens (_tokens.scss)
Prefer BEM methodology for predictable styling
Keep global styles minimal
Host large asset bundles on a CDN in production
Use WebP and responsive image sets for performance
Avoid overriding Spartacus styles excessively — extend, don’t fork
5. Data Flow: Connectors, Adapters & Mappers
SAP Composable Storefront’s architecture encourages clean data handling:
Best Practices
Keep raw OCC models in adapters
Map OCC → UI-friendly models in dedicated mappers
Use HTTP interceptors for:
Auth token injection
Site/tenant context headers
Request correlation IDs
Keep services thin; let adapters handle network concerns
Implement custom endpoints using Spartacus’ OccConfig extension approach
This ensures maintainability through upgrades and avoids code duplication.
6. State Management & RxJS Best Practices
Spartacus already ships with internal NgRx stores; custom state can extend it cleanly.
Guidelines
Prefer async pipes instead of manual subscription/unsubscription
Use OnPush change detection for all components
Apply correct RxJS operators:
switchMap → dependent API calls
exhaustMap → checkout flow steps
combineLatest → merged UI streams
Keep state local wherever possible — global store only when necessary
7. Server-Side Rendering (SSR) & Pre-Rendering
SSR is essential for SEO and for first-load performance of SAP storefronts.
Key SSR Considerations
Leverage Angular Universal for rendering
Pre-render static routes (homepage, category pages)
Implement fast fallback for SSR server failures
Always guard DOM access using:
if (isPlatformBrowser(this.platformId)) {
// browser-only logic
}
Scaling SSR
Deploy SSR nodes behind a load balancer
Use horizontal autoscaling based on CPU/memory
Cache SSR HTML aggressively at the CDN
8. Performance, Caching & CDN Strategy
Recommendations
Use long cache TTLs with content-hashed asset filenames
Enable API-level caching for read-only endpoints (CMS, product, categories)
Implement lazy loading & route-based code splitting
Consider image optimization and responsive formats
Cache SSR output at CDN for key pages
Monitor TTFB and Core Web Vitals continuously
This significantly reduces backend loads and improves Lighthouse scores.
9. Security Considerations
Enforce HTTPS everywhere
Apply Content Security Policy (CSP) headers
Use HttpOnly cookies for tokens when possible
Sanitize CMS-driven HTML
Rate-limit OCC endpoints at the gateway layer
Avoid leaking internal config via environment files
Security must be treated as a continuous practice, not a one-time setup.
10. Testing Strategy
Layers of Testing
Unit tests → Services, components, mappers
Integration tests → Using Cypress or Playwright
Visual regression tests → Percy or Playwright snapshots
Contract tests → Pact against OCC
API mocks for local development
A mature storefront requires confidence across all layers.
11. CI/CD & Deployment Patterns
A modern pipeline should include:
Linting
Unit tests
Build (client + server bundles)
Integration/E2E tests
Deploy to staging
Canary/Blue-Green deployment
Final production release
Infrastructure Guidance
SSR Nodes deployed in Kubernetes
Zero-downtime rolling updates
Automatic CDN cache invalidation on release
Tight integration with observability stack
12. Monitoring & Operational Runbook
Monitoring Stack
Error tracking (Sentry / Dynatrace / Kibana)
Node SSR logs with correlation IDs
Alerts for:
Memory pressure
5xx spikes
Slow OCC endpoints
CDN cache miss patterns
Runbook Should Include
How to disable SSR in emergencies
Cache purge strategy
Rollback instructions
Recovering from Commerce outages
This ensures stable operations even under stress.
13. Extensibility, Upgrades & Governance
To keep the storefront healthy long-term:
Never fork Spartacus libraries
Maintain compatibility matrix with Commerce & Spartacus versions
Use linting + Angular style guide
Treat every new feature as an isolated module
Have a structured upgrade plan for both Angular & Spartacus versions
Good governance reduces technical debt dramatically.
Conclusion
Building a production-ready SAP Composable Storefront requires more than installing Spartacus libraries — it demands a carefully crafted architecture, operational excellence, and adherence to enterprise-grade engineering standards.
By following the patterns outlined above, teams can deliver storefronts that are:
Performant
Composable
Upgrade-friendly
Highly maintainable
Secure
Ready for enterprise scale
This blueprint aligns with SAP’s recommended best practices and equips teams to deliver future-proof digital commerce experiences.
IntroductionAs commerce landscapes evolve toward composability, frontend architectures must deliver speed, modularity, resilience, and seamless integration with enterprise ecosystems.SAP Composable Storefront, built on Angular and powered by OCC APIs, offers a modern, headless, and flexible foundation for B2B/B2C experiences — but building it for production requires deliberate architectural choices and strong engineering discipline.In this blog, I provide a practical and deeply technical blueprint for designing, implementing, and running a production-ready SAP Composable Storefront application. Whether you’re an architect, senior engineer, or SAP Commerce integrator, these guidelines will help you scale efficiently, avoid common pitfalls, and achieve high performance on the edge.1. Architectural OverviewSAP Composable Storefront is essentially an Angular application composed from Spartacus libraries with custom modules layered on top. It communicates with SAP Commerce Cloud via:OCC REST APIs (product, cart, checkout, CMS)Third-party services (identity, search, payments, analytics)Edge/CDN layers (for caching & performance)High-Level FlowUser request hits the CDN. If an SSR HTML page is cached → return instantly.If not cached, request is forwarded to the SSR Node server pool.Once delivered, the Angular client hydrates and fetches additional data from Commerce APIs.Connectors, adapters, and interceptors handle mapping, authentication, and context (site/catalog/currency).Design GoalsModular, maintainable featuresClean separation of concernsEfficient API mapping & error handlingStrong observability and operational readinessHigh performance on edge delivery2. Project Setup & Recommended FoundationA solid foundation begins with the right scaffolding. The recommended project initialization:ng new my-storefront –routing –style=scss
cd my-storefront
ng add /schematics –ssrAfter running Spartacus schematics:Configure environment.ts with occBaseUrl, site, and API prefixValidate Commerce Cloud compatibility matrixChoose feature libraries (B2B, Wishlists, CDS, CDC, etc.)Establish a multi-env config strategy: dev / staging / prod / SSR / preview3. Folder Structure & Module StrategyA clean folder structure is critical for scalability in large storefront implementations.src/
app/
core/ → interceptors, guards, root services
shared/ → UI components, directives, pipes
features/ → cart, product, checkout, account, etc.
config/ → all Spartacus + application configs
styles/ → SCSS tokens, global mixins, theming
server/ → Angular Universal SSR code
assets/ → images, i18n, iconsCore PrinciplesCoreModule contains all singletons.SharedModule contains pure components, no business logic.Feature Modules are route-based and lazily loaded.Config Modules centralize Spartacus and custom configurations.This organization prevents module bloat and ensures low coupling.4. Theming, Styling & Asset StrategyUse SCSS with centralized variables/tokens (_tokens.scss)Prefer BEM methodology for predictable stylingKeep global styles minimalHost large asset bundles on a CDN in productionUse WebP and responsive image sets for performanceAvoid overriding Spartacus styles excessively — extend, don’t fork5. Data Flow: Connectors, Adapters & MappersSAP Composable Storefront’s architecture encourages clean data handling:Best PracticesKeep raw OCC models in adaptersMap OCC → UI-friendly models in dedicated mappersUse HTTP interceptors for:Auth token injectionSite/tenant context headersRequest correlation IDsKeep services thin; let adapters handle network concernsImplement custom endpoints using Spartacus’ OccConfig extension approachThis ensures maintainability through upgrades and avoids code duplication.6. State Management & RxJS Best PracticesSpartacus already ships with internal NgRx stores; custom state can extend it cleanly.GuidelinesPrefer async pipes instead of manual subscription/unsubscriptionUse OnPush change detection for all componentsApply correct RxJS operators:switchMap → dependent API callsexhaustMap → checkout flow stepscombineLatest → merged UI streamsKeep state local wherever possible — global store only when necessary7. Server-Side Rendering (SSR) & Pre-RenderingSSR is essential for SEO and for first-load performance of SAP storefronts.Key SSR ConsiderationsLeverage Angular Universal for renderingPre-render static routes (homepage, category pages)Implement fast fallback for SSR server failuresAlways guard DOM access using:if (isPlatformBrowser(this.platformId)) {
// browser-only logic
}Scaling SSRDeploy SSR nodes behind a load balancerUse horizontal autoscaling based on CPU/memoryCache SSR HTML aggressively at the CDN8. Performance, Caching & CDN StrategyRecommendationsUse long cache TTLs with content-hashed asset filenamesEnable API-level caching for read-only endpoints (CMS, product, categories)Implement lazy loading & route-based code splittingConsider image optimization and responsive formatsCache SSR output at CDN for key pagesMonitor TTFB and Core Web Vitals continuouslyThis significantly reduces backend loads and improves Lighthouse scores.9. Security ConsiderationsEnforce HTTPS everywhereApply Content Security Policy (CSP) headersUse HttpOnly cookies for tokens when possibleSanitize CMS-driven HTMLRate-limit OCC endpoints at the gateway layerAvoid leaking internal config via environment filesSecurity must be treated as a continuous practice, not a one-time setup.10. Testing StrategyLayers of TestingUnit tests → Services, components, mappersIntegration tests → Using Cypress or PlaywrightVisual regression tests → Percy or Playwright snapshotsContract tests → Pact against OCCAPI mocks for local developmentA mature storefront requires confidence across all layers.11. CI/CD & Deployment PatternsA modern pipeline should include:LintingUnit testsBuild (client + server bundles)Integration/E2E testsDeploy to stagingCanary/Blue-Green deploymentFinal production releaseInfrastructure GuidanceSSR Nodes deployed in KubernetesZero-downtime rolling updatesAutomatic CDN cache invalidation on releaseTight integration with observability stack12. Monitoring & Operational RunbookMonitoring StackError tracking (Sentry / Dynatrace / Kibana)Node SSR logs with correlation IDsAlerts for:Memory pressure5xx spikesSlow OCC endpointsCDN cache miss patternsRunbook Should IncludeHow to disable SSR in emergenciesCache purge strategyRollback instructionsRecovering from Commerce outagesThis ensures stable operations even under stress.13. Extensibility, Upgrades & GovernanceTo keep the storefront healthy long-term:Never fork Spartacus librariesMaintain compatibility matrix with Commerce & Spartacus versionsUse linting + Angular style guideTreat every new feature as an isolated moduleHave a structured upgrade plan for both Angular & Spartacus versionsGood governance reduces technical debt dramatically.ConclusionBuilding a production-ready SAP Composable Storefront requires more than installing Spartacus libraries — it demands a carefully crafted architecture, operational excellence, and adherence to enterprise-grade engineering standards.By following the patterns outlined above, teams can deliver storefronts that are:PerformantComposableUpgrade-friendlyHighly maintainableSecureReady for enterprise scaleThis blueprint aligns with SAP’s recommended best practices and equips teams to deliver future-proof digital commerce experiences. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
