Spartacus is a composable Javascript storefront for SAP Commerce Cloud, a widely-used e-commerce solution suitable for omnichannel business ecosystems. Spartacus is developed with Angular, Google’s Typescript-based, open-source web framework. It is designed to be lightweight, customizable, and modern, with the ability to support the most recent architectural and development practices.
Spartacus makes it easy to design and deploy the necessary functionalities for an e-commerce website, such as personalized storefronts, headless capabilities, progressive web application support, SEO friendly, and multi-language and multi-site support. Its composable architecture allows for clean infrastructure design and deployment and makes it particularly suitable for multi-platform and multi-project solutions.
For this guide, we’ve teamed up with A.S. Watson, who understand the challenges that a multi-brand, multi-country ecosystem poses for e-commerce infrastructures. Our guide will look at how Spartacus can be used to leverage complex international e-commerce, gaining insights from A.S. Watson’s own integration of Spartacus into their multi-project Angular setup.
Introduction to Spartacus
Spartacus is a lean, Angular-based storefront for SAP Commerce Cloud. It was originally introduced in 2018 as part of a drive to integrate toolsets for different platforms into a single-page storefront interface. It began as an open-source project and has since been adopted as part of SAP Commerce Cloud itself.
The ABC of Spartacus
Spartacus offers a clean, composable storefront interface to accelerate and simplify SAP Commerce systems. Its single-page setup communicates with SAP Commerce using a REST API (Omni Commerce Connect). This means that user interface layers are fully decoupled from SAP Commerce, allowing flexible and secure integration without direct concern for backend components. Spartacus, being a headless storefront built on top of SAP Commerce, allows for more flexibility and agility in the frontend development, as the two can have independent release cycles. This means that frontend updates can be implemented more frequently and independently from the backend, resulting in faster innovation and a better customer experience
Spartacus is based on Angular, Google’s lean and extensible web framework. This makes it easy to start small and extend as required, to huge multi-project, multi-platform internationalised systems if desired. And Angular also provides excellent security and accessibility tools from the ground up, plus an extensive and supportive global developer community.
With a decoupled architecture, users benefit from rapid extensions and upgrades to the libraries as soon as they appear. The technology is forward-focused, aiming to offer a consistently high-quality user interface across any supported device. It aims towards full compliance with the PWA (Progressive Web Application) standards being developed by many major technology providers, including the W3C.
Spartacus provides all the core components for storefront interfaces that we’d expect such as navigation, product listing, product detail pages, shopping cart, checkout flows, and also advanced features like personalization, search and filtering, and dynamic content.
Spartacus allows integration with various PSP, such as SAP Digital Payments or any other external provider, to offer a wide range of payment options. This flexibility ensures that the e-commerce platform can adapt to the specific needs of the business and its customers. Furthermore, it includes many features for improving e-commerce interfaces, such as cart validation, product zoom, and dynamic configurations for site themes and guided-selling scenarios
What’s Spartacus good for?
By separating the user interface from SAP Commerce, Spartacus provides benefits for complex e-commerce systems. This means that core functionality can evolve independently of the shopfront interface, which can then use this functionality in various ways to meet different needs. Additional frontends can also be added to support multi-brand solutions. The modular interface allows for views to be created to meet the requirements of different languages or locations, as well as highly customized commercial specifications.
Setting up a multi-project structure
Spartacus’s decoupling and composability draw on Angular’s inherent capabilities for modularity and extensibility. In particular, this makes it ideal for multi-project workspaces. This development approach is used by enterprises that have multiple projects but need to maintain core libraries, configurations or other shared aspects of their technology ecosystem.
Enterprise development teams have various options for administering multi-project setups. The choice is reflected in the strategies they use to host and manage code using Git. Thousands of libraries, a wide range of implementations and globally-dispersed development teams can mean administrative complexity. So organised flexibility is crucial.
There are two main options for managing multi-project codebases: multi-repo and mono-repo. The multi-repo approach uses a different repository for each project or collection of libraries required for reusable components, standalone applications or microservices. This can help with defining access, autonomous working and independent release cycles. But it also leads to more fragmented projects and may ultimately require more reintegration work for complex setups.
By contrast, a mono-repo setup uses a single repository for all code. This makes it easier to navigate shared aspects of the project ecosystem, making code quicker to find and issues more straightforward to trace. Refactorings and fixes require fewer cross-repository dependency checks and collaborations face fewer interruptions.
And last but not least, Angular makes it easy to set up multi-project systems by skipping initial application generation when creating workspaces.
Integrating Spartacus: How A.S. Watson does it
With a huge international presence across thousands of stores, A.S. Watson needs to leverage complex technology to serve many different e-commerce applications. The size of operations means that a set of robust core modules is essential to ensure quality across all brand representations. But needless to say, with brands based across the globe, serving different marketplaces with multiple product ranges, the storefront interfaces may vary extensively. Seeing how A.S. Watson approaches multi-project ecosystems is a helpful guide for your own project setups.
Since 2017, A.S. Watson has used SAP Commerce Cloud for the backend of their e-commerce operations. Their multi-project infrastructure uses a mono-repo Angular setup to handle the sophisticated feature sets that drive each brand’s frontend. The setup comprises two main libraries, which contain code modules as well as commerce feature modules representing the customised multi-project configuration.
To get a clearer idea of how A.S. Watson implements this functionality, let’s take a peek inside their project structure:
- ci-script – this folder contains the build scripts for each brand implementation. They feed into the full build system, helping to streamline continuous integration.
- lib – this is the main folder that contains the libraries which have already been implemented. It also stands as a placeholder for the remaining libs which will eventually be implemented by ASW.
- mock-proxy-server – in here is a mock server used to run ASW’s Angular applications during development. This is helpful in case the API on the BE side is not yet ready for deployment.
- projects – in the projects folder, we find one folder for each of the ASW brands implemented in the system. Within this folder there is a src folder for each brand, containing the specific implementations for that BU.
Best practices with Spartacus
With A.S. Watson’s implementation as our guide, it’s worth considering some best practices for projects using Spartacus. Using best practices can boost your app’s performance and help you gain better Google Lighthouse and Core Web Vitals scores.
Use a PWA checklist
Earlier on we mentioned Spartacus’s alignment with Progressive Web App aims. You can do your bit by using a PWA checklist. For example, make sure your customisations retain universal accessibility and responsiveness. Implement caching strategies to keep speeds high and ensure that offline browsing can work seamlessly with online to keep users in your app.
Reduce resource requests
In short, only request what you need. For example, keep CSS and Javascript includes specific to each page. Don’t download full-res images if you only need thumbnails. Optimise your asynchronous HTTP requests to avoid unnecessary server calls. Also, when accessing the SAP Commerce backend through the REST API (OCC), make sure you only request the data you need for the current operation.
Use caching to improve speed
Caching frequently used assets can significantly improve your storefront’s performance. Keep an L2 cache for all scripts, images, fonts and so on that don’t change much. You can also cache OCC calls for anonymous users (which change infrequently). And don’t forget to optimise browser cache policies to boost page load times on user devices.
Consider SEO
SEO is vital if you want your storefront to succeed in a crowded marketplace. As well as top-notch content, there are a few technical steps you can take to improve your site’s discoverability. Server-side rendering will help to make sure your pages are properly indexed. Make sure you include a valid robots.txt to allow robots to crawl your site. And check that your meta-tags are present and correct across all your pages.
Conclusions
In this article, we’ve taken A.S. Watson’s global technological operations as our guide. We outlined how Spartacus and Angular are perfectly suited to developing and maintaining complex multi-site ecosystems. A lean approach, combined with composable architecture makes it much easier to implement modular customisations with core common functionality, allowing the multi-project, multi-brand systems required by major global operations.
