Which platform is for you?
At Inviqa, we’re always on the lookout for new platforms and technologies that fit in with our core delivery skills of PHP, Node and Scala. Our ecommerce business is one that has grown from strength to strength over the past five years off the global success of the Magento platform.
Magento achieved its success by being able to rapidly develop features desired by business-to-consumer (B2C) ecommerce websites and offering an ‘off the shelf’ product that was ready to integrate with payment providers and shipping vendors by using built-in or third-party modules.
It saw fast adoption thanks to its ‘free’ nature, by having a community version, and through the creation of a third-party module ecosystem that could fulfil the basic needs of a great deal of online shopping requirements.
With top-class engineers, Inviqa has been able to take on Magento websites and its feature-first approach, and to start addressing the second problem that all successful websites eventually hit: the problem of scaling to high numbers of users.
With its feature-first approach, the architecture of a Magento website reflects that of a monolith. The fundamental problem with scaling a monolith is that each component is not independently scalable.
To increase capacity in one small area to handle an increase in frontend traffic requires scaling the entire system. This can be very expensive in terms of hosting requirements so alternatives need to be found.
These alternatives come in the form of a full-page cache. Scaling Magento requires very heavy use of caching technology. Inviqa developed a caching module for Magento 1.x that took advantage of the Varnish HTTP cache to deliver content to end users without hitting the real servers behind the cache.
Being able to serve the bulk of requests from the Varnish cache can enable a Magento-powered website to scale a great deal. One of our Magento-powered ecommerce websites, for example, serves up to 45,000 customers in just five minutes.
Heavy reliance on a HTTP cache does come with its own problems and cache invalidation starts to become a limiting factor. When there are many layers of cache, there must be a process built in to ensure that when the underlying data is changed, it filters up to the front layer of cache as soon as possible without causing a stampede on the backend, which could potentially bring the site down for a long period of time.
Solving this problem requires a fundamentally different approach to the platform architecture. Caching is a hugely important factor in running a website at scale, but to avoid the problems of stampeding on the cache it must be done at the right layer.
This is where ecommerce platform Spryker comes in. From the ground up, caching has been placed at levels below the frontend of the website to ensure that the platform retains full control over how invalidation works. The frontend (Yves) is deliberately a very lightweight PHP application that only has access to cached data in memory, utilising both the Redis in memory data store and Elasticsearch search engine.
These data stores are populated by the database driven backend application (Zed). Periodically, collectors run to extract all the data that has been changed and push it into memory data stores. The separation of the high-traffic frontend from the slower, administrative backend allows Spryker to independently scale either application as necessary to fit the traffic profiles unique to each.
Users of the frontend application will often provide data that is required in the backend system. An obvious example of this is when an order is placed. Communication between Yves and Zed is achieved directly through remote procedure calls (RPC), though these are limited to one per request to avoid network latency issues slowing down the frontend.
The focus is on performance at all times. As a result, the Spryker system is extremely fast even under heavy frontend load.
But Spryker does not try to be everything that an ecommerce platform needs to be successful. Its architecture and the constraints it puts on developers ensure that the performance of the platform is always the single most important thing.
From a developer experience point of view, Spryker is a very interesting platform. The core is very modular and follows a very consistent architecture that is encouraged for any custom development that goes into individual implementations.
Software engineers find themselves incredibly productive working with the codebase and able to produce very high quality implementations of highly customised requirements.
Spryker vs Magento: the verdict
Both platforms are built with PHP and are geared towards the same business goal: that of allowing end users to place orders for items and pay for them. The temptation therefore is to compare the two and pick the platform that fulfills the most requirements out-of-the-box without having to pay for expensive development time to implement them.
Spryker certainly wins out on the code quality and architecture side. Magento 2 has made some strides in the right direction but it still has a long way to go. Where Magento wins is in the community and third-party module ecosystem. It will be very difficult for Spryker as a closed platform (a license is required for every production installation) to compete here, so for a startup ecommerce website with third-party integrations to almost any payment provider, Magento is certainly still a compelling option.
Where Spryker really fits is for the established ecommerce sites looking for the next-generation platform that can really scale to meet the demands of a high-traffic business.
The reality is that, beyond the basic integrations, every ecommerce website is different and will certainly require customisation. This is where Spryker shines. Solid software design results in an easily extendable core which a development team can use to their advantage when building out custom functionality.
If you’re in a position where you’re trying to decide on a platform for your ecommerce business, it comes down to a question of how innovative you want to be with it. Spryker focusses on performance and extensibility where Magento focuses on ease of deployment and community built ecosystem.
We have seen that while Magento certainly has its fans, Spryker is the more appealing platform to a team of software engineers as it deliberately gets out of the way and allows innovation at the fastest possible pace.
Got a question about the merits of Magento or Spryker? Interested in discussing the unique requirements for your own ecommerce platform? Drop us a line at firstname.lastname@example.org