Decoupled CMS architecture, also known as “headless”, is an increasingly popular development approach. It offers advanced user experience and a great deal of flexibility for future redesigns. Many web development projects are now using this approach and for good reason. Headless development can offer your project many advantages, so it’s worth considering if it will work for you.
A ‘coupled’ CMS architecture approach ties the CMS backend system to the front-end. It’s quick to develop websites in this manner using popular template-based development platforms such as Drupal and WordPress. But it also means that you make decisions early on about where content can appear and what kind of content you can publish.
If the owner wants to redesign the website at a later date, it usually means having to rebuild the site unless a very similar design theme is chosen. When front and back ends of a website are locked together, it limits your flexibility to evolve the website at a later date.
Whilst the coupled approach is a good way to quickly build a basic website or blog, brands that aspire to change and grow in the future may want a more flexible approach.
A decoupled approach instead separates the CMS from the design. The CMS links to the front-end component via an API, whilst handling all the content management and site admin tools in a standard CMS interface.
The CMS admin functions look, feel and act just like a traditional CMS; it’s just the website design isn’t built into them quite so fundamentally. It’s an approach that offers greater flexibility for later development of the front-end without having to redevelop the CMS.
A lasting trend
Headless development is unlikely to be a passing trend. This approach is being picked up in new iterations of the world’s largest CMS platforms such as Drupal and WordPress, meaning its now being adopted as a mainstream method of development. This means that it’s within reach of even the humblest web development project.
It’s likely to be significant for brands because of the advantages it offers those who adopt it. For starters, front-end developers have more freedom as they aren’t so dependent on the back-end architecture to achieve whatever vision they want.
They can use their native tools to fully control the user experience. Brands should be aware that if their competitors are all using the headless approach and they aren’t, they could be hamstringing their user experience and putting themselves at a disadvantage.
Brands should also be aware of the speed advantage that this development method affords them. Because the website isn’t dragging a huge backend around with it, pages can also be loaded more quickly.
Display logic rests on the client-side and the backend is more streamlined. This makes your application much more responsive. It’s a way to create a faster site. There’s strong evidence this is something that users really value.
Many headless CMS providers have placed flexibility at the core of what they do and a lot of the well-known providers have built-in localization and multilingual capabilities. Contentful allows you to create multiple locales based on language or geographical region.
Directus, Content Stack, and Kentico Cloud also have localization capabilities built in. Another benefit of the headless approach is that the developer gets to decide how the relevant language versions are presented and if the user should be redirected automatically or shown the relevant options once arriving at the site.
Disadvantages of headless
Of course, there are disadvantages to headless development too. It’s not the best choice for working with Internet Of Things and might not work for a full-scale eCommerce site.
There’s also another potential disadvantage to this style of development – it disrupts project dynamics and roles, for example, by elevating the front-end developer. This disruptive effect can, of course, be a blessing as well as a curse – but not all teams will adapt easily to the new way of working.
Headless development projects can help you get a project up and running more quickly. That’s not always something that organizations can cope with. For example, headless development projects tend to enable you to put content first.
That’s fine as long as organisations are ready to start talking about content right from the beginning, but it means the content collaboration process needs to start moving as soon as the wireframes are signed off. Not all organisations can move as quickly as headless projects require them to.
Building headlessly can also be a bit more complex. Businesses are used to building in the coupled approach, so headless development is going to take some getting used to.
But there are additional complications besides the novelty factor. You’ll need to pay separately for the CMS, for the developer and for infrastructure to run your site. You’ll need to hire a project manager that can manage the new way of thinking and get your content strategist hired early. We’ve grown accustomed to the ‘old’ ways of doing things.
Headless development approaches may seem exciting but they aren’t necessarily right for every project. Consider your need for scalability, publishing flexibility and security carefully before you decide what’s the best development approach for you.