Building Flexibility and Streamlined Internal Process with Hybrid Headless in Adobe Experience Manager

Organizations that create a lot of content to be used across sites or different applications can use a hybrid headless approach with Adobe Experience Manager (AEM) to add flexibility without sacrificing content authoring capabilities.

If you've done anything with a Content Management System in the past few years, you've likely heard the term "Headless." Headless is used to describe the concept of storing the content within one system and consuming that content for display within another system. The "body" is stored in the CMS while the display or "head" is managed in a different system, leaving the CMS as a "Headless CMS."

Going headless can offer several advantages over a traditional CMS setup. A primary advantage is the flexibility afforded when content can be consumed across various channels and disparate display systems. For example, content may be consumed for display on a website on desktop and mobile, while specific content details can be pulled into relevant sections of a mobile application. Headless systems typically allow as much or as little of the content to be consumed at one time as desired.

When utilizing AEM for headless content, you're able to author the content with regular site authoring in addition to serving it to other systems as headless content. Using AEM to author your content will also allow you to structure and layout your content, and your "head" can use that structure and layout information, allowing authors to have greater control over the site's appearance.

Similar to the previous advantage, your content delivery is also decoupled from the CMS technology. This is useful when multiple teams specialize in different technologies. A team consuming the content for a particular purpose does not need to have any knowledge of the underlying system serving the headless content. This can allow for team efficiency and reduced training overhead.

Considerations for Going Headless

Every project and situation is unique, and our own experience with implementing Headless solutions reflects this. No two implementations we've crafted have been identical. Some of our primary considerations when designing a headless site include:

• How critical are performance characteristics like site load time, latency, and cacheability to your site?
• Is the site an application that is going to be primarily driven by complex business logic, or a content site that is primarily driven by content authoring?
• Which systems are best suited to being the source of truth for various aspects of your site?

Examining the performance characteristics of the site can help to determine which technologies to use for the front-end, CDN, and caching strategies. The results of these considerations may even be multi-faceted, as was the case with a recent web application we developed that consumed content from various sources.

While content from some sources needed to be served fresh with minimal caching, some of the sources could wait a full day before their content updates were reflected on the site. Carefully considering the needs here can go a long way toward driving site performance and efficiency and also keeping hosting costs down.

Applications that are primarily driven by complex business logic are typically better suited for development in a system like React, Angular, Vue.js, or any other technology that includes programmatic state management, routing, and navigation. Sites that are more content-focused can use the SPA support that is built-in to AEM. With the built-in AEM support, the routing is more focused on the page hierarchy and content than it is on business logic. This makes the built-in AEM support a fantastic option when building contentful sites.

Identifying which system is best suited for being the source of truth for a particular aspect of your site is an important architectural consideration that can have far-reaching impacts. This is reflected in a few of our recent projects where some of the content has been sourced from profile-management systems, instead of trying to update the business processes to include the authoring of that content within AEM.

As another example, we've created some hybrid headless commerce solutions where the commerce aspects have either lived completely within Adobe Commerce (previously known as Magento), or where we've communicated with Adobe Commerce via APIs and kept content within AEM. The primary consideration in each of these cases was simply: which system is best suited for being the single source of truth for this content or logic?

Consider Headless Content Delivery with Adobe Experience Manager

Headless content delivery is a fantastic tool for some situations, though it's not warranted in every case. Careful consideration of the required page performance, sources of truth for each type of content, and which system(s) will render the content to the end-user are all important architectural concerns with no single correct answer.

While going headless may not always make sense for a specific scenario, considering future growth and additional delivery platforms may help make the case for going headless today. Having the option for decoupled content delivery provides additional flexibility that can make the difference over the long term.