SAP Spartacus is getting visibility and good vibes among developers and agencies. However, starting the Spartacus project, especially in an upgrade/migration situation, can be difficult.
The problem is in the need to upgrade the whole tech stack including the Hybris back end. In this situation, the companies that have large-scale hybrid deployments often choose to go with the legacy, accelerator-based storefront to “speed things up.” When we dig a little deeper to try and figure out why, we quickly realize that starting with the accelerator when there’s a Spartacus alternative is a short-term game. This is because the accelerators themselves have become the main obstacle for the upgrades.
Copy, customize, deploy? Never again.
When I talked with Tobias Ouwejan, SAP Architect in charge of Spartacus, he pointed out that one of the most important, if not the most important, problem Spartacus solves is the upgradeability issue of accelerators.
The accelerator-based front ends are usually a mix of the accelerator codebase that is extended and customized. This combination makes the eShop application very difficult to upgrade because of the need for the manual merging of the changes in the accelerator base. Whenever the back end requires some front end changes, even if they’re applied to the accelerator itself, they still need to be applied to the customized site your team created. It can literally take months to upgrade and do all the necessary QA.
What’s worth mentioning, though, is that the accelerators SAP provides are dedicated to different industries like telco, b2b, b2c, etc.. Spartacus is not there yet. However, with the new releases, B2B features will be available very soon.
The most important difference is that Spartacus is distributed as an npm package/library. The upgrade itself is like one or two command line calls. The library is very coherent and backward compatible, so the upgrades are mostly seamless and safe because the interfaces are stable.
If you go without Spartacus and would like to make use of it at any point in the future, you’ll face the need to rewrite the whole front end from scratch anyway. Using the accelerator? It’s not a time saver. It’s fast food that solves the problem every now and then but generates a more complex problem for the future.
The Spartacus architecture is designed with upgradability principles incorporated into the core. Source: https://www.sap.com/cxworks/article/435949087/choosing_which_storefront_to_use_for_your_sap_commerce_cloud_solution
Since development resources and talents are now the most valuable assets and are required for any digital transformation project, the tech stack means way more than just a bunch of fancy buzzwords and languages. It makes a real difference in being able to hire and motivate your dev team. The unified tech stack concept is gaining traction. One of its core values is that the dev team can focus on a single, JS-based stack. This improves team productivity a lot.
The Spartacus tech stack is based on RxJS, Angular, and TypeScript. It requires a lot of unit tests, automated tests, and security tests. It’s a pleasure to work with the framework.
With accelerator-based solutions, you need to somehow find JSP and jQuery developers. It’s not in the requirements, but it’s very often the case. Currently, front-end developers are not used to working with this stack. Back-end Java developers, on the other hand, are more willing to improve the APIs than to write the CSS code.
The problem is real, and looking forward to a few years from now, you should use the most modern tech stack you can afford because it will become a legacy stack in five or six years anyway. You’ll be able to see the accelerators in the museum of technology at that point ;)
Because Spartacus is distributed as a library and it’s a set of independent components, it’s fairly easy to add new features because the interference is stable.
The accelerators are not the first to get the new feature releases.
Because it’s way easier to upgrade, the SAP team makes the most out of the agile development process. According to SAP:
“Spartacus is intended to be the strategic way for creating storefronts with SAP Commerce Cloud. The intention is to have releases of Spartacus every 2 weeks. You should ensure you have checked the Spartacus Roadmap to confirm whether or not a feature from the B2C or B2B accelerator exists.
It is supported by SmartEdit to ensure business users can modify page templates while also leaving developers many options to extend and customize the storefronts to meet requirements. As an open-source project, you will be able to pull down the latest changes at any time and incorporate them into your solution.”Source
Spartacus is open source. The security patches, upgrades, and new features, including community contributions, may land in the software repository way quicker than with the legacy release cycle:
“Because the accelerators and Spartacus JS Storefront are built on completely different technology stacks, there will not be a migration tool. A full rewrite will be necessary. If you are just starting a project and Spartacus offers the features you need, the recommendation is to start with a Spartacus-based storefront. If there are features missing in Spartacus that are available in the accelerator then you should evaluate the tradeoff. If you decide to move forward with an accelerator-based storefront we recommend minimizing the time you spend on customizing the storefront and have plans to create a Spartacus storefront in the future.”Source
Spartacus is the new standard
SAP CX didn’t invest a lot into a new product to keep it hidden from the world. As the company stated: