Modern CMS development has become a lot more complex in the last few years. Traditionally development within a CMS framework involved writing code within the same folder as the CMS using its APIs and job done. Nowadays we have a plethora of different CMS architectures to pick from, decoupled, coupled, hybrid, JAMStack and headless.
There are very few CMS systems that have been designed to work with all architectures. Nowadays each CMS is typically focused on one type of architecture. When deciding to build a new project, it is your architecture choice that will help guide you as to which CMS is most suited to your needs.
If you try to Google for information about these different CMS architectures, you will be presented with hundreds of marketing fluffed articles. Most of these articles will be written by one of the CMS vendors, explaining why their approach is the best. This guide is different 🤔
This guide is a developer-focused tutorial that will explain the differences between these different CMS architectures, giving you real-life examples and unbiased opinions. Just because a headless CMS provider says that headless is the be-all and end-all, does that make it true? If you want to know the real truth, this is the tutorial for you 🔥🔥🔥
Coupled Architecture Explained
Let's start with the classic architecture, which is now known as a coupled architecture. Coupled architectures are where CMS systems originally spawned from.
With a coupled CMS architecture the backend and frontend are built within the same platform. Typically when picking which coupled CMS to use, the main filter between the options will be the programming language that the team uses. C# has its own range of CMS systems, Java has another range and who could forget WordPress (written using PHP). In a coupled CMS system, the website is built predominantly with the same language that the CMS was built with. This is because the APIs to access the content will also be written in that language.
In a coupled architecture, the back end of the system is closely integrated with the front end. The CMS and the delivery tier are effectively the same things. The benefit of the coupled architecture is that if you have a team with a certain skill set, like C#, when using a C# CMS a lot of the fundamentals will be very familiar to the team.
There are several main downsides to a coupled architecture. First, as the CMS and frontend is coupled, a mistake in one will take the whole site down. When you need to release updates on either the frontend or to the CMS, you need to release everything in a big band, increasing the deployment risk.
The second point is focused on upgrades. CMS systems tend to change a lot. In a coupled architecture, if the CMS architecture drastically changes, you will need to completely rewrite your frontend. In a coupled architecture, if you want to keep up to date with the CMS, expect to completely re-write your site once every 3-4 years.
The last point is around trends and resourcing. Frameworks like React, NextJs, etc... are less useful in a coupled architecture. As Javascript is now the most used language in the world, there are fewer traditional language developers around making it harder to staff your projects. As younger developers want to work on whats popular, you will find it slightly harder to recruit for projects using languages not on trend
CMS Platforms That Support Coupled Architectures: WordPress, Drupal, Umbraco CMS, and Episerver CMS
PRO
- If you have an existing team that knows a certain language, there is less to learn
- Less infrastructure
- Use the CMS APIs rather than re-inventing the wheel
CON
- Limited to just websites
- Can not use ReactJs, NextJs, etc... SPAs and JAMStack not supported
- Harder to keep frontends happy
- Need niche CMS specialist that can be hard to find
Headless Architecture Explained
Within a headless architecture, the CMS and website are separate. All content rendered on the website is accessed via an API that the CMS exposes. This API might be REST or GraphQL. Hosting wise the CMS and website might be hosted using completely different hosting solutions. For speed it is recommended that CMS and website are hosted within the same region of the world, however, this is not mandatory!
Typically within a lot of headless architectures, the CMS is a SASS tool that is not coupled to a specific programming language. Content modelling is not typically influenced by a programming language, however, this is not always the case. In most CMS systems, content modelling can be done completely within the CMS by content editors.
Most headless CMS systems will be very Javascript focused. As the frontend can be built using whatever you want, you are free to use a SPA with SSR or JamStack with SSG. The downside of this freedom to do what you want is effort. Unless the CMS vendor ships with a really good Javacript/React SDK/Vue SDK you may have to do a lot of the heavy lifting of talking to the CMS yourself. When picking headless, make sure the vendor has a good clientside SDK!
Headless CMS systems are also essential if you are providing multi-channel support. If you want to share content between a website, a mobile app and an IoT device you do not want your content coupled to one thing like a website.
As all content is accessed using an API, developers are free to create as many frontends as they want to interface within a headless architecture.
One consideration that seems to cause a lot of heated conversations in headless architectures is preview. How do you preview your content as it is written with your applications?
Most headless CMS solutions (not all Storybloq) do not provide inline editing or preview capabilities inside of the CMS. If the content is meant to be consumed by multiple things, coupling a preview just to your website view is not great.
Instead of CMS powered preview, most headless systems preview capabilities work based on tokens. You get an API token for production and one for preview. You then create a preview version of your site or app that is configured to talk to the CMS API using the preview token. To preview your app when content editing, you simply view the preview version, sounds simple right?
A lot of non-headless CMS vendors will say that preview and inline editing is the most important feature of a CMS, I will not comment on this and leave the decision to you...
To make discussions more interesting within headless, your frontend website can also be built using different architectures. Within a Javascript powered headless website, you can design your website to render pages using either an approach known as a SPA or as a JAMStack architecture.
Out of these two options, the choice you make will influence the Javascript frameworks that you will use on your site. If you use JAMStack, you will use a tool like NextJs, NuxtJs, or Gatsby. If you go SSR you will use pure React or Vue and NodeJs.
Within JAMStack, your CMS pages are statically generated into HTML during deploy time. Within a SPA the application needs to be enhanced with server-side rendering abilities in order for pages to be spiderable by search crawlers. Covering these topics in detail is beyond the scope of this simple guide, however, this route does take a lot of consideration!
CMS Platforms That Support Headless Architectures: Contentful, Strapi, ContentStack, and StoryBlock.
PRO
- Build a front however you want to
- Works Omn-channel
- Works with SSR and Jamstack
- Easy to hire Javascript developers
- Decoupled hosting, update the CMS without rewriting the frontend
- Deploy the frontend without impacting the CMS
CON
- You will likely need to build more of the heavy lifting to the CMS yourself
- Preview is supposedly an issue
Hybrid Architecture Explained
A hybrid architecture allows for a bit of everything. CMS systems that support hybrid, tend to have been the ones that have been around for a long time. From my experience, hybrid tends to be the first step that a traditional CMS vendor provides in order to support some form of headless architecture.
Within hybrid, you can still build a CMS using a traditional coupled architecture, however, the CMS will also provide access to that same content via an API. This API can then be used by headless apps to get that content and use it however they need. In a hybrid architecture, you typically build a coupled website and then have your mobile app talk to the CMS API to get its content.
In a hybrid architecture, your website will be built using the same language the CMS was built from. The frontend website will still be deployed with the CMS code. Hybrid gives you more choices and can be a good step if you need to move from coupled to hybrid one application at a time.
CMS Platforms That Support Hybrid Architectures: OptimizelyCMS, Adobe Experience Cloud, WordPress and DotCMS
PRO
- Best of all worlds
- Can build mobile and IoT apps
- Good for digital transformation projects that want to eventually get to headless
CON
- Website will be coupled to the CMS
- A website change, could accidentally break everything
- The content modelling aspects of the CMS tend to be website focused, rather than content focused
Decoupled Architecture Explained
The final architecture known as decoupled is a bit of strange architecture in my opinion. Decoupled is really just focused on how your CMS and website talk to each other, so not applicable for omnichannel. Within a decoupled architecture, you still deploy your website and CMS code onto the same server, however, the frontend gets all the data from the CMS using an API.
The thought behind decoupled is that it gives you more flexibility. Having built a few decoupled projects, I am yet to be convinced of these merits. In decoupled, the theory is that if the CMS drastically changes you are more protected from having to do a complete frontend rewrite compared to a coupled architecture.
Personally, I have never seen a single successful project to prove this selling point. Typically within a decoupled architecture, if the CMS API changes you need to change everything. If your website needs drastic change, you need a new CMS instance.
In a decoupled architecture, you tend to be able to use less of the core CMS core APIs which means you need to build more of the front end yourself. Decoupled will mean that you have to deal with the worst aspects of all the options.
You have the same levels of risk when deploying code as coupled but the development and testing time increase. You will also not be able to use JAMStack and static site generation so performance and site stability will not be as good as headless. The website's shelf life will also be the same, so I really struggle to see its merrits!
In decoupled, templating and CMS code are deployed on the same server, however, content is delivered via content delivery API. The API serves as an intermediary between the back and front. The benefit over coupled is the ability to built the frontend using a Javascript framework of your choice
CMS Platforms That Support Decoupled Architectures: WordPress, OptimizelyCMS, Magnolia, and Sitecore
Con:
- Deployments are coupled
- Can not use JAMStack
- Does not take into consideration omnichannel (hosting in particular)
- Can not use the CMS coupled APIs
PRO
- Sounds cool?
As you would expect when it comes to comparing different architectures there is no one solution that is perfect for every situation. Some of the main decisions on which route you should take will include the team working on it, how many resources you have, the programming language that you want to adopt in the future, the number of channels you need to support, and what your legacy stack is built in.
Nowadays a lot of the hype around CMS is on headless. Headless is a great architectural choice, however, it is not the only choice. Websites have been successfully built within CMS systems for many years. Just because an architecture has been around for many years does not mean that it should not be used any more. Pick the approach that makes you happy. Happy Coding 🤘
