Introduction
Hello, my name is Artem.
I have been working in the web development industry for about 10 years. During my career, I have worked with different technologies, mostly with Angular web framework, React and Vue.js. However, for about two years I’ve worked as a Full-Stack developer using server-side platforms like Node.js and Python, databases like PostgreSQL, MongoDB, some graph databases, etc.
💡Marketing Explanation of “Digital agency” are strategic and creative marketing agencies focused on user experience, mobile, social, data gathering and analytics apart from providing creative services and promotional offerings (supported by analytics and optimization of the promotional mix). Once dominated by communications and promotional activities, digital agencies today help explore new sources of growth, including market diversification and product ideation and development.
I’ve been working in a large digital agency that decided to use SAP Commerce Platform as a tool for developing the business with its clients. We have been working for more than a year in a distributed team of qualified professionals.
💡The entire SAP Commerce platform consists of three main modules:
1. SAP Spartacus
2. SAP Cloud
3. SAP Hybris
Apart from them, there is also SAP Backoffice for working with data and mapping cms-components, SAP Smartedit for editing page templates and several other less significant modules.
SAP Reality
In the beginning, our team was introduced that we will be working with the unified web-store development platform SAP Commerce. And my team had to work with the UI part which is called SAP Spartacus and has built entirely on Angular 12+.
Why SAP Spartacus is bad
Next, I went through the basic requirements of a project to understand how I would actually build my code over this platform, there was the first problem.
💡 Those people who have some experience with Angular know, that it is a web framework that was created with the OOP paradigm in mind.
Spartacus code was poorly prepared to be extended:
Most of the class methods had the private modifier. Many services had private methods with crucial logic which cannot be extended. And in the exported components their dependencies were injected through the private modifiers too! Besides all of that the platform was in fact a monolith and had common state management layer, implemented through the popular library NgRx.
Almost all the code responsible for the state of the application was non-extensible. Except for a few entities, all selectors, actions, reducers, and stores were not exportable and could not be modified in the client code. This meant writing custom solutions, which mostly had to duplicate the existing closed source code with only minor modifications to suit the needs of the project.
🤬 Basically when it needs to modify something more than it’s intended by SAP developers, You have to clone existing code, because there is no other way to do this.
Yes, there is a way in Angular how to override existing module dependencies with custom ones by using providers (in most cases we were using class providers), but still, you have to copy the original class code and extend it or write a completely new class to modify its logic for your needs.
The even worse situation with the state layer, there are few entities exported and no way how you can easily override existing parts with a customized one. Instead, you have to write your own (actions, reducers, selectors) and augment related services accordingly to make them use your custom code. This is extremely time-consuming.
🤬 What exactly the SAP developers were thinking about when they created this kind of “modifiable platform” I can only guess. But they obviously weren’t thinking about the people who will be working with it.
Why SAP Hybris is even worse
Besides Spartacus itself, which is the client platform, there is also a server part called Hybris.
Hybris is a SAP Commerce server, written in Java, using ant and maven libraries, connecting to DBMSs like Solr, MySQL/MsSQL and Oracle. Hybris also uses Docker to build this entire solution and run the database. The configuration is done through an XML file describing the startup process.
🤬 Any manipulations with Hybris wherever in Cloud or on local (especially on local) caused extreme frustration to all the developers who were lucky enough to work with it.
The official SAP Commerce page describes in the system requirements section that Hybris can be started with a 2-core processor and 8 GB of RAM, which is totally not true.
In fact, up to 14GB of physical RAM is used during startup and initialization of Hybris with a small data set and all 8 processor threads are loaded on the Ryzen 5600. After initialization, the amount of consumed memory drops to 7–8GB, and CPU resource consumption also drops to reasonable values, but it is obvious that all these values are much higher than those specified in the official recommendations.
💡By the way, the developers of 🎮 video games industry 🎮 like to do the same, for example, to sell their products to as many users as possible, and the fact that someone does not run something does not bother them much. Sometimes even in early access!
But even after this initial run, it becomes very difficult to work with running Hybris, because of the constant lack of processing power of the machines given to us by our e-commerce company Hybris becomes very unstable and can stop work at any time. And if the developer has running IDE then every more or less serious manipulation of the project code turns into the torture of waiting.
😂 After some time our team been working with this software these two words stood side by side very often in our informal conversations: “hybris” and “sh*t”
Any configuration change can cause startup or initialization errors, which do not have any structure or codes to communicate with the documentation. Due to its closed nature, understanding the inner processes of operation is extremely difficult, even for experienced backend developers.
The deployment process is extremely slow (up to 2 hours for 200Mb data), unstable and can not be interrupted, also snapshots and backups are not supported. Everything is done practically live. Hybris can only be deployed in the SAP Cloud and cannot be replaced by a local server with its own settings. Because of the extremely complex deployment process, backend developers have to spend a lot of time monitoring and debugging. The solution is monolithic, which means that any small error in any part of it will break entirely.
SAP Cloud + Hybris
💡SAP Cloud has mostly been used with Hybris Commerce and Spartacus solution at one piece.
The whole thing had to be tested somehow. The SAP Platform is surprisingly inflexible. To run the solution, you have to deploy the project through some custom CI/CD pipeline which is located in a service called SAP Cloud.
It’s not enough to just build the project on a local machine to test it, you need to test it exclusively in SAP Cloud, which builds the project in its own special unmodifiable way. The entire pipeline doesn’t have any configurable script, all you can do is only set the entry points which are the project names of your monorepo.
Despite the fact it’s built with Docker, you have no ability to create custom containers or even modify the existing ones inside the Hybris.
Kubernetes and its configuration are supported, but not for SAP Commerce Hybris. Hybris has to be configured via its own custom config file and gives a very limited amount of options to configure.
There are no Virtual Machines for testing, to be able to create a snapshot of the working state. Backup options are very limited and related only to DBs.
🤬 Working without the ability to create backups or properly configure the deployment process — what kind of “solution” is that?
Everything about deploying a project is closed. The only thing that can be changed is the Git branch and the name of the build, after that you have to click the start button and hope that at the end there won’t be a “Build failed” message.
Conclusion
Yes, it’s possible to write a complete custom backend and frontend, and put it in the SAP Cloud. But why you would do so if there are already more convenient and proven industry standards like Google Cloud, AWS, Azure, etc.?
Maybe only if you have some kind of financial agreement with SAP. Otherwise, there is no point in using such a heavy, closed and poorly configurable solution as SAP Commerce.
