What is headless architecture, and is it a new normal?

Q: What is headless architecture?

A: It’s where the front-end is decoupled from the back-end.

In headless architecture, you have one central back-end system, but no ‘standard’ client-side front-end. The front-end is agnostic.

But how does that work, exactly? Here’s an “ELI5” overview.

Headless architecture explained

Typically, an organisation has data and content that must be transferred from channel to channel. This can be a messy process, comprising a tangled web of back-ends and front-ends – and a headache for developers.

Headless architecture seeks to streamline. Let’s use a headless CMS as an example.

In a headless CMS, there is only an admin back-end area. There’s no classic client-side front-end. Instead, you create your own front-end; a front-end completely fit for purpose rather than a fixed one.

With this setup, the content you publish is raw. It can be published anywhere, through any framework. You’ve gotten rid of one, set, front-end delivery layer. Your CMS, meanwhile, has become a content-only data source.

This leaves developers free to build as many front-ends or ‘heads’ as they like. And these ‘heads’ can present the data they’re served in the way best suited to the channel.

For instance, then, developers can facilitate a custom front-end for an online site, for mobile, for IoT devices, apps, kiosks, smartwatches, etc.

To retrieve the content for each channel, the headless CMS responds to API calls.

Whether you hear people talking about a ‘headless CMS’, ‘headless commerce’, or ‘headless architecture’, the core principle remains the same. Information is delivered via API down various channels, rather than tied to a singular, designated front-end.

What is headless architecture good for?

So, we now know what headless architecture means. But what is headless architecture good for?

Headless architecture is popular for the agility and adaptability it enables. It makes it easier to introduce new user interface (UI) tools and functionalities. It makes it easier to change existing components. And it makes it easier to implement small, incremental changes.

This is in comparison to, for instance, a waterfall architecture approach. Here, changes involve adapting the whole system, rather than tweaking the one ‘head’ that needs the changes.

Headless architecture is also more flexible in terms of scalability. Rather than scaling the whole application, developers only need to scale the features/components involved.

Finally, there’s the level of freedom that headless architecture gives front-end developers. Going ‘headless’ means that they can create and present content no matter the device or platform the consumer chooses to use.

What is headless architecture not good for?

For all its flexibility, headless architecture is not without its challenges.

Decoupling the user interface adds complexity to the system. It adds APIs, extra steps for queries/requests to go through, and so more code. This, naturally, translates to a slightly higher chance of flawed code and bugs.

Front-end teams may also find adjusting to headless challenging. Particularly when it comes to content that simply doesn’t suit a medium.

Or, in cases where teams are still adjusting to the change to headless architecture, developers can fall under unrealistic expectations. For instance, if a team lead forgets that the content will need to be tailored for several devices, not just one.

A new normal?

So, TL;DR: what is headless architecture, and is it the new normal?

Headless architecture uses specialised back-ends to wrap up all the business logic / functionalities in a set of APIs. Any front-end channel can hook into these APIs, interact with them in custom ways, and provide the data presentation and customer experience desired for that channel.

The question that remains is whether headless architecture will become the new normal. The benefits of scalability and adaptability cannot be ignored. Particularly in an industry as changeable as the tech world.

In short, we predict that headless architecture is likely to become a mainstream option.

For those wanting to take the leap — or that have already made the change to headless architecture— you can find out how ThinkAutomation supports headless here.

Useful links

What are malicious API calls, and how can you combat them?

What does low code mean? A simple overview in 500 words

ELI5: What is an API?

ThinkAutomation and headless architecture