SftB #4 recap - The power of headless: Connecting CMS & eCommerce
Storyblok is the first headless CMS that works for developers & marketers alike.
At the 4th Storeis from the Blok event, Maria Künzner (Technical Project Manager) and Johannes de Zordo (Senior Frontend Developer) from Marc O’Polo talked about their journey from monolithic to headless architecture. This article is a short recap of their presentation.
SftB #4 - The power of headless: Connecting CMS & eCommerce
Section titled Why change if everything is stable? Why change if everything is stable?
Maria started the presentation by asking a key question “why bother changing?” To answer that, she first gave a quick overview of Marc O’polo’s previous tech setup, built with an all-in-one approach. While this meant easy communications, as there was only one vendor to deal with, it also had some crucial flaws.
)
Marc O'Polo's old setup
Looking at the flaws, the team at Marc O’Polo felt that their tech stack is not really future-ready. This meant some changes had to be made. Instead of “doing everything a little bit, with imperfections” the team wanted to focus on things that mattered the most to customers, and do them perfectly.
This mindset then led to the next question “who is able to do things in a way that delivers the best experience to our customers?” As Maria pointed out, the obvious answer was themselves - the Marc O’Polo dev team - as they knew more about their own customers than anyone else. This meant putting the in-house team on the driver’s seat, and providing them with all the cutting edge tools that they needed. The new setup was built around this principle (best-of-breed) with Storyblok as the new CMS:
)
Marc O'Polo's new setup (MOP: Marc O'Polo, SB: Storyblok, AY: About You)
But before looking at the result, there are some other questions to answer. Firstly, how did the Marc O’polo team tackle this whole project?
Section titled Setup to a new level Setup to a new level
From the beginning, the team knew that the new setup had to be headless (including the CMS), for all the benefits that it offers. They had 12 months to choose a new setup, and implement everything.
)
The timeline set by the team for a completely new setup
A new potential CMS had to meet an extensive set of requirements, including internationalization, WYSIWYG editing, scheduling, and more.
)
The set of requirements for a new CMS
Section titled Why Storyblok? Why Storyblok?
During this 12 months period, Maria and her team first settled on another CMS. For roughly 200 days when this new headless CMS was in place, they had to struggle with some key procedures. This eventually led Maria and Johannes to think about a new option, with more than half of their time already spent.
After looking for a CMS that would check all their requirements, Johannes managed to find Storyblok and create a prototype in only 2 days. For Maria, this was exactly what every team needed - an agile system that helps getting things done, and doesn’t get in your way. With the developers and the Technical Project Manager on board, convincing the other teams followed quickly, and after only 14 days a completely new CMS was in place!
)
With more than half of their time spent, the team started to look for a CMS alternative
Section titled Integrating Storyblok, and some uses cases Integrating Storyblok, and some uses cases
Johannes dedicated the second half of the talk to firstly explain how Storyblok was integrated inside their new API-based solution, and then to present some practical use cases.
)
The API-first setup of the new online shop
The first use case that Johannes presented was centered on the eCommerce system and Storyblok. As an example, a category page from the online shop was chosen. These pages have different kinds of data showing up side-by-side. More specifically, there is eCommerce data (categories, products, etc.), and also content data (custom headline, image, etc.). To fetch any data from the frontend, Johannes and others use the URL as the identifier. The question is, how could they make sure that the same structure is present in both the eCommerce system and Storyblok.
)
Use case: Using Storyblok's Management API to automate synching categories
Having around 400 active categories (which can change at any moment) meant that manual maintenance was not really an option. With Storyblok’s Management API (which allows users to write, change, and update stories), the team was able to automate the whole process and save hundreds of hours of work.
Another use case presented by Johannes was centered on creating personalized content. This meant connecting their CRM data with Storyblok. This was managed easily by taking advantage of Storyblok’s Data Sources which allowed them to set individual data sources for different blocks of content - or in other words: which banner/headline should be shown to which customer.
)
Use case: Using Storyblok's Data Sources to easily personalize content for the customers
Johannes presented a few more use cases, including promotions and manual sorting. If you want to know more about them, and listen to Maria’s in-depth explanation of their journey, check out the video at the top of the page!
