Over the last five years, we've witnessed several notable changes in commerce architecture. Notably, the onslaught of headless commerce has forced brands and their technology leaders to reconsider the traditional monolithic approach.
I've seen companies make assumptions about how to best structure this new headless commerce system. Some do it well while others fail, but those that succeed have one aspect in common; they understand that having an API with endpoints that can be queried is not nearly enough. After all, what good is an API with data if the data is old, stale, and irrelevant? The best technology leaders have an obsession with data flow and separation of concern.
I will talk about a data flow anti-pattern we regularly see called the CMS Daisy Chain. While this isn't the only anti-pattern found in the modern headless commerce stack, we often see it.
When going headless, most merchants identify a primary issue related to webstore merchandising control. If you separate the frontend from the backend, how will your merchandising team edit the webstore without calling in a developer? This "headless orchestration conundrum" plagued early headless builds.
Some headless approaches will solve this by sacrificing the entire notion of headless. We often see competitors bring solutions to the market that tightly couple the content management system backend to the frontend to solve the headless orchestration problem. Often categorized as headless digital experience products, these are just subtle iterations of page builders from the past.
This approach is dangerous because it undermines the merchant's ability to go headless. After all, if you are registering backend CMS components directly into your frontend, are you headless? Doesn't this architecture break the separation of concern between the frontend and the backend, which is the whole purpose of a headless build?
A more viable headless approach would be to query the API from the CMS as unopinionated raw data, then fit that data into components explicitly built for the frontend of the head. We have a much better architecture here since our frontend is decoupled from our backend.
However, the world of commerce doesn't simply include content. It turns out, to provide a good customer shopping experience, many systems need to come together. A common one is the product catalog, an essential for online shopping.
The modern commerce architecture suggests that merchants separate concerns between the CMS and the product catalog. This structure is not a stretch of the imagination, as most merchants today use a product information management system (PIM) or an eCommerce platform to manage their product data.
And herein lies our conflict; the product data sits outside the system you will use to bring data into the frontend. So, data must first move from the product catalog system into the CMS database. Then, from the CMS database, into the frontend. Welcome to the Daisy Chain.
Here we should ask an important question: is this architecture the right choice to achieve our goals?
At Nacelle, we see firsthand the pain merchants deal with when leveraging monolithic platforms. One of the primary motives for going headless is to rid the organization of monolithic solutions. And while the monolithic platforms of commerce are slow, lock-in merchants, and lack flexibility, they aren't all terrible either; some do a superb job providing data shape and structure around commerce.
Contrast that to the CMS in today's market, which focuses on flexibility. The headless CMS providers force merchants to design a database to make the CMS useful; this process is called "content modeling" is simply a rebranding of database modeling. And, while this flexibility is applauded, it means the CMS system itself has no opinion and gives no guidance for the best structure of the data.
When executing a Daisy Chain CMS architecture, you make a handful of poor trade-offs.
First, you exchange one monolithic system, your eCommerce platform, for another monolithic system, your headless CMS. But the new monolithic system you have chosen has no knowledge nor opinion on your most essential commerce data; for all of your work and effort of going headless, all you have done is exchanged one monolithic platform for another. And this new monolithic is, arguably, the worst solution for your organization.
Second, you now have a data flow problem. Getting data to move, at scale, out of eCommerce platforms is always a difficult task. You will battle unreliable webhook systems, poorly designed APIs and bulk files systems, slow response times, rate limits, and throttling. Therefore, product data in the CMS, which originates from the eCommerce platform, will often be stale. And this includes inventory, pricing, descriptions, etc.
But this is just the first chain!
Now, data must flow from the CMS and into the frontend of the webstore. And the CMS, although often a touch better, still struggles with the data flow. Again your system will battle slow response times, unreliable webhooks, broken APIs, low rate limits, etc.
The CMS Daisy Chain is a game of double jeopardy, and it leads to painful eventual consistency issues where the webstore can never catch up with the most recent changes because the data is too stale to be relevant.
So how does Nacelle solve this problem while empowering merchants? In parallel, Nacelle pulls data directly from the eCommerce platform and pulls data directly from the CMS platform. We then offer integrations that create references to products and catalogs in the CMS- but this data never lives in the CMS. Instead, we use a Lazy Binding pattern, where the product data is resolved only when a query is executed. Automatically. Voila, no daisy chain needed.
Now, the CMS can be leveraged to do what it does best; content. Your merchandising team can drag and drop to rearrange the webstore and build new landing pages on the fly. All of this will include product and catalog data that is up to date, which means merchants can have their headless cake and eat it too.
This is why we designed Nacelle to use advanced event streaming technology, and this is why we needed to build a lot of infrastructure to solve these problems for our merchants. The modern headless commerce stack is exciting and will be fruitful for many brands and retailers alike. But it is also all too easy to make disastrous mistakes that will negatively affect the long-term viability of your webstore.
We recommend your team think beyond the API structure and strongly consider data flow while building your ideal headless system.