How to accelerate content production with Adobe Experience Manager headless
Over the last eight years, there have been big changes in the way people consume content, which require businesses to adapt and change how they manage and deliver their content. This is my headless journey working with Adobe Experience Manager and related Adobe products to find the best practice for content production. In this article, I will share my journey with Experience Manager and best practices on content production with headless as well as hybrid approaches.
Today, people interact with a brand in multiple digital channels and expect these experiences to have a highly personalized touch. As mobile devices have become a major way people consume web content — and for some groups, the default — these websites have evolved to support multiple form factors with the same content from mobile to tablet and desktops. This transition primarily drove changes to the layout and design of the site, but the content itself didn’t need to change. The same content could be easily served to these devices as they were all still using a web browser to access the content.
With a headless content management system (CMS), companies can build their front end using any framework of choice and create blocks of content that can be delivered in any channel and be reused everywhere. This allows companies to create exceptional experiences faster and more effectively.
What is headless, and why might you use it?
In a headless CMS, the back end is completely decoupled from the front end, separating the management of the content and the presentation to the end user. The CMS exposes the data via one or more APIs, which the front-end systems interact with to retrieve the data when needed.
From an implementation perspective, a headless system empowers you to work “front-end first” by using mocked data in the same format that the back-end systems will eventually produce. This allows your front-end code and applications, as well as back-end content, to be reusable across different channels. Each side of the application can be built independently and in parallel.
Separating the data from the presentation gives the front-end control over how it interprets the content and converts it into something the end user will see. This makes the content reusable, as different front ends — like a website and mobile app — can read the same data and use their own methods to convert it into something the user can view and interact with.
As the source data for all front ends is the same, any changes to the data will be reflected everywhere, ensuring it only needs to be made once and cannot become out of sync. This empowers marketers and content authors to concentrate on creating the best content for their end users with the knowledge that it will be consistently displayed. As we move toward more personalized experiences, this will continue to become more important as the scale of content creation increases.
By breaking the hard link between the back end and front end, teams can start to build new UIs without having to touch the back-end systems at all. This makes moving to new technologies or implementing new functionality simpler.
Front-end teams are free to choose the technology which fits their situation, target device, or use case the best. So long as the back-end system provides a consistent API, the front end isn’t affected by how or where it’s managed.
Where libraries of existing front-end components exist, they can be shared across different implementations, which may connect to different back-end systems. By using the same front-end components in all cases, teams can ensure a consistent look and feel without the end user being aware that different systems are involved in the management of these different platforms.
Have questions on how to use headless in your organization? Meet with our community of advisors who are experts in headless implementation. You can share knowledge and get answers and best practices. Start a discussion here.
The value of Adobe Experience Manager headless
Adobe Experience Manager headless CMS gives you all the tools you need to manage your content and make it available via APIs to any number of front ends via both JSON and GraphQL. The platform is also extensible, so you can add new APIs in the future to deliver content in a different way without needing to change the underlying content itself.
Experience Manager headless has a high amount of built-in flexibility. It is one of the only solutions in the market that lets organizations adopt headless without compromising the marketer experience. Even in headless implementations, marketers have access to a robust WYSIWYG editing interface, giving them the power to create exceptional experiences while reducing the load on dev and IT teams.
Plus, the SPA Editor in Experience Manager empowers editors to seamlessly edit the content, while developers find it easier to build using single-page application (SPA) frameworks. With server-side rendering of the first page of a SPA, pages load much faster and content will show instantly when information is requested.
Flexibility doesn’t end there — Experience Manager headless helps organizations remain ready for the future by supporting evolving use cases. This allows teams to go live with headless today while retaining the ability to expand to hybrid or traditional, full-stack experiences in the future without needing to re-platform.
The DAM functionality built into Experience Manager allows storage of images, videos, and other assets within the same content management system, which can be made available directly or as part of the data via APIs. It also supports out-of-the-box integrations with other Adobe products, such as Adobe Target for personalization, multivariate testing, and A/B testing, as well as Adobe Dynamic Media for enhanced image and video serving.
Pure headless vs. hybrid headless
Now let's dive into the differences between using a pure headless implementation and using a hybrid approach.
Pure headless scenarios make use of Content Fragments in Experience Manager to hold structured data. Content Fragment models are created that define the set of data a given fragment type will hold — for example, a blog may require a title, description, and body copy.
Content Fragment references can be used to link in data from other fragments, like office locations or author details, avoiding duplication of that data and ensuring it will remain up to date everywhere it is referenced.
The GraphQL API allows the front end to perform queries against the content management system to retrieve the data it needs — for instance, getting all blogs related to a specific subject or by a given author. If the content authors publish a new Content Fragment that meets these criteria, all future query results from the front end will include this new item.
Hybrid headless content management makes use of both headful and pure headless methods of content management. The use of Experience Manager Core Components simplifies this, as the components support both traditional HTML and headless rendering. In turn, this allows the same Experience Manager components to be used in all contexts. Where page authoring is already happening, this gives a path to extend the usage of these components for additional decoupled use cases.
In the hybrid model, page-level authoring of the structure and layout of content continues to be possible for content authors where needed, allowing them to control the positioning, size, and more of their content when it is displayed, giving them a preview of this directly within the content management system.
In this mode, you have the flexibility to decide which areas of the content should remain fully headless and managed via Content Fragments, and which areas should allow more content authoring control. This ensures you can continue to benefit from content reuse while also giving the content authors the level of control they need.
In my view, when one of the endpoints for your content is a website, the use of a hybrid approach to headless content management makes a lot of sense. You should consider carefully to determine the different types of content that are managed to ensure you’re able to remain efficient while also maintaining the desired level of authoring control.
Lessons I’ve learned from headless implementation
To give some more insight into how headless can be implemented, I’ll share some information about how it’s been done for one of our retail clients. This setup fits their specific needs and technology stack, so it isn’t necessarily a blueprint for everyone — but it should give you an idea of a real-world use case.
The initial scope of the project only included web content management with a specific desire to move to using React-based components with the content management system and decoupling it from the end user-rendered web app. The ability for content authors to control the page layout was also a key requirement due to the large number of different page types being managed and the high rate of change of this content.
We built a React web app, which supports server-side rendering and reads its content from a cache within the clients’ front-end systems. When content is published from the CMS, the data within the front-end cache is updated and the content delivery network cache is flushed to ensure new content will be immediately visible to end users.
Experience Fragments within Experience Manager are used extensively by the content authors to create blocks of content that can be reused across the site as well as being exposed to other web apps to embed, for example, during the checkout process.
Content Fragments are currently used to manage digital offers and header and footer content like navigation, social links, and more. Soon, mobile app content will also be managed via Content Fragments along with data related to health services which can then be exposed on web pages via a component or directly with the app.
Start your headless journey
Whether or not you’re currently managing content for multiple endpoints, moving to a headless approach to content management is a sensible way to go. It provides flexibility for the development teams to use the technologies that fit their approach and target environment without requiring changes to the content management system. Be sure to consider whether a pure headless setup fits your ways of working and needs, or whether a hybrid approach would be more appropriate.
If you’re wanting an enterprise-ready content management solution that supports headless, headful, and hybrid setups all within the same platform, Adobe Experience Manager delivers the best of both worlds. With its built-in DAM capabilities, you can also centrally host all your images which can then be made available either directly or via other services such as Adobe Dynamic Media via out-of-the-box integrations.
If you’re ready to learn more in-depth about using Experience Manager headless, check out these headless tutorials.
Test drive AEM headless CMS today and sign up for your free trial here!
Martin Noble has been working in IT for over 18 years, with the last eight years focused on Adobe Experience Manager and related Adobe products. In his current role as CTO of ecx.io (part of the IBM iX family in the UK), he manages a growing team of skilled architects and developers and continues to work day-to-day with clients to help them realize their content delivery dreams. Martin has a passion for technology and exploring new systems and how they can be used to improve and enhance the content creation and delivery process.