outubro 23, 2017

Headless choices enable changes

The problem with CMS

The first question you should ask when building a new website is: “Will we be able to replace it?”. It’s hardly comforting to have to consider that the nice new website you’re building will one day be out of date, but unfortunately that doesn’t mean that it won’t happen. When you fail to consider a website’s lifecycle is when you end up creating hard-to-replace solutions that require separate migration projects to get away from.

But imagine if you could replace parts as you go along instead of having to carry out major migration projects every 5 to 10 years?

For the last couple of years we have talked about using “microservices” as a way of laying the groundwork for changeability. By building small, independent services that talk to each other via clear interfaces, you make it possible to change, add and remove services without disrupting the whole.

Traditional CMS

The problem with the established content management systems (CMSs) is that the code we write for our webpages executes as part of the CMS; in object orientation terms, you inherit from the CMS instead of using it. This creates problems:

1. The code you write will be tightly coupled to the CMS, frequently even to a particular version of the CMS. This makes it complicated to upgrade the CMS or replace it. The code also needs to be written in the same language that the CMS is written in.
2. There is no separation of data and presentation. The CMS manages both the content and the rendering, which makes it difficult to reuse content for multiple channels.

Not only that, but Technology Radar, the prestigious publication put out by ThoughtWorks, has advised against using CMS as a basis for development since 2014.

Headless CMS

For a few years now, the trend has been to use what is referred to as a “headless CMS”; that is to say, a CMS that is not responsible for how the content is presented. In system administration, systems that do not have a graphical environment are traditionally known “headless,” which is why the expression is used in this context as well.

A headless CMS gives editors and administrators an interface for managing content, users, permissions, etc., just like a traditional CMS does. After that the content is available in an API, usually in JSON format.

Architecture with a headless CMS

The architecture looks different with a headless CMS:

When you use a headless CMS, you call it as a separate component, instead of having your code execute in the CMS. There are several benefits compared to traditional CMS:

1. You can use the content in multiple channels.
2. The web application can be written in any language, irrespective of the language the CMS is written in.
3. Upgrades to the CMS do not have a direct effect on our code.
4. The CMS and application can be replaced separately

A headless CMS also makes it possible to use other architectures. One example, one that Valtech used to build the site for the International e-Sports Federation, is to take advantage of the ability to pre-render HTML pages.

If you build webpages that look the same to all visitors, there’s no reason to render them dynamically. Instead, you can generate the entire site as static HTML files and have a web server serve the files directly. This makes for a simple architecture that is also able to cope with high demands in terms of performance and security.

Changeable data

Until now, we have only discussed the organisation of code in architectural terms, i.e. what handles data. In order to create a flexible website, you also need to make sure that the data you store is changeable.

In traditional CMSs, all data is stored in a shared data model – the page. No matter what content you handle, you only have one model of the data, which entails certain problems:

1. Data has to be arranged manually, for instance using a page tree.
2. Changing and migrating the data requires manual copy-paste.
3. Difficulties customising content for different platforms, as discussed above.
4. Content translation management becomes more difficult.

A better option is to model the content data according to what it actually is, just like we do in relational databases for example. Instead of talking about an “Event page” for content related to an event for instance, what we do is model an event with the attributes that the event has. What the actual event page looks like is not the responsibility of the CMS; this is governed by the platform on which the content is presented.

This means that the content model is defined according to the actual model instead of being adapted to the model offered by the traditional CMS – which also often happens to be unknown.

Usually the content is retrieved from a headless CMS via an API in JSON format, which makes for considerable flexibility in terms of how you use the data.

Summary

A headless CMS makes for a better fit in a modern microservice-based architecture than a traditional CMS. If you also choose one that allows content modelling at a more granular level than “page,” you create a solution that is well positioned to cope with future changes.