A Developer’s Transition from Headful to Headless: Understanding the What and Why of Headless

Many of us have dedicated substantial time to crafting AEM Sites, diligently creating components and authoring content, ensuring that our websites shine on both web and mobile platforms with responsive designs. At a certain point, it might have felt like we had accomplished it all.

However, the digital landscape is evolving, continually improving and expanding. Today, this evolution is pushing us toward embracing headless architectures, where paramount importance is placed on flexibility, scalability, and the seamless distribution of content.

In this blog, we embark on a developer’s voyage, exploring the transition from the traditional headful approach to the contemporary realm of headless AEM. Along this journey, we’ll harness the potent capabilities of GraphQL and Content Fragments, unraveling how they can revolutionize the way we manage and deliver content.

Please note that there are other modes of Headless CMS offered by AEM. More info available on link

What is the difference between headful and headless implementations of AEM?

Source of the image: https://experienceleague.adobe.com/docs/experience-manager-65/developing/headful-headless.html?lang=en

Headful (Full-Stack) Implementation:

In a headful implementation, AEM handles both content management and presentation within a single monolithic system. Here’s how it works:

Content Management: Content is created, organized, and edited directly within the AEM authoring environment. Content authors use the AEM interface to input text, images, videos, and other assets.

Presentation: AEM also takes care of how this content is presented to users. It uses templates and components to define the structure and layout of web pages. These templates and components are tightly integrated with the content management system.

Example: Let’s say you’re creating a blog post in AEM’s headful mode. Then, you’d choose a predefined template that defines how this blog post should look when published. The template might specify the header, sidebar, and overall styling of the blog. You’d use the AEM authoring interface to write the content, add images, and format it.

Headless Implementation:

In a headless setup with AEM, it separates the job of managing content from how it looks on the website or app. This split gives you more freedom to use the same content in different places and styles. So, you can easily show it on websites, mobile apps, or other devices without being stuck to one way of displaying it. It’s like having the content in one box and deciding how to wrap it in different gift wrappers for different occasions.

Here’s how it works:

Content Management: AEM continues to be the content management system in a headless setup. Content authors create and manage content in AEM, but it’s stored in a structured format. These structured pieces contain the content’s raw data without any presentation-specific information. Example: Content Fragments which has a form-based UI to author content.

Presentation: In a headless approach, AEM doesn’t dictate how content is presented. Instead, it exposes this content through APIs, such as GraphQL, to be consumed by any front-end application, whether it’s a website, mobile app, or IoT device. The presentation layer is entirely up to the developers working on those applications.

Example: Suppose you’re managing product information. In a headless setup, you’d create a Content Fragment for each product. This fragment would contain structured data like product name, description, price, and image URLs. A front-end developer working on a mobile app could then use GraphQL to request this product data from AEM and design the product listing in the app, offering complete control over the user interface.

Aspect	Headful Implementation	Headless Implementation	When Headful Might Be Better	When Headless Might Be Better
Content Management	Managed within AEM’s integrated authoring interface. Authoring is easy with WYSIWYG editing.	Managed within AEM but stored as structured format, allowing for flexibility in data structure.	When content needs to be tightly coupled with presentation and quick content updates are essential.	When content needs to be reused across various front-end applications and devices.
Presentation	Presentation templates and components are tightly coupled with content in AEM.	Content is separated from presentation, and front-end applications determine how to present it.	When maintaining a consistent brand and design across the website is critical, and rapid design changes are infrequent.	When delivering content to multiple platforms, each with its unique presentation requirements, is a priority.
Front-End Flexibility	Limited flexibility in adapting content to different platforms or designs since presentation is closely tied to content within AEM.	High flexibility; content can be used across various front-end applications with different styles.	When the website or application has a single platform or is primarily web-focused with a consistent design.	When there is a need for a more adaptable, multi-channel content delivery strategy across web, mobile apps, IoT devices, and more.
Data Structure	Content may lack structured data since it’s closely tied to presentation elements, making it less reusable for other purposes.	Content is structured, making it easier to reuse and adapt for various purposes and different front-end applications.	When content is primarily intended for a single use case and extensive reusability is not a priority.	When content reusability and adaptability across different contexts are critical.
API for Content Access	Limited options for delivering content to front-end apps, often relying on traditional web delivery mechanisms.	Content is accessible through APIs like GraphQL, enabling precise data retrieval and customization for different use cases.	When the website’s content is primarily for human consumption and does not require programmatic access.	When the content needs to be programmatically accessed and tailored for different front-end applications.
Development Effort	Development often involves adjusting templates and components for each presentation change, leading to more back-end development effort.	Front-end developers can independently work on the presentation layer, reducing back-end development effort.	When the development team is more familiar with AEM’s integrated development model and the website’s design is stable.	When rapid development and customization of front-end experiences are needed, and the content structure needs to remain consistent.
Authoring Ease & Instant Preview	Authoring is user-friendly with WYSIWYG editing, and previewing changes is instantaneous.	Content authoring and presentation are decoupled, offering flexibility but may not provide instant WYSIWYG previews.	When content authors require a straightforward, WYSIWYG authoring experience with real-time previews.	When the primary focus is on content reuse and adaptability, and instant previews are not a top priority.
Site Type	Better suited for informational sites	Better suited for transactional sites.	For informational sites that require quick design changes and a tightly coupled content-presentation model.	For transactional sites where user interactions involve multiple steps and require state management.
Page type	Support multi-page websites	Supports: – MPA – SPA with dynamic content loading.
SEO	MPAs* tend to perform better in SEO due to unique URLs, titles, and metadata for each page.	SPAs may have SEO challenges but can implement techniques like SSR and prerendering for improved SEO.	MPAs are preferable for sites with SEO as a priority.	SPAs can be suitable for transactional sites with SEO optimization techniques in place.
Performance	MPAs provide good initial load performance but may feel slower during page navigation due to full-page refreshes.	SPAs excel in providing fast, responsive user experiences after the initial load, but initial load times may be longer.	MPAs work well for sites where rapid design changes are infrequent and initial load speed is critical.	SPAs are ideal for single-page applications that require dynamic, interactive user experiences.

Abbreviations used:

MPA – Multi Page application
SPA – Single Page application

Hybrid Implementation

The hybrid approach seamlessly blends features from both the full-stack (headful) and headless methods. In a hybrid setup, content authoring and management remain within AEM. However, this approach offers the versatility to serve content through multiple channels.

This means that the same or some portions of your content can be simultaneously served on AEM Sites as traditional web content and also made accessible as JSON data through RESTful APIs or content APIs like GraphQL for consumption by other front-end applications. This hybrid strategy grants you the flexibility to adapt to evolving digital demands while maximizing the value of your content across various platforms and applications.

Why is relying solely on responsive web pages for both desktop and mobile not sufficient? What gap does the headless approach fill?

While responsive design has significantly improved the user experience by adapting web pages to different screen sizes, it doesn’t address the evolving landscape of digital experiences. Responsive pages are limited to adjusting layouts, but the headless approach enables tailored content delivery, ensuring optimal user experiences across a wide array of platforms, including web, mobile apps, IoT devices, and more.

Conclusion:

Headful offers simplicity and real-time previews, ideal for tightly integrated content and design. Meanwhile, headless, with its flexibility and scalability, caters to the demands of the modern, multi-channel digital landscape.

The choice between them isn’t one-size-fits-all. It’s about selecting the right tool for the job. Whether you opt for headful or embrace the versatility of headless, you’re equipped to craft exceptional digital experiences tailored to your project’s unique needs. Happy coding!

More info about headless implementation via GraphQL and CF available on:

References used:

AEM Champion Office Hours (September 2023) – AEM Headless