< Back

CMS Antipatterns in Headless Commerce

eCom and Marketing

December 16th, 2021


Over the last five years or so, we've witnessed several notable changes in eCommerce architecture design. Notably, the increased popularity of headless commerce has forced brands and their technology leaders to reconsider the traditional monolithic approach and move to a new modern commerce stack.

I've seen companies make a number of assumptions about how to best structure this new modern commerce stack. 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.

Introducing the CMS Daisy Chain

I am going to talk about a data flow antipattern we regularly see called the CMS Daisy Chain. While this isn't the only antipattern found in headless architectures, it is one we see far too often.

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 common headless conundrum plagued early headless builds.

Some approaches will solve this by sacrificing the value of having purpose-built tools within the modern commerce stack. We often see solutions that tightly couple the CMS backend to the frontend to create a single source of truth for product and content data. Digital experience products, subtle iterations of page builders from the past, now take on the role of keeping data flowing and in sync across systems.

This approach is dangerous because it undermines the merchant’s ability to keep the frontend and backend separate. After all, if you are registering backend CMS components directly into your frontend, are you using the best tool possible for data flow and orchestration? Doesn't this architecture break the separation of concern between the frontend and the backend, which is the foundation of a headless architecture and the modern commerce stack?

A more viable headless approach would be to query the API from the CMS as unopinionated raw data, and then fit that data into components explicitly built for the frontend of the head. In this case, we would have a much better architecture since our frontend is decoupled from our backend.

However, the world of commerce doesn't simply include content. Many systems need to come together to provide a good customer shopping experience. A common one is the product catalog, essential for online shopping.

The modern commerce stack suggests that merchants should 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.

Here is our conflict: the product data sits outside the system that will be used 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 CMS Daisy Chain.

Issues with the CMS Daisy Chain Approach

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 moving toward the modern commerce stack is to rid the organization of the challenges of attempting to work with these types of solutions. And while the monolithic platforms of commerce have challenges, they aren't all terrible either. Some do a superb job providing data shape and structure around the domain of 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," and 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 are making a handful of poor trade-offs.

First, you exchange one monolithic system—your eCommerce platform—for another , your headless CMS. But the new monolithic system you have chosen has no knowledge or opinion on your most essential commerce data; for all of your work and effort of going headless, all you have done is exchange one monolithic platform for another. And this new design is, arguably, a worse 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 poorly designed webhook systems that are unreliable, 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, and more.

And this is just the first chain!

Now, data must flow from the CMS and into the frontend of the webstore. From there, the CMS may be a touch better, but chances are it will still struggle with the flow of data. 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.

Overcome Inherent Design Challenges with Nacelle

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 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 modern commerce stack.

Interested in learning more about eCommerce architecture and how the modern commerce stack can help you achieve the many benefits of headless commerce? Visit the Nacelle documentation resource center for more information. 

Brian Anderson

Brian Anderson


Stay in the know.

Get tips & tricks straight to your inbox.