Cloud Nine explains headless: Is headless right for my website?

In this blog series, I discuss the concept of headless and answer some questions that I am often asked in my role as a developer. We've previously defined and highlighted some of the benefits of headless , and in this post we'll talk a little more about why you want a headless website and some things to consider if you want to go that route.

Yes, headless is still relevant

In the context of the web, headless has been hanging around as a clear trend for quite some time now, and it has shown no signs of slowing down. Here at Cloud Nine, it has usually been us who have tried to explain what it is and why it is good, but lately it has also started to appear as a requirement from the customer side early on in discussions. It shows that there is a wider knowledge about headless and what it can bring, and this in turn means that this trend will probably only continue to grow stronger in the future.

My view is that above all there are a few things that make headless attract interest outside developer circles, perhaps primarily flexibility and interchangeability. Simply that you see value in being able to make changes. Both in that small changes can be made faster thanks to a more loosely connected system, but also that you can theoretically replace rather large building blocks in the system without having to do such a large overhaul in general. It is seen as a more future-proof way of working, with less risk of painting yourself into a corner.

Another factor that should not be underestimated is that many modern websites offer a very pleasant experience by using one of the major Javascript frameworks, with React at the forefront. The benefits in perceived speed, seamless navigation, and greater freedom when designing interactions on those types of sites appeal to many. To achieve this well for a larger site, headless is enough to be considered a requirement.

Decisive factors for choosing headless

So then say that you think all of the above sounds good. It is clear that you want flexibility, faster changes and a hip React site. But if that is what you want out of your site, what do you need to fulfill in order for it to be implemented? In principle, nothing special is required, but you should remember that it is a slightly different mindset than the more traditional website. It can have an impact on a number of things, where it is good to have some insight from the start on, among other things, the following:

Does the development team have headless experience? Not an absolute requirement, of course, but it can help you avoid some pitfalls. It is quite easy to "accidentally" build your headless solution according to exactly the same mindset as a traditional website, whereupon you lose some of the benefits of flexibility.

Are those who will work with the content of the website on board? Often it can be a slightly different task to work with content when it is not linked to a specific presentation, for example it can feel a little less free, as everything but the most basic design is generally controlled by code rather than editors (leading to a consistent presentation of all content).

Have you chosen one (or more) platforms that are suitable for headless? Most major CMS and eCommerce platforms today have some form of support for headless, but it's still worth keeping in mind. It doesn't have to be a "deal-breaker", but if your platform isn't ready for it or doesn't have good enough support, you should be aware that it may require additional development, or that, in the worst case, you might have to rethink your choice of platform. It should also be remembered that there may be things that are perceived as built into a platform, but which are not automatically included when building a decoupled application. The latter mainly applies to platforms that are not built for headless from the ground up.

In summary, you can probably simply say that headless entails a slightly different way of thinking, both in the development work and for those who will work with the finished product. However, I would say that most of them, perhaps with the exception of a start-up phase, become more straightforward once you are up and running, thanks to the clear division of responsibilities.

In the next post, I will take a closer look at "microservice architecture", which is often mentioned together with headless, as well as mention some brief thoughts about the future in these two areas.

/Ronnie Hillgren, System Developer