Headless architecture is a relatively new approach in web development, right? Actually, it’s not. More than 10 years ago, I was developing web applications based on ExtJS and the back-end REST API using a similar approach that involved working with a content repository without visual interfaces. The modern headless CMS is only slightly different: Most business logic went to the front end, where cloud services were beginning to be used in development.
In fact, the rise of the headless approach is logical from a technological perspective. For a long time, developers used different tools for front-end and back-end development. This changed when JavaScript stopped being used as a browser script and became a solution for server-side rendering. This was made possible by the emergence of frameworks like Next.js, Nuxt.js, and Nest.js, which allowed JavaScript to be used for the back end as well. With these tools, APIs, and an endpoint with content in JSON format, it became possible for JavaScript developers to cover server functions and do full stack development. With JavaScript coders now doing full stack development, CMS development began to favor this approach as well, making it easier to manage the back end and deliver content in various formats.
This is all great, and it works perfectly in some cases, but do you need to jump on the headless bandwagon? In certain situations, this approach would be an inefficient solution. Let’s consider them in detail.
You Want a Single Toolbox With a Complete Set of Tools
Modern headless CMSs are lightweight and help manage unstructured content. When you need detailed analytics, marketing automation, personalization rules, or any other extended features, you need to connect additional systems to a headless CMS. At the same time, traditional and hybrid (JSS) Sitecore setups offer you all the tools out of the box, integrated with your corporate environment, with users and permissions managed from a single account. So, if you need various marketing tools seamlessly integrated with your content and analytics in real time, headless architecture might not fit the bill.
Manage large amounts of content, engage customers, and personalize offers
You Need To Be the Owner of Your Data
You Have a Lot of Everything
What does a normal Sitecore setup look like? 30 sites, 15 languages, 100 back-office users with different permissions, weekly marketing campaigns, thousands of personalized emails sent out daily, site content aggregated from 10 different external data providers, and 20 background jobs running every night on a dedicated server. Since a headless CMS doesn’t weigh much, it will be difficult to use it to support and manage the performance of multiple site versions and other complex operations.
You Need to Personalize Everything
For sure, you can use personalization rules with a headless CMS, but you’ll need a third-party service for this, which will limit the connection between user analytics profiles and content. Website extensibility will be limited too. Meanwhile, a traditional/hybrid Sitecore XP setup will allow you to fine-tune every part of your website—any page, any module—leveraging all available user data, any business rules, and any content you have.
You Want Experience Editor
If you’ve been working with Sitecore for some time, you’re probably familiar with its What-You-See-Is-What-You-Get editor. Experience Editor allows you to make changes directly on a page so that you see the results immediately, whereas in a headless CMS editor, you only see a page with several text fields. Once you see how a properly developed Experience Editor can be used to manage a website, you’ll forget all about headless.
Your Target Audience Is Located in One Region
If your servers are located in the US and you need a seamless user experience in Southeast Asia, you might need to set up additional infrastructure there, which is quite costly and complicated with traditional server-side personalization. In this case, a headless cloud CMS would be the best option. However, if your target audience is located in one area, it makes more sense to adopt a traditional/hybrid Sitecore setup.
You Need a Complex Solution for a Global Company
Suppose your organization is global and every regional unit needs a set of web tools that are both flexible and aligned with global brands and other units. The level of complexity increases when a new dealer adds a branded website for a country managed by a local office. Headless architecture won’t cut it as the backbone of such an extensive system. Here, a traditional Sitecore setup is your best bet.
You Need a Long-Running Supported Solution
Sometimes the newest products and technologies just don’t live long enough. Trends come and go every year, but COBOL is still crunching numbers after all these years. While Sitecore encourages the use of the latest technologies, its core is mature and has been well supported for decades. Sitecore’s support team and partners are ready to help users improve their experience as well.
What About Performance?
Regardless of the technologies used, websites with lots of personalized, dynamic pages always perform slower than a compact headless system. Modern websites based on JavaScript and APIs are fast, but with the proper optimizations, even an old Sitecore MVC site will do the job.
Like any approach, using a headless CMS has its pros and cons. Before switching to headless architecture, you need to understand whether this trend meets your business requirements–which might not always be the case. In Part 2, we’ll look at some cases when the headless approach is the optimal solution for your organization.
