Today we are featuring Fabian Schmengler with a post detailing his hands-on experience with the Spryker e-commerce framework and laying out what the differences are with Magento. This post originally appeared on Fabian’s English blog and is also available in German.
Recently I had the opportunity to take a peek into the source code of Spryker, the e-commerce framework that’s composing itself to be the new player in the enterprise area. Spryker was originally developed by the Berlin based incubator Project A to be used in the companies that they build up and is supposed to be released to the public this year. While “public” is not enirely true, I can say so much in advance: an open source version is not planned, licenses will cost about €100.000 per year. Agencies can register as partner, to get access to source code and documentation without a license. With the first sold license they get access to additional training material. Freelancers are not addressed. Already listed as partner are the agencies CommercePlus and Symmetrics that are well-known in the German Magento scene.
What is special about Spryker?
Spryker doesn’t consider itself as ready-to-use product but as framework that provides the building blocks for an individual e-commerce solution from which you can choose and extend for your project. This takes the reality into account that no project is equal to the next and each shop has its own processes and infrastructure, which you have to address individually.
The core of Spryker are two separate applications, Yves and Zed. In short, Yves is a lightweight application for the frontend, Zed the big gun for the backend.
Yves (in the first version developed with Yii, now with Silex) reads any needed data from an in-memory NoSQL backend such as Redis.
Zed (Zend Framework 2) handles communication with MySQL, message queue and external systems, and contains the business logic for order processes and so on.
Zed is called by Yves only for a few operations, by making use of a REST API:
- Add product to cart
- Edit customer account
The frontend application focusses on performance and simplicity. It is supposed to be easy to learn and possible to change without complications and little risk. Access to the file system should be minimal, access to relational databases none at all. Product and session data are retrieved from a NoSQL database, search is powered by ElasticSearch.
A central technical trait which is highlighted by the creators of Spryker, is that no kind of caching is used, especially no full page cache. A cache increases complexity, hole punching is necessary for logged in users and items in the shopping cart, a logic for cache invalidation has to be implemented, cache warmup, and so on. Caches solve a symptom, not the cause of performance problems, they say. The goal is, to achieve processing times of <= 50 ms / request without caching.
In a demo installation with not many products this is already the case. Real shops based on Spryker or its predecessor that I saw, had times between 100-200ms, which is still okay, but according to Fabian Wesner (CTO of Spryker Systems) is attributed to lousy programming in the frontend and/or weak servers.
The demands for the backend are different than for the frontend, it is all about business critical operations, so stability is more important than speed and short release cycles. But Zed is supposed to be relatively easy to learn for an experienced developer as well.
It is covered with unit tests and integration tests and consists of many single modules with well-defined and cycle-free(!) dependencies. Every module has its own DI container. Every module has a Facade class as public API (Facade in the original sense, dear Laravel devs), every class is implemented against interfaces. All in all the SOLID principles for object oriented design have been followed. What I saw, looked very clean, clear separation of concerns, no long classes and methods.
Propel 1 is used as ORM, which is slightly dusty but Propel 2 is not yet ready to use and Doctrine has been written off as too bloated. This decision tells a lot about the philosophy behind the architecture: As “enterprisey” the code may look, it does not originate out of love for complexity but they still strive to find the simplest appropiate solution. I have experience with Propel from previous projects and it is indeed simple to learn and to use. For smaller individual projects I would use it again anytime. I can imagine that it also works well for bigger projects, at least it offers enough flexibility through custom SQL code in “Peer” classes.
A noteworthy feature of Spryker is the modelling of business processes with state machines. State machines are modeling the behavior of a system with states and transitions. In this manner, states of orders and how they change on which actions are modeled with state machines. Conveniently, it’s possible to visualize them automatically. Generally, Spryker visualizes application logic wherever possible.
Comparison to Magento
What strikes immediately, looking at the code, is that no “PHP magic” is used, everything is cleanly typed, so that the IDE helps out everywhere. For Magento this is only possible with plugins like Magicento. Both systems use the Service Locator pattern for instantiating classes, to allow easy replacement (“new” is almost never used, although at least Magento makes some exceptions). But in Spryker replacements are easier to handle, because for each class there is a complete interface to implement.
In terms of Clean Code Spryker has the edge over Magento. Magento 2 makes good advancements in the right direction but still carries around huge technical debt from modules and architecture that were more or less directly ported from Magento 1.
Magento allows a flexible data structure within MySQL with its EAV model. But this is also a performance brake which had to be compensated for with flat index tables, which in turn add additional complexity. Spryker on the other hand, saves for example product attributes as JSON in a NoSQL database (Redis), which allows way faster access. Searching and filtering is handled by ElasticSearch anyway, so the features of a relational database were not really necessary.
Magento defines itself amongst others with a multitude of features out-of-the-box. There is a less flattering expression for this, namely “creeping featurism”: more and more features that might be needed at all, are plugged into the software and increase complexity and maintenance cost.
Which Magento developer didn’t at least once get the task, to “deactivate unnecessary core modules”? And that’s not even simple in some cases, so that there are even distinct modules that support deactivation of core modules. And how frequently core modules are not sufficient for customer requirements and have to be replaced or enhanced anyway?
Spryker on the other hand does not try to be capable of everything a little, or at all attempt to be a full-fledged but extensible application. It should be more efficient with realization of individual requirements at the end of the day. But there still are the smaller merchants without special needs and without ERP which are well served by an off-the-shelf application with custom theme and smaller modifications. Those are of course not the target group of Spryker and in those cases Magento is still first choice, if not a SaaS plaform like Shopify.
However, Magento’s big plus is the amazing community. User groups, podcasts, (un-)conferences and hackathons organized by the community, non-profit organizations like the Meet Magento Association and FireGento e.V., countless ambitious developers and also agencies that make their tools and modules available to the community.
Let’s face it, no matter how hard you try you won’t get this kind of community for a closed source framework. And all complaints about trashy extensions on the Magento Connect marketplace aside, there are still many really useful and high-quality extensions, as soon as you know where to find them and how to separate the wheat from the chaff.
On top of that, since the Magento 2 Developer Beta, the Magento Community Edition is “more” open source, the state of development is updated daily on GitHub and pull requests are actually accepted and processed quickly. This way, the source code benefits from the active and dedicated community as well, and the days of year-long known bugs with unofficial patches should be numbered.
Will I use it?
Probably not in the near future, the barrier to entry is too high and projects in the dimensions that Spryker addresses are scarce in my daily work. But I will definitely keep an eye on the development since it makes a promising impression.
What can we learn from Spryker?
That’s maybe the more interesting question. A look beyond the own nose always pays off, also and especially if you are specialized in one technology.
Some concepts and ideas stand out:
- Real separation of frontend and backend
- Consequent application of OOD principals for modular architecture, without “shortcuts”
- No “creeping featurism” and focus on the essentials
- Automatic visualization of business processes
- Fast frontend without full page cache, not using caching as first response to performance problems
- Right Database for the job: Not squeezing everything into relational databases
One may look forward to watch how Spryker evolves and what kind of fresh impetus it gives to other ecommerce platforms.