Going Headless: A CMS Story, what and why go headless – Part 1

If the context was Harry Potter, we might say going headless was a failure for Nick, but our context is Content Management Systems (CMSs) and going headless in this context can be a huge win for multiple reasons, from team productivity to app performance. However, if you don’t need to go headless, and you try, then your project could be a failure in lost time and costs. Let’s go over what headless is.

Describing headless 

The backend 

Headless is a simple concept, it’s taking any CMS and stopping it showing any views to a visitor, so no:

• HTML
• Design
• CSS
• Buttons
• Images
• Actions

or anything else the visitor might want. The CMS has only a login and the management of content, nothing else. This keeps different concerns separated, i.e. Separation of Concerns (SoC). Another way to describe a headless CMS is there is no FE (Frontend), it’s all BE (Backend).

To ‘see’ any content we must use an API (Application Programming Interface) usually transported in json (JavaScript Object Notation) or XML (eXtensible Markup Language).

The above is not the only way to create an API for example the API can access the DB and sit on a separate server and/or the DB may be on a cluster or may other setups for security or performance, but this to simplify things we'll stick with this setup. Comment if you'd like to know more about more advanced server setups.

There are many types of API including SOAP, REST and GraphQL we could use, but REST is probably the best to use as it works in the browser with no extra programmes and is simple to understand. However, the choice will usually depend on the CMS you have chosen. Your FE should be able to consume any type of API, but once this decision has been made it should not be changed as it can be very difficult to change after development has started.

Even going headless a CMS will still have a: 

• Database to store the content.
• Secure method to login to change content.
• Method to format the content with things like bold, italic, centre text, etc.
• Method to change hidden or meta content.

There may also be other parts to the CMS like:

• Changing the paths / URLs
• Different types of User to do different things
• Changing menus
• Changing ‘blocks’ or ‘sections’

And lots of other functionality a CMS may do. What you may loose by splitting the FE and BE like this is any ability to 'see' the changes as you make them.

The Frontend

The second half to a headless system is the ability to show the content to the visitor, this is the FE (Frontend). The FE has historically been technologically minimal, but complex in design and usability i.e. looks pretty, but simple. Its job was to load the page, then pull in the content after the basic page had loaded. 

We had a few ‘tricks’ to make it look like this all happened at once, like hiding the page until we had everything loaded then showing the page. In most cases it was as slow or slower than the CMS views, so headless was only an option in edge cases like splitting teams between Backend and Frontend or we needed multiple frontends like:

• apps on multiple devices
• app & website
• multiple websites using the API

As time has gone on, the FE has become more technical as has become more performant and the UX (User eXperience) becomes easier for the visitor.

Today, the Frontend has its own server that does a lot of the rendering before sending to the client device. So instead of waiting for content, the page already has the content before sending the page to the device, this is known as SSR (Server-Side Rendering).

Pros and Cons of Headless

There are several reasons for going headless or deciding not to, let’s go over a few.

1. If you are a company with multiple teams, you can have a team/s focused on the Frontend and a team/s focused on the Backend. However, this means new functionality is split between teams. This can be a good idea, or a bad idea depending on organisation. If you do this, you will want to look at ‘contracts’ between the frontend and backend.
2. If you have multiple channels using the same content e.g. an Android App, an iOS App, a website then going headless allows you to use the same content and quickly change content across channels. However, you are forcing exactly the same content for the different channels and will need a ‘published on’ field or similar for when you need to have content for specific devices / channels.
3. Cost / Time. Everything is doubled. Work is done on Frontend and Backend, hosing is for Frontend and Backend. Also security is doubled, you would have to secure both sides. You must take this into account when deciding to go headless.
4. Performance – This is where going headless shines. At the time of writing there are no CMS systems that are as fast as headless (if both are done correctly).

In summary

The choice here is a difficult one, but if you are looking for the most performant option, headless is probably the way to go, however, if you are looking to keep costs down you are probably best to stick with an all in 1 CMS.

If you are interested in how to make a headless website / system / webapp, check back next week for the second part.

As usual if you have anything you’d like to say please comment and if you are looking for more information on this leave an email or contact us and we’ll get back to you.