Headless CMS sounds brutal, right? What happened to its head? Fear no more; I got you covered. We'll look together at what headless is, what other CMS's are out there and why you might choose one or the other. If you have any questions, opinions or musings about this, feel free to drop it in the comments - I'd love to hear your thoughts on the matter.
Just a small disclaimer before we dive in: While I am trying to approach this topic neutrally, I work for Storyblok (headless CMS) - and might be biased here.
Monolithic vs Headless
There are different kinds of Content Management Systems: Headless CMS (like Storyblok, Contentful, Prismic, or many others) and more traditional CMS (think Adobe Experience Manager, WordPress, Sitecore, etc. ) - often called monolithic, regular, or coupled CMS.
A traditional, monolithic CMS usually contains a database for the content to read and write to, an admin interface where the editors can manage the content, integration of reading and writing, as well as the actual frontend that combines the data from the database with HTML - all in one package. This can be great: you got it all from the start and don't have to make as many decisions.
But…
It also means you are making a lot of compromises - if you are trying to do everything at once, you can't excel at the individual tasks. Some of the features included in your (monolithic) CMS will probably be why you chose it - but many others might not (yet be simply part of the package).
Monolithic CMS are also less flexible in terms of the technology used and how much you can personalize the experience. You will likely have to adjust to whatever stack the CMS is built in to make your changes - and even then, not everything might be possible. All in all, a lot of compromises if you want a unique design or set-up, but generally a good starting point for folks without much programming capacities.
Decoupled everything
With a headless CMS, on the other hand, the "head" (i.e. the frontend) is decoupled from the "body" (i.e. backend, content repository, etc.). It has an interface to manage the content and an API to deliver it wherever you need it. The content repository is accessible through a RESTful API or GraphQL API and can display your content to any device type you might want. Instead of doing it all in one place, everything is decoupled - the headless approach focuses on storing and delivering structured content.
Flexible Tech Stack
Headless CMSs are mostly technology agnostic, meaning you can choose what you would like to work with. Instead of adjusting to the CMSs requirements, use what you or your development team is most comfortable with. Since everything is decoupled, this gives you the freedom to exclusively pick and choose the features you need and implement them in the technology you are most proficient in or which works best for your needs.
But using a Headless CMS doesn't only benefit developers - it also helps other departments:
- More independence among the different teams: marketeers and content editors don't depend on developers to implement their content
- Headless is an excellent option for SEO and A/B testing.
- Since everything is in the cloud, no servers need to be managed.
- Decoupling everything improves the security profile.
- There is the freedom to implement a wide range of use cases and channels.
What's the best fit for you?
So, in the end, I guess it - as always - comes down to your needs. There is no definite answer. A headless CMS might likely be an excellent fit for you, especially if you are working with multiple output channels and are experienced with creating your own frontend. If you prefer an out of the box solution with little programming effort and don't mind working with templates, a monolithic approach could be the solution for you.
Monolithic or Headless, what do you prefer? I'd love to hear your thoughts about that - let me know in the comments!
The stunning illustration is made by the fantastic artist @nicolaidiekmann
– go follow him on Instagram. He has got some cool projects lined up this year!