It’s 2021, and there’s no doubt that technology is advancing faster than ever. Some time ago I wrote that “There won’t be another Magento”. My main argument in that article is that the time of the all-inclusive, feature-driven platforms has passed and that it is being gradually replaced by more specialized and rather architecture-driven software – it’s about time to look into headless commerce solutions more deeply.
A few weeks ago I compared the GraphQL driven eCommerce platforms. But that’s just my deduction and some theory. This time I decided to check what my clients think, and most importantly: to find out why.
Highsnobiety.com powered by commercetools
When I spoke to Philipp Triebel, CTO of HighSnobiety.com what struck me was that the majority of the developers working on the site were newcomers to eCommerce. Sure, they were a media company with a lot of tech challenges regarding scale and traffic. But they had never dealt with things like currencies, taxes, etc.
“So, we know that we need something that gives us freedom on the front-end. We are a very visual company. That makes our front-end maybe more important than for the average brand. Also, given the model that we’d want to do content-driven commerce, we knew that we want to integrate commerce very smoothly and seamlessly into our existing front-end and like our existing experience. We already had some technology choices there. So, on the front-end that also played into it. This led us to the search for something versatile.”
What they were searching for in an eCommerce platform was a platform they could easily ramp up and speed up the process on the one side, while still having a clear API and high scalability features.
“Ideally we don’t want any boundaries on the front-end side. We want to be able to say, today we want to have a checkout on the article page or implement a mix of affiliate products and eCommerce products and it just shouldn’t matter to the front-end. We want to create a seamless experience” – Philipp Triebel
They were circling around different platforms:
“We had a lot of conversations with agencies, architects and the providers [..] First and most obvious candidate was Magento. [..] I’ve got a personal, quite frankly negative experience. Then we’ve been considering Spree Commerce – but it was like a more monolithic solution [..] Spryker was another one. One of the most promising one’s was Shopify. I was hoping we could use it. [..] The other contenders were enterprise SaaS platforms: AboutYou.cloud, but it was very early stage [..] The last one was commercetools.”
Why did commercetools finally meet all the requirements? Philip’s team was painstakingly comparing the platforms against the decision factors matrix.
The key criteria were:
- to have the headless architecture – so they could own the frontend: “We’ve been having already the React based frontend developed for the media site, so it was very important to us to maintain the same seamless user experience”,
- it should be API first – “Other platforms also have API but they’re not necessary the API first “.
- extensibility – by the way I recently posted about the commercetools extensibility mechanisms.
- enterprise features like multinationalization and scalability,
- reasonable costs of ownership, SLA – preferably SaaS platform.
Shopify was the preferred platform until they compared the multinationalization, multi-currency and multi-site capabilities. On the tech side – the GraphQL API of commercetools was also pretty amazing (just out of transparency – Shopify now also provides the GraphQL API).
LoveCrafts powered by commercetools
Halil is the CTO of LoveCrafts.com. They operate in 100+ markets and are now in the process of migrating from Magento to commercetools. Leading technology at Rocket Internet Halil’s first contact with headless architecture was in 2011, long before it became a de-facto standard for eCommerce solutions.
When I asked Halil why they decided on commercetools he said the decision was a process:
“We wanted to give this a due process, right? So I can’t just go and say I like commercetools and we go with it. We had to be sure because a platform change like this doesn’t happen often. You want to make sure that it covers your current needs but also your future needs because you won’t be migrating probably for another 5-10 years. We did some market research and looked at 30 platforms and 10 in detail, including meeting solution architects, going through each of our requirements and so on.”
Halil advised me that, in order to choose the right technology, you need to first understand your business. The changes / development requirements might show up over time. How flexible should the platform be? They listed all the business use cases.
The first option LoveCrafts considered was staying with Magento 1, and then the natural second was migrating to Magento 2. Staying on Magento 1 was not an option due to the upcoming end of life of the platform (and lack of support). Magento 2 didn’t make the cut either.
“Magento 2 doesn’t meet our requirements so we need to spend time building that functionality like we did over the years and I’m not talking about just some user features but fundamental changes and then also the performance question I raised earlier. So yeah I think so at least in our case”
The reasons for moving towards the commercetools platform include great documentation, GraphQL API, and data model.
To summarize why we chose commercetools let’s start with chemistry. [..] It’s API only, it has GraphQL support, it’s modular so you can pick and choose. [..] It actually had the best overlap with our requirements compared to all the other platforms. The data model is very sensible and scalable. Translations are for example represented in localizable attributes rather than requiring a whole new store in Magento for example. The pricing model is flexible and you have this staging capability so you can make changes to your products but publish at the end either by doing QA or have some other processes. This allows you to use the catalog SFM as well, whereas for example in Magento you save a product, and then it’s immediately public.
Marc O’Polo powered by AboutYou
When I asked Matthias Zielezny–Head of Software development at Marc O’Polo– the same “which platform and why” question, he started with an unusual observation. “First you need to decide which elements of the platform to own vs. which ones you’re gonna build”.
He said that Marc O’Polo owns what makes up the User Experience. In that case, it’s the frontend and backend services – including: Order and Store management, pre-orders, and pricing. The rest – including the eCommerce platform itself, Checkout, CRM components can be bought on the market.
The architecture Marc O’Polo has is pretty complex:
Including several components from different vendors like AboutYou components: Backbone, Checkout, CMS, company’s CRM from Microsoft and Internal ERPs (providing features like Order Management mentioned above).
What are the key reasons for owning these? Flexibility, sustainability, the highest possible speed of making adaptations and no-vendor lock-in.
Then, I asked Matthias how you could actually customize the eCommerce platform which is SaaS:
“We somehow have to connect that system to our internal or other external systems.
As AYC expects data in a specific format and also sends data in a specific format, we build a middleware on AWS and Azure to transform the data between those systems.
So our order management system for instance gets the order as json through AWS API Gateway which triggers a Lambda function.
This function makes a few checks and writes the order to our order database which is DynamoDB. On this table we have a trigger, so on order creation we are triggering another lambda function which exports the order to our logistic partner and another lambda which sends the bonus points for our members to the CRM system and so on.”
The platform selection process in case of Marc O’Polo was really complex including stages like:
- Architecture sessions,
- Tech stack validation,
- Code deep dive.
The reasons they decided to have the AboutYou as a partner were the performance, feature parity (which is especially useful/important for fashion stores), great docs, developer experience with AYC API’s and the company’s transparent and partner approach working with it’s client.
That’s it for now. If you’d like to check out more case studies subscribe the CTO-CTO podcast including hits like “Zadig & Voltaire Magento 2 + Vue Storefront migration case study!”
Discover the audio version of the article on our CT-CTO YouTube playlist:
Published February 18, 2021