Reason #1 – Decoupled Architecture

The SAP Commerce Cloud REST APIs (link) have improved to be fully compliant with any JavaScript storefront technology, allowing you to completely separate front-end and back-end development.

Since front-end technology frameworks have grown quickly in the last decade, working with jQuery is no longer enough. Front-end developers are expecting to be able to use one of the major Javascript (JS) frameworks, such as Angular, React, or Vue.js.

The gap between front-end and back-end technologies has expanded. These days, you should not expect the same developer to have all the skills required to develop efficiently for both aspects of your solution. You probably want to separate concerns into different teams, to allow you to increase productivity and scalability.

With a decoupled architecture, the teams can work independently within their own release cycles. For example, you may need to do many cosmetic changes on the UI that you would like to develop, test, and deploy in production on the same day. You would be able to achieve this easily with a lightweight solution such as Spartacus connected to SAP Commerce Cloud back-end by REST services.

Reason #2 – Open Source

Spartacus was developed by the same team that works on SAP Commerce Cloud, but the product has been released with an open source license. You will benefit from all the development effort invested by the Project Spartacus development team without any new investment required by your team.

By being open source, it should also provide larger access to the SAP Commerce Cloud ecosystem, digital agencies, and those who may not be official SAP partners. With easy access to the code to explore, test, and modify a storefront, you can develop quicker. The open source project is run using an agile model, which allows for quick releases and rapid changes (goal: releases every two weeks). At the same time, you have the flexibility to configure your setup to automatically pull in the new releases or you can set up to maintain a particular version of the libraries.

Although SAP manages the open source project, SAP is keen to welcome contributors and to foster an inclusive, active development community. It means customers and partners have direct access to the Spartacus team, can influence prioritization of new features, and can post questions to developers, product owners and architects on our Slack workspace or on Stack Overflow with the ‘spartacus’ tag. See here for more on contributing to the project.

Reason #3 – Upgradable and Extensible

Since it’s 1.0 release in June 2019, Spartacus aims to ensure most of the pages and components achieve feature parity with the SAP Commerce Cloud, B2C accelerator and the SAP Commerce Cloud, B2B accelerator (see Roadmap to understand which features may still be missing).

Of course, you are free to add your own components or design new ones. By design, Spartacus is modular and extensible, so you can continuously upgrade and benefit from the latest version of components.

Spartacus is packaged as a set of Angular libraries, so when new feature or fixes are introduced, you can take advantage of them right away. We do not recommend you fork the Spartacus project or copy/paste the source code when you want to build a new storefront.  Instead, you should create a new Angular App and add dependencies to the Spartacus libraries. Patch and minor release of Spartacus should not break compatibility. As long as there isn’t a major release (for example, 2.0, 3.0), upgrading to the new libraries should not cause any issues with your storefront app.

Reason #4 – CMS-Driven

Content for Spartacus pages is fetched from the SAP Commerce Content Management System (CMS) so Content Managers can modify page content through the SAP Commerce Cloud CMS tools, like SmartEdit. SmartEdit is fully supported and combined with Project Spartacus to provide relevant and personalized experiences, including a preview of the site as it will appear to customers later on.

In theory, you could even use Spartacus and SAP Commerce Cloud with a third-party CMS. If you have implemented this or a similar scenario, we would love for you to share your results with the Spartacus community.

Reason #5 – Supported by SAP Commerce Cloud Automation

From within the SAP Commerce Cloud Portal, you can deploy your Project Spartacus storefront onto the public cloud infrastructure. The build automation that comes standard with SAP Commerce Cloud in the Public Cloud supports the deployment of JavaScript storefront, which can be built independently from the SAP Commerce Cloud solution and deployed on dedicated nodes (link to product documentation).

In addition, SAP Commerce Cloud supports Server Side Rendering (SSR), so web crawlers can actively browse your website. Please see this page for more on how to enable it for your application.