Inside Headless CMS
In this article, we will learn about Headless CMS and we understand what are advantages and when it is convenient to employ. Moreover, we will enumerate the actual main limitation. To better understand how and HCMS works behind the scenes I will explain how I design and build RawCMS, an Aspnet.Core Headless CMS with Oauth2, extension plugin system, business logic support. This solution is available on GitHub and released on docker hub as a demo.
What is a Headless CMS?
A traditional CMS combine content and rendering part, meanwhile, a headless CMS is focused only on the content. This may seem a limitation because barely speaking you lose something. The purpose of HCMS is to decouple logic from content making easy change management and decomposing complex application in many components, each one with his single responsibility.
Going in this direction HCMS is something that can replace what actually you are calling backend and save a lot of useful work creating CRUD statements.
HCMS born to create a multi-component application where you can quickly change presentation logic and design, and this is a big improvement when you are working on modern websites or application and you need to restyle\change UI once at a year because of business requirement.
Many vendors sell their product and label it at “HCMS” just because it is decoupled (and because it sounds cool and may drive to a sell improvement..). In my point of view, I’m strictly related to the original integralist definition: headless cms means an API first, non-monolithic CMS, completely decoupled from the interface or other components.
Advantages of a Headless CMS
Why use a headless CMS? I could simply say that in some scenario it can be useful to decouple systems, make easier frontend replacement and speed up development phase, but I feel obliged to explain better using a bullet list.
- Omnichannel readiness: The content created in a headless CMS is “pure” and you can consume in every context you want. If you store some news content on it you can publish on public web site or intranet as well, keeping data entry in one place.
- Low operating costs: Headless CMSs are a product so, once you choose a good one, I expect it will be plug-and-play. Moreover, compared to custom solution, update and bug fixes came for free from the vendor.
- Reduces time to market: A headless CMS promotes an agile way of working. You can involve multiple teams for backend and frontend and this reduces timing. Moreover, because the HCMS area a vertical solution on data storage with API consumption most of the things come already done, so you must focus on data design rather than on technical details (like wasting time thinking about payloads, when you can have Odata or Grahql for free).
- Vertical solution: HCMS do one thing this makes it very easy to learn and maintain.
- Flexibility: Once you pick your HCMS (on-prem or cloud, no matter) your devs can use any language they prefer to implement frontend. This means you can be free to technology constraints.
Limitation of Headless CMS solution
HCMS are quite young compared to traditional CMS so, even if a lot of product borns in last years, most of the product are not so mature to completely replace a traditional API backend. In this paragraph, I would share my experience with the limitations I found. Capabilities may vary a lot based on the specific product and if it is an on-prem or saas solution.
Actually, there is mainly two kinds of CMS headless limitation:
- disadvantages of using an HCMS
- limitation of the product you install
Disadvantages of using an HCMS
HCMS requires to employ multiple teams to benefits of work parallelization. Moreover, as the HCMS doesn’t have any rendering all presentation logic is demanded to the client. This is good for decoupling, but in all case, you have only one consumer decoupling advantages is not so relevant and you introduce more complexity and latency over the data fetch process. Another problem is about business logic. Where to implement? If you want to do not implement into HCMS you have to put it into presentation layer and with multiple consumers you will duplicate it, falling in problems you have when logic is in more than one place. Otherwise trying to put it into HMS you will discover that most cloud solution\products are not so flexible. This introduces the next topic, what are all the HCMS limitations?
Limitations of HCMS
Testing most important HCMS solution I fall in many difficult and the following is the list of the most common limitations. Take into account that this depends on the product, someone may have or not but generally speaking most are quite common.
- Authentication against external provider: most solution does not allow to authenticate users against an external system. I’m speaking about the most common scenario where you have a central authentication system and all parties pass user token\ticket to operate on behalf of the user. In other words, if I have an oauth2 server I want to authenticate on the frontend and make calls with a token to all application of the intranet, not only the HCMS, and being recognised as myself.
- Non-standard output format: some uses graphql or Odata and this is good because give a standard approach to the data consumption. The problem is that “some” doesn't mean “all”, so you have to take care of this choosing your HCMS.
- Business logic: In most cases, there is no possibility to define at runtime the business logic, and in some cases neither extending the core application. Extensibility: It’s hard to find a solution where you can write your own code and alter business logic or add extra stuff. This is in part because many vendors design their HCMS as dumb data storage and in part for the complexity of managing extensibility.
When and where use a Headless CMS?
Headless CMS is a great opportunity but there we have to understand what is the best scenario to employ it to optimize cost\benefit ratio. The matter is that using regular HCMS, the customization is quite limited so in case you are not in the right scenario it will be hard to blend the HCMS to achieve the business requirement. Moreover, using it just like a bare data storage make it meaningless things.
When using an HCMS is convenient:
- a lot of changes on UI during the time
- a lot of application that shares the same information and one team that manage it
- you have few business logic over data
- you can employ multiple teams (be+fe)
When do not use an HCMS:
- there is a vertical solution that fits your need (es. you want a blog use WordPress)
- you have a lot of business logic
- you are not the master of data
Points of interest
HCMS are great because they decouple by design presentation layer from the backend, and that’s a good driver. HCMS are a great opportunity but, nowadays, is hard to employ in the real project except where there are very simple business logic and well-defined behaviour. It would be great to overcome these limits and employ as a “general purpose backend”, where you spend time only to teach the system about data schema, relation and tune only what is non-standard. The matter is that this is, generally speaking, hard to implement (thrust who try to do it).