What is Headless Architecture?

Software architecture designs how engineers distribute the logic, code, and data among various application layers. In a headless architecture, most of an application’s code and data layers run on back-end or cloud servers separately from the user interface. This front-end/back-end decoupling (separation) enables engineers to run the same code base on multiple devices, such as a desktop, smartphone, and website.

For most of us, software is a user interface (UI) and user experience (UX). We use the UI/UX to find and enter information, navigate options, vote or register for some service. Our waking lives are in constant contact with some sort of digital user interface. And we expect to use the same application on multiple devices. For example, we might add items to our cart on a mobile device and buy them on our computer.

From an engineer’s perspective, software is the code, data, and logic that drives the UI/UX. Google’s interface is the perfect example. It has the simplest UI: a white screen with a search bar. But Google is not a search bar; it’s a search tool. Google search happens somewhere “behind” its screen. Its powerful search algorithm performs multiple actions on vast internet data remotely and displays the results in our browser.

Engineers call this simple white screen the “front-end” or “head” of an application. One can loosely classify everything else as the middle and back-end layers. Headless architecture refers to an infrastructure and coding structure. It processes all data and logic before reaching the front-end, the head.

What is headless architecture?

Headless systems divide an application’s code into three layers: the front, middle, and back. The front layer (front-end) is the interface we see and use. The back layer (back-end) runs business and other logic, processes data, and integrates with other apps. The middle layer relays requests, responses, and data between them.

These layers perform (a) multiple tasks in (b) multiple processes on (c) multiple machines. Let's explore each of these in some more detail.

Multiple tasks

One key goal is to separate the tasks needed to perform the whole action.

As an example, consider a payment form:

• The front-end manages the display of information, the capturing of user data, and the immediate validation of what a user enters. It handles the visual design and interactivity and navigation of the form.
• The middle layer takes the information that the user has entered and sends it to the back-end.
• The back-end processes the information. During the payment process, there might be extra validation to do. A back-end process, for example, may check if the client has an account. There may also be several trips between the layers. For example, the back-end may need to add delivery and other fees. Then, it sends the new total to the user for approval. The back-end performs this recalculation, while the front-end manages the display of the new price and approval process.

Multiple processes, or decoupling

At the simplest level, headless architecture separates tasks into different processes.

The front-end code builds the form in one process and sends it to the browser in another process. The back-end accesses data and runs algorithms in one or more other processes.

This decoupling is the foundation of a headless architecture, where different processes perform tasks in very discrete parts of the software. Decoupling lets companies use APIs from SaaS products. They can use Stripe for back-end payment, SAP for calculations, and Salesforce for client information. The front-end then sends and receives the back-end data and does all of the display logic.

Multiple machines

In our payment scenario, the company may decide to use one or more computers to perform the tasks. Multiple processes can run on one machine.

A headless architecture usually spreads its tasks across multiple machines. These machines include: cloud servers from SaaS providers, middle layer servers that communicate with and integrate the SaaS apps, and company servers. The company servers process data, make calculations, and build the code for the browser to use to present the UI/UX to the client.

Online companies have servers worldwide to service requests from billions of users. An online application must spread its functionality across many back-end and front-end servers.

What are the benefits of a headless architecture?

While there are many benefits and details, here is a summary of some key advantages.

Scalability of the applications

You can change the screen without worrying about changing the underlying data or functionality. For example, Engineers can work on and upgrade the back-end without changing the front-end's code. Marketers can change front-end web pages in a headless CMS without asking engineers to change any back-end code.

Multiple devices and channels

Suppose the back-end does all the data and logic processing except displaying the data. In that case, it is easy for a company to send the same data and functionality to multiple devices. A mobile app may look completely different from a web application, but it offers the same functionality that a shared back-end may provide.

Multiple UI/UX of the same application

Likewise, by separating the head from the rest, you can create different versions of the same software. Financial advisors might like a certain kind of front-end interface, different from a client’s, but they both look at the same data on the back-end.

Composability

A headless architecture often relies on a microservices-based architecture, which integrates many distinct services. SaaS applications usually provide such microservices. For an e-commerce site, Stripe may provide payment services, Algolia provides search, and other apps provide deliveries, pricing, catalog management, etc. The back-end's main functionality is integrating SaaS apps' application programming interface (APIs).

Maintenance

Engineers leverage these separations of front- and back-end distinct services to simplify maintenance. For example, an engineer can swap out Stripe and use a different payment service without affecting the code of the front-end or the other services.

Examples of benefits of Headless - 3 use cases

Finally, let’s look at three popular domains where headless architecture is used.

Headless CMS

Media companies and e-commerce businesses use headless Content Management Systems (CMS) like Prismic to deliver customer content. Authors and marketers create the content, which is processed on the back-end and published on the front-end.

Headless Commerce

Monoliths succeeded when there were few product upgrades and online retail was simple. Today, to stay competitive in e-commerce, it needs to use a headless commerce architecture for scalability, security, and to provide shopping services on multiple channels.

Headless Business Intelligence

As businesses collect vast amounts of data, headless architectures offer an opportunity to revolutionize how they manage and utilize this data. Headless systems can structure data, which makes the data easy to access for front-end apps. This lets developers create dynamic user interfaces that draw upon real-time data, offering users more relevant and engaging experiences.

Conclusion

Developers have been decoupling and dividing their code for a long time, spreading the logic across machines and over long distances. With APIs, SaaS providers empower a headless division of tasks which enforces a hard division between two principle layers of any application—the front- and the back-ends.

Modern content management systems, with their API-first foundations, follow the headless approach. Traditional CMS platforms are for simple websites. Headless CMS solutions are flexible and scalable. They deliver content to many channels, making them ideal for complex, modern digital experiences.