Just very briefly in advance, you are currently on a website which uses a headless CMS system in the background.

Content Management System (CMS)

Classical CMS, or also called Monolithic, regular, coupled CMS, have revolutionized the editing of content on websites. Thanks to them, even non-web developers can create, customize and remove content on a website.

1. Structure

For classic CMS systems, such as: Wordpress, Drupal, Joomla, Magento or Typo3, to name a few, it is an all-in-one solution. They all have a database, an admin backend area and a frontend area. Content creators can create, edit and delete blog articles in the admin area. However, the visitor to the site is only shown the frontend area, which in turn is also configured in the admin area. Architecturally, the two areas are one big system, from there comes the name Monolith.

2. Advantages

This also brings advantages, for example, only a single system must be installed to set up a full website with admin area for authors. Most large CMS's run PHP, a programming language that runs natively on a cheap web server and does not need to be compiled. This brings us to another advantage, the costs can be kept extremely low. Nowadays, even the last hosting company offers one-click installations for CMS systems like Wordpress. The installation needs no expertise and can be done by anyone and usually takes only a few seconds.

3. Disadvantages

But enough of the advantages, the regular CMS systems are slowly becoming obsolete and also bring some disadvantages. For example, there is the problem of PHP. Technically PHP is a programming language but it is not really taken seriously among developers. Security problems and an outdated syntax are only two problems with which PHP has to fight for years.

The other is the hard technological coupling of the front-end area with the admin area. If the CMS system uses PHP, the frontend area must also be written in PHP. If you want to set up a separate mobile app and access the same data, this can only be done in a roundabout way and is more complex because the CMS is not designed for such cases. Possible but always something buggy.

Headless CMS

An increasingly common term is Headless CMS. Headless CMS systems are slowly replacing an ever-growing part of the classic CMS systems. 

1. word derivation

The word Headless, in German headless, comes from the fact that many look at the frontend area as the head and the backend so the admin area as the body. So you want to say that there is a decoupling of the front- and the admin-area, the two systems are completely separated from each other. The frontend can be deployed with X any programming language on Y any hosting. The connection between the two decoupled systems runs over an API interface like REST or GraphQL.

2. What is an API interface

An application programming interface is a connection between applications. It is a kind of software interface that provides a service for other applications. An always constant defined standard, which describes how such an interface can be built and used, is called an API specification or API for short.

Two widely used standards for web applications are REST (Representational State Transfer) and GraphQL. REST was considered the only standard for a long time. GraphQL which was launched by Facebook, exists since 2015 and slowly finds more and more application areas.

3. Headless

The sole focus of a headless CMS is to store and provide structured content. It allow the collaboration of "content creators" on new content.

Imagine a classic CMS system with a database and an admin area without the frontend area. Additionally, a headless CMS has a well-functioning and most an automated generated API interface out of the box. If a new entity is added in the admin area, an identical API interface is also provided in the background to access the data from the external frontend application.

The gained decoupling of the two systems may initially be seen as additional work, but has the distinct advantage that on both sides can be used appropriate technologies, which allows one to provide faster, more secure and for the visitor of the page an increased user experience. Which in turn can have an impact on better marketing and stronger customer loyalty.

4. Development and hosting

Yes Okay, a separate frontend with independent technology choice is nice, but what about the development costs and the additional hosting?

That is a very good point, two systems also means you need two different hosting places to run them. Also you need to maintain and monitor two systems. So multiply everything by a factor of two? We say no, of course there are additional costs and additional effort due to additional hosting and setting up the additional frontend. But the effort which is saved on the side of the CMS to build up and configure the frontend area can be added to the external frontend. And if we consider the later extension and scaling possibilities, the initial additional effort is justified. Generally we can say from experience that an implementation of a functionality in an existing classic CMS system takes more time than with a decoupled headless CMS system with external frontend.

Conclusion

For those who want to use a single page application (SPA), as a frontend technology and still do not want to do without a CMS, a headless CMS is exactly the right thing. A software should do exactly one thing and do it extremely well. With the decoupling of the frontend area from the CMS system, we have achieved exactly that.

The whole thing may look a bit technical at first glance and you might wonder if all this is necessary at all, we say clearly yes, it definitely is. Any improvement in user experience can work wonders. Happier visitors stay longer on site and happier developers write higher quality code. A classic win-win situation.