kras99 - Fotolia
An overview of headless architecture design
Decoupling the back-end components of an application is certainly valuable, but what about the front end? This is where headless architecture comes into play.
Twenty years ago, many Agile development methodologies suggested that developers should separate the user interface from underlying business logic. That allowed developers to not only test business logic independent of the interface, but also to reuse that logic for any number of other front-end systems.
Headless architecture takes this concept one step forward: Instead of making just the underlying business logic reusable, headless aims to turn the actual front-end interface into a collection of APIs that various applications and servers can access through abstraction. Let's explore what defines headless architecture, how it differs from other hybrid architectures, when to use it and what to watch out for if you implement one.
Headless architecture defined
Headless architecture represents a specific type of decoupled user interface that is untethered from underlying, back-end business and application logic. This happens through APIs that use HTTP protocols to handle traffic and either XML or JSON for payload management and data transfer.
In headless architecture, there is no standardized user interface at all. Teams that work in a headless system will simply halt development once the API is born. They then suggest that other third-party systems consume and display the interface data contained in those APIs, such as the text for a customer-facing user interface. This practice allows developers to create multiple front ends for various formats (mobile, web, etc.) at once, as well as plug into third-party systems.
A headless architecture example
A wholesale company I worked with had a group that wanted to quickly develop a user interface prototype and connect the back end to their existing systems with web services. They chose a decoupled approach using SOFEA, or service-oriented front-end architecture. Instead of a single computer program that generates the user interface, the graphics were based in HTML and JavaScript.
The actual JavaScript code didn't contain specific application data, but instead made API calls to pull up the headlines, the text, the product numbers, the product descriptions and all the other details pulled from the database. If there were only one user interface, this separation would reflect a basic decoupled architecture, but the company separated the teams and planned to create a mobile version. Their APIs became robust, first-class objects, rather than simply an interface between applications and services.
How headless architecture changes a CMS
Say a company pushes notifications to customers via various e-commerce platforms and IoT devices that require frequent updates. With a headless content management system (CMS), teams can create a single messaging API that can plug into any number of applications, rather than customizing messages for each device and platform type. This content can even integrate with advertising campaigns, where users can pull ads from a CMS in the form of those APIs. If the company needs to change a running ad, all it needs to do is update the ad in the CMS, and it is pushed to all relevant platforms immediately.
Pitfalls and risks of headless architecture
By separating application data from front-end interface components, headless architecture introduces a new layer of complexity. Instead of running a query and putting the results into a form element, like a text box, headless applications need to assemble that information and then store it in an API. The client-facing front end, which could be a website or mobile application, now has to make a request, authenticate the response, interpret the returned results and, finally, render the text box on the user's display.
This series of actions adds more code at every step, which consequently increases the potential for errors. As increasingly diverse sets of client devices and OSes come to consume your application data, you may need to frequently version the API accordingly, which carries the risk of breaking any number of existing integrations. On top of that, the back-end team will still need to support older versions of those APIs in case a rollback is needed to address an error or recover data.
Conway's Law says that software architecture and an organization's team structure will reflect one another. This is equally true with headless, which will quickly lead to separated front-end and back-end development teams. And when teams collaborate poorly or misinterpret specifications, errors are more likely.
For example, the projects where I worked on a SOFE architecture usually had a front-end team create the user interface, while back-end developers implemented the APIs. After that, each team would perform debugging work to see if the user interface was calling the API incorrectly or if the API was not quite exactly returning the expected information. Admittedly, this practice did make it a little easier to isolate problems. You'll have to decide if the extra time required for testing and potential error fixing is worth it.
