Path to Your First Experience Using AEM Headless path-to-first-experience

In this part of the AEM Headless Developer Journey, you will understand the steps to implementing your first headless experience in AEM including planning considerations and also learn best practices to make your path as smooth as possible.

The Story So Far story-so-far

In the previous document of the AEM headless journey, Getting Started with AEM Headless you learned the basic theory of what a headless CMS is and you should now:

This article builds on those fundamentals so you understand how to prepare your own AEM headless project.

Objective objective

This document helps you understand the steps needed to implement your first project. After reading it you should:

Requirements requirements

Before you continue with this document, ensure that you have reviewed the previous document in the AEM Headless Developer Journey, Getting Started with AEM Headless making sure you:

Planning for Success planning-for-success

To start your first AEM headless project you need to ensure you have a content model that will support the personalization and updates you want to make across all your channels.

Separate from AEM, you also want to make sure you have a proper development environment set up if you are building a client-side application so you can test your client against API calls to AEM.

Defining Content Models and APIs defining-models

You want to drive a consistent experience and manage personalized campaigns across channels, so you can look at each individual channel and surface as its own distinct content structure to deliver to. However having each channel have its own content model will be challenging to maintain.

Instead, you should consider how content on different surfaces is related based on organizing principle such as brand and product hierarchies, categories of goods or surfaces, or steps in the customer journey. For example, if you have a set of surfaces that support a specific brand of cars you manufacture, you may want to start with a content model for general information that would be true for the entire car and then have more - specific elements such as content needed when the car is starting up to when there are service issues. Such a model will enforce inheritance of general car brand content while allow for shifts based on specific context needed. It also helps with future management of updates to this content as you can enforce control based on roles such as the overall marketer or product manager for the entire car brand vs an author who is responsible for the “starting car” experience.

Once you have the content model and clear view on the various clients the content needs to be surfaced to, you need to ensure the GraphQL/APIs associated with accessing various of the content model are published to all the clients who need this content. There are different options of how to access certain content. You can request for a specific piece of content that is static which enables caching of the content and higher performance. You can also request content that is dynamically generated which will require more processing. Ensure that clients are using the APIs that are most efficient for their business need.

Understanding Your Environments understanding-environments

Within AEM there are three types of environments: development, staging, and production.

The development environments (you can have multiple) are a safe place to experiment and try out ideas. During the initial phase of the project, Adobe recommends using the development environments to try variations of content models and see which provide the intended output for the surfaces.

The staging environment for headless projects is used for validating new AEM product releases before they roll out to production. Keep an up-to-date list of the production content models there and a subset of the content, so you can have JSON files rendered to compare of they still provide the same output, as you make changes or the AEM release introduces changes

Production is where content authors create and manage their actual content. Model changes in production must be carries out with care and with backwards compatibility in mind.

During the development stage, it is recommended you work with a development and staging environment. As you move to performance testing, you will want to move to the production environment.

Cooperation of Developers and Content Authors cooperation

Developers need an AEM development environment set up with the populated content models. The developer develops the client that will consume content from AEM headless as the content authors are still creating the content. That is why the API definitions are really important. By using the AEM SDK, the developer can create a test hook so client and unit tests can be created to make sure the client is able to properly render the content.

Content authors create content based on the content models that have been defined on the staging environment. Using the content fragment authoring tool, the author would create a content fragment or edit an existing content fragment. Before publishing it, the author can preview how it will look in the client by working with the developer to push the content model onto development or set up a developer environment just for authors to preview how it would look in the client.

Setup setup

Before you get started with headless in AEM, you need to make sure all required features are enabled. This section outlines what is required. The actual steps to fulfill these steps are detailed later in the AEM Headless Developer Journey.

You can also optionally see the additional resources for more information on the individual topics.

Configuration configuration

Implementing Your First AEM Headless App

This is an overview of what is needed to implement your first headless app using AEM to deliver your content. How to carry out these steps will be described in detail in later parts of the Headless Developer Journey.

Best Practices best-practices

A headless project is not only successful because of the technology implemented, but also due to good planning and project governance. The following are several best practices for both content authors and developers to keep in mind as you plan your project.

Organizing Your Content organizing-content

Authoring Content authoring

Authoring Global Content localization

What’s Next what-is-next

Now that you have completed this part of the AEM Headless Developer Journey, you should:

We want you to build on this foundational knowledge to fully understand the power and flexibility of AEM Headless so you can take advantage of it for your own projects. To do this, you have options.

Choose Your Own Adventure choose-your-path

No matter what your learning style, Adobe wants you to succeed as you get started with your AEM Headless project.

Additional Resources additional-resources

While it is recommended that you move on to the next part of the headless development journey by reviewing the document How to Model Your Content as AEM Content Models, the following are some additional, optional resources that do a deeper dive on some concepts mentioned in this document, but they are not required to continue on the headless journey.