Talking to clients and watching discussions on the internet about various front ends, I regularly encounter opinions about SAP composable storefront that are fundamentally wrong. They’re usually based on outdated images of older versions of Spartacus or stereotypes that have little to do with what the modern SAP composable storefront really is. Here are the top seven myths that fly around SAP composable storefront, formerly known as Spartacus.
Myth #1: You have to be in the cloud
The first one says that you have to have your SAP Commerce instance in the CCv2 cloud. I’ve seen some merchants deferring migration to Spartacus because they thought that they have to migrate their current Hybris instance to cloud-first. The problem is that this approach makes the migration process even harder. Migrating to Spartacus first makes your commerce solution headless. And headless architecture is easier to migrate to the cloud.
Where does this myth come from? Since version 5.0, Spartacus has become an official SAP product, and the distribution channel has changed from open npmjs to SAP’s RBSC that’s available only for cloud customers. However, Spartacus is open source and available on GitHub, and you can still use it. You just have to compile the code yourself. I show how simple it is in one of my recent videos.
Myth #2: You can’t use it with a third-party CMS
SAP composable storefront is driven by a content management system (CMS), and the out-of-the-box CMS in SAP Commerce is WCMS or SmartEdit. So, the composable storefront has out-of-the-box integration with it. However, this doesn’t mean it can’t integrate with other CMSs.
Spartacus was built in a way that it’s fairly easy to connect it to any other system. I’ve seen working integrations with Optimizely, Contentstack, Storyblok, and Amplience. What’s more, Bloomreach, Magnolia CMS, and Contentful have released their connectors for Spartacus.
This myth probably comes from the fact that SAP doesn’t provide any out-of-the-box connector to other systems. But there’s a good reason why they don’t. SAP Commerce WCMS has a strictly defined data structure while other CMS solutions are more flexible in shaping your data model. As a result, you need to decide on your own how your data should be represented on the front end, and that’s exactly what creating a connector is all about. Composable storefront architecture makes it simple.
SAP composable storefront can connect to any CMS system.
Myth #3: It’s not really composable
I think that this one was already demystified in the previous point, so I’ll focus more on the source of this myth. The first version of Spartacus was kind of monolithic, and this allowed the team to deliver a full-featured, stable storefront in a relatively short time. Fortunately, the team had the composability in mind from the start, so the monolith was meant to be decomposed later. That’s what happened and is happening with every new version.
At the time of writing this, Spartacus consists of more than 20 packages that you can opt in or opt out of based on your project needs. What’s more, each package consists of modules that you can import selectively into your project to give you greater flexibility on what you want to use in your implementation.
Spartacus composable architecture
Myth #4: It causes vendor lock
“Composable storefront is a lean, Angular-based JavaScript storefront for SAP Commerce Cloud. Composable storefront talks to SAP Commerce Cloud exclusively through the Commerce REST API.”
This is unfortunate wording that can be easily misinterpreted as “composable storefront talks exclusively to SAP Commerce Cloud.” But the right meaning is that it communicates with SAP Commerce Cloud only via REST API. For less technical readers, this means that the storefront communicates with the commerce engine via standard and popular interfaces, so either one can be replaced with something else that also uses that interface.
In other words, if for whatever reason you decide to change your commerce engine from SAP Commerce to something else, then Spartacus allows you to do so. Of course, it won’t be plug-and-play, and you’ll have to provide your own connectors, but it’s rather straightforward. The cost of it is marginal compared to the cost of the commerce engine migration.
Spartacus talks to SAP Commerce via REST API
Myth #5: You are forced to use Bootstrap for styling
Spartacus comes with a styles library that is based on Bootstrap. That library allows you to selectively opt out of styles for specific components and page sections. Additionally, as with any other Spartacus library, you can completely remove it and provide your own styles for the entire storefront. There are people who wish that composable storefront provided some basic styling in other CSS frameworks, and I can tell you that the Spartacus team has such a feature in their backlog.
Myth #6: It’s slow
First of all, we need to define what “slow” means. It can mean that a web application is slow to start (load performance) or it reacts slowly to the users' actions (runtime performance). Load performance is often represented by the Lighthouse score or core web vitals.
The runtime performance of Spartacus is good and much better than in accelerator-based storefronts. The myth refers to load performance. That’s because if you run the Lighthouse test on a fresh installation of Spartacus on your local machine, it will throw an alarm and glow in red. But that’s not a real-life measure. You have to do a proper setup and think about where you want to deploy your application and optimize for that. Long ago, I wrote more on this topic.
With our team, we’ve created a Spartacus demo that gets the green score in Google Lighthouse. This proves that a composable storefront doesn’t have to be slow.
Myth #7: It has poor developer experience
This myth comes from two false assumptions that people have when approaching Spartacus.
Number one: “Angular is bad.” It has a bad reputation. Every year, I see new blog posts announcing its sudden death, but it still hasn’t happened, and recently, the Angular team has put a lot of effort into modernizing it.
I’m not going to get into the fight between React, Vue, and Angular because I’m technology agnostic, and I see value in each of these tools. I guess the problem is that Angular is significantly different than the other two, and many people approach it with prejudice. There are some features of Angular that made it the right choice for Spartacus, but this deserves a separate article. What makes me sad is that people approach Spartacus without learning Angular first. No wonder that Spartacus has a poor developer experience for Vue or React developers who don’t know Angular.
Number two: “Spartacus is just a library.” In fact, it’s more of a framework so you don’t simply install it and use it before learning it. You have to make some effort first to understand how to work with it. In return, you get better productivity, you don’t have to reinvent the wheel, and you can make tough architectural decisions yourself. What’s Spartacus's biggest asset regarding developer experience is its source code. It’s open source and well written. It’s easy to read, and by doing so, developers can learn a lot about how to use Spartacus and what the best practices are.
Moving beyond the myths
The myths above prove that there are a lot of misconceptions about what SAP composable storefront or Spartacus really is. The code itself isn’t always sufficient to dismantle them because it requires a lot of effort to really immerse yourself in it.
If you want to move beyond the myths and explore the first-hand truth about SAP composable storefront, you can start with our eBook library and a discord server where you can get help from the community.
Published August 22, 2023
