In Adobe Experience Manager (AEM), what is a “headless AEM implementation”? And is it as important as AEM cloud and AI support?

Headless implementations

First, let’s define a headless implementation.

In general, “headless” refers to the following:

“Headless implementation forgoes page and component management, as is traditional in full stack and hybrid solutions. Instead it focuses on the creation of channel-neutral, reusable fragments of content and their cross-channel delivery. It is a modern and dynamic development pattern for implementing web experiences.”

The concept of fragments, which we will discuss later, is important to headless implementations. If you create a fragment with the basic information you want to convey, then that fragment is deployable across a variety of channels, such as emails, web pages, or mobile web pages. And if the fragment changes—for example, if the fragment contains an image of a purse, and the designers modernize the purse design—then it is extremely easy to instantaneously change all channels that use this fragment. If the purse was stored as multiple separate pieces of content for all the channels, then you would have to manually change all the pieces rather than just the single fragment.

While headless implementations are available today, they will only become more important tomorrow as website developers must distribute more pieces of content across more channels. If you haven’t moved to headless implementations already, you will need to do so in the future to keep up with your competitors.

Headless implementations in Adobe Experience Manager

Regarding Adobe Experience Manager, I have alluded to headless AEM implementations before. For example, I’ve noted that “AEM’s GraphQL supports headless (multi-layered) implementations and manages content fragments.” I’ve also noted the usefulness of headless content in omnichannel messaging.

What does this mean for AEM developers?

“AEM Headless is a CMS solution from Experience Manager that allows structured content (Content Fragments) in AEM to be consumed by any app over HTTP using GraphQL.”

Content fragments

Headless AEM implementations use content fragments. As I explained previously, content fragments are undesigned text and images that can be applied for any purpose. The content fragments are not “designed” until they are applied to a particular channel via the AEM GraphQL API.

A single content fragment can map to multiple assets.

In a headless AEM implementation, one content fragment can link to multiple assets.
One content fragment, multiple assets. From the Adobe Experience League.

If a content fragment displays in an email, it has one design. A web page display of a content fragment may have a different design. A content fragment on a MOBILE web page may have a completely different design.

In a headless AEM implementation, a content fragment can appear in multiple channels.
From Adobe for Business.

Again, a change to the content fragment automatically ripples through all assets that use the fragment.

AEM GraphQL API

For a headless AEM implementation, you use the AEM GraphQL API, an adaptation of the open source GraphQL suited for AEM content fragments.

The basic GraphQL optimizes API queries:

“GraphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your data. The GraphQL specification was open-sourced in 2015 and has since been implemented in a variety of programming languages. GraphQL isn’t tied to any specific database or storage engine—it is backed by your existing code and data.”

The Adobe implementation, AEM GraphQL API, is tailored for use with AEM and content fragments in a headless manner. This includes automatic schema generation, optimized data types, and AEM-specific security mechanisms.

But what advantages does the AEM GraphQL API provide?

Using the GraphQL API in AEM enables the efficient delivery of Content Fragments to JavaScript clients in headless CMS implementations:

  • Avoiding iterative API requests as with REST,
  • Ensuring that delivery is limited to the specific requirements,
  • Allowing for bulk delivery of exactly what is needed for rendering as the response to a single API query.

To enable GraphQL API queries for Content Fragments, you must first configure a GraphQL endpoint. Once that is complete, you can use the built-in GraphiQL Integrated Development Environment (IDE) to create, test, persist, and publish your queries.

Again, while AEM content fragments and the AEM GraphQL API already exist today, they will become more important tomorrow. Therefore, you will realize future benefits if you start using these features now.

Future-proof your AEM development

Of course, the headless AEM implementation is not the only key driver of Adobe’s advances. Cloud deployments and artificial intelligence also improve the AEM user experience.

But when you combine the power of cloud (and on-premise) deployments, smart use of artificial intelligence, and the flexibility that a headless AEM implementation provides to your messaging, Adobe Experience Manager emerges as a true revenue driver, now and in the future.

Do you need help understanding and implementing content fragments, the AEM GraphQL API, or other Adobe Experience Manager features? KBWEB Consult is ready to help. Schedule a free assessment call with KBWEB Consult now at https://calendly.com/krassimir-boyanov/30min.