It’s not uncommon when facing a new problem, to fall back on a tried-and-true solution. Then, suddenly remember why the team moved off of that solution in the first place. Recently, I’ve seen this trend with engineering teams and a desire for multichannel content.
A Common Case for Headless Content on AEM
Let’s set the stage with an example. A digital marketing team has licensed Adobe Experience Manger 6.5 with the hope of using the WYSIWYG content editing to quickly produce and release content decoupled from code deployments. They also see that AEM has the capacity to produce reusable multichannel content via Content Fragments. Marketers plan on using those fragments within a marketing website, a companion mobile app, and voice assistance devices. Finally, it would be great if the site had the option for highly interactive pages that didn’t require a refresh. They ask the engineering team to implement the solution.
The engineering team is full of talented backend developers who have years of experience serving up web content. The engineers dig into the platform, and while some are able to learn AEM component development, it’s slow going. They soon have a few concerns:
- They want to use a frontend framework to deliver the highly interactive parts of the website. Expanding the team is difficult because only a few developers in the market have both AEM component and frontend framework experience.
- There is already a disconnect between authoring Content fragments and the expectation of authoring content in-place on the page.
- There are a myriad of options for implementing Single Page Applications (SPAs) in AEM. Which one best fits the use case?
- The slow progress to get even one demo-able page together. If this was just in [insert technology] instead of multiple HTL templates, Sling models, and component dialogs it would be faster.
Frustrated, the engineering team spins up a proof of concept with their previous stack. They go back to the marketing team and show how much faster they created a new page and components. Engineering pushes for a compromise of headless content on AEM and a separate SPA site with the stack they are familiar with. In my opinion, this largely defeats the purpose of licensing AEM. With this approach, the ability to use WYSIWYG editing and decoupled code/content releases is gone.
Why You Should Consider Fragments and Sling Model Exporters
Instead, consider using Content Fragments, Experience Fragments, and Sling Model Exporters combined with SPAs for benefits of both approaches.
Content Fragments are code-free, structured text and image content you can author and expose to any channel via JSON or GraphQL.
Experience Fragments are also code-free, but present experiences with a partial or complete layout in HTML. Optionally, they include design and functionality via CSS and JavaScript. The Experience Fragments can utilize any AEM component and are intended for reusable “ready/nearly ready” experiences. With some light custom development, you can even leverage Content Fragments within AEM components and thus any Experience Fragment.
Sling Model Exporters can serialize most AEM component authoring into JSON to expose to any channel. This is the preferred option for retaining in-context editing, as most other solutions require navigation to another page to edit the experience. All Adobe Core Components have this enabled by default. This requires a small amount of development to configure for custom components but is quite powerful and quick for existing AEM implementations to enable multichannel content delivery.
Utilizing these solutions together over headless alone has several benefits. Having any one of these fragments together with at least one of the experiences within the AEM author environment means you can natively preview changes in a channel before they go live. You can also build out much of the base site structure with Core Components and fragment-based authoring without any development. Then once your team is more comfortable with AEM development, utilize Sling Model Exporter for multichannel delivery of custom experiences. Most critically, you retain WYSIWYG editing and decoupled code/content releases.
But What About SPA for AEM?
You might notice there’s a key element left unanswered here – how best to do that in combination with SPA? Thankfully there are several options, which I cover in Part 2.
For more information on how Perficient can implement your dream digital experiences, we’d love to hear from you. We’re certified by Adobe for our proven capabilities, and we hold an Adobe Experience Manager specialization (among others). Contact Perficient to start your journey.
