I have been working with Magento since 2012. At that time, it was already relatively established with version 1.7. and enjoyed great popularity in German-speaking countries. However, after a large number of projects with Magento 1 & 2, I have now swapped the "Magento world" for Spryker. I would like to tell you here how this came about.
Magento vs. Spryker - the origins
The development of Magento dates back to spring 2007. Back then, a small company called Varien from Los Angeles was working on a customised shop system that would be both more stable and more flexible than the existing solutions on the market. Within a few years, Magento became one of the most popular e-commerce systems for SMEs and large companies. After Varien was sold several times, it was finally acquired by Adobe and integrated into the Adobe Experience Cloud.
Seven years later, the foundation stone for one of the most innovative e-commerce technologies on the market was laid with the founding of Spryker Systems. Spryker's approach can be described with a high-tech lego box and is now one of the fastest growing companies in terms of customer and revenue growth. Spryker has been listed as a "Visionary" in Gartner's "Magic Quadrant for Digital Commerce" for several years and is recognised for its agility and flexibility.
Similarities
Both systems pursue more or less the same business goal - products or services should be able to be ordered and paid for online by a customer.
Both Magento 2 and Spryker are built using the PHP programming language and store their data in a relational database - the source code can be viewed. Elasticsearch is used for the search in both systems and APIs are provided in one form or another.
Code quality: Magic vs. clean code
Magento 2 was ultimately developed from scratch and only shares one or two concepts with its predecessor. This new development, which was started back in 2011, was initially very slow and only picked up speed again with the takeover by Permira. It was finally published in 2017.
Various decisions that were made back then were certainly justified at the time - but from today's perspective, they can certainly be described as "technical debt".
For example, the now seemingly antiquated JavaScript framework "KnockoutJS" has always been in use, which at best leads to head shaking, but in most cases to frustration. In the meantime, there are at least third-party providers such as Hyva, who have brought the frontend up to date and are competing with the slogan "We fixed the Magento Frontend".
Both Magento and Spryker work with a modular approach. The aim should be to utilise the features that are relevant for the respective project. While Spryker strictly follows this separation of the individual modules and you decide for yourself what you want to use, this is a little more difficult with Magento. Modules such as customer ratings or certain product types are included from the outset and can only be removed or cancelled with great effort.
Magento also comes with a wealth of bloatware as standard. Third-party providers such as Amazon, Paypal, Klarna or Vertex are included in every installation from the outset - regardless of whether the services are used and required. This not only leads to a larger code base and unnecessarily increased complexity, but also to potential security vulnerabilities. With Spryker, on the other hand, you have the freedom to choose which code is installed and used. Modules can be added or removed at any time as required.
Spryker is clearly orientated towards the "SOLID Principles" and the "Separation of Concerns". This leads to a clear structure on the one hand and a clearly understandable and clean code base on the other. However, such principles are lacking in the Magento world, which means that the quality varies depending on the module used.
In my opinion, however, one of the biggest distinguishing features of Spryker is the "ahead-of-time" generation of source code. This process not only makes debugging easier - it also leads to more comprehensible and, above all, more readable code.
For example, transfer objects are used for communication within the modules as well as for data exchange between the front end (Yves) and the back end (Zed). These objects are simple data containers that are described using XML and then generated via the command line. By using these transfer objects, a clear separation is made between the available data and the business logic.
Traditional monolith vs packaged business capabilities
With the increasing popularity and implementation of agile processes - both on the client and agency side - more and more demands are being placed on the systems used. Speed, flexibility and the ability to adapt to new market conditions are top priorities.
Magento has always been built on a monolithic architecture. This means that the entire logic - from the back office and interaction with the database to the output for the customer - is summarised in a large code base.
This sometimes means that changes in one area can lead to undesirable side effects at the other end of the system. A clean separation of the business logic and the presentation for the end customer is sometimes very difficult to achieve. This also makes it difficult to diversify the development team according to specialisation.
Spryker, on the other hand, follows the "Packaged Business Capabilities" approach. As the name suggests, individual "business packages" are divided into different services that work independently of each other and communicate with each other via interfaces. This not only simplifies and accelerates the implementation of requirements - it also gives the customer and the development team the opportunity to implement new ideas more quickly and discard them again if necessary.
Workflow - Spaghetti vs State Machine
One of the biggest challenges in e-commerce is the mapping and implementation of business processes in the IT infrastructure. What can still be easily implemented in a simple B2C business model becomes a real challenge with more complex business processes in the B2B sector.
One example of this is the processing of an order. Depending on the products ordered, the desired delivery time, the stock level and the type of payment, the order must be processed separately.
Depending on the complexity of the process, this often leads to complex "if-then-else" constructs (spaghetti code) when implementing with Magento, which are difficult to understand after a short time and appear almost unmaintainable after a longer period of time.
Spryker provides a solution to this problem with the so-called state machine. Processes can be easily modelled and visually displayed using states, transitions and events. This solution gives both the developer and the shop operator a transparent and easy-to-maintain option for implementing and expanding complex processes.
Import / Export
Every e-commerce project needs a way to communicate with the outside world.
Products and stock levels, orders and customer data etc. must be able to be exchanged and synchronised with other systems. Each software product has its own way of doing this and provides the data in a variety of different formats and forms.
Unfortunately, Magento only offers a very limited solution for dealing with this data. With the available on-board tools, the limit of what is possible is unfortunately reached very quickly and the developer has no choice but to tinker with a solution himself. Only in very few Magento projects that I was allowed to work on could we fall back on an existing solution and we had no choice but to start from scratch. The overwhelming number of third-party modules dedicated to this topic illustrates this problem.
Spryker, on the other hand, already provides a framework for realising imports and exports quickly and cleanly. The developer is left with the task of converting the data into the correct format. The actual process of importing and exporting is then carried out using the tools provided by Spryker.
Adobe - SaaS vs Open Code
The purchase of Magento by Adobe in 2018 signalled a certain paradigm shift. The strategy seems to be to move away from a single code base that you can operate yourself towards distributed "microservices", which are then developed and provided by Adobe. "Live Search" and "Product Recommendations" are two of these SaaS products that can already be used. Unfortunately, Adobe has not clearly communicated where the journey is heading and whether Magento will be further fragmented by external services.
In the long term, this means less control over your own ecommerce system and a "lock-in" by Adobe. The flexibility and expandability that has always characterised Magento is unfortunately lost to some extent with this strategy.
PaaS, on-premise or SaaS - Spryker offers three options, but only in terms of hosting the ecommerce system. The individual features remain open code and can be used, modified or removed as desired.
Bye Bye Magento – Hello Spryker
Conclusion
Without question, Magento was one of the largest and most influential e-commerce systems on the market. However, the developments of recent years have seen Magento lose more and more ground, with many agencies and developers turning their backs on the Magento world and looking for alternatives.
Due to the state-of-the-art architecture and the growth of recent years, this alternative for me is Spryker.