In this part of the AEM Headless Developer Journey, learn how to deploy a headless application live.
In the previous document of the AEM headless journey, How to Update Your Content via AEM Assets APIs you learned how to update your existing headless content in AEM via API and you should now:
This article builds on those fundamentals so you understand how to prepare your own AEM headless project to go live.
This document helps you understand the AEM headless publication pipeline and the performance considerations you need to be aware of before you go live with your application.
The AEM SDK is used to build and deploy custom code. It is the main tool you need in order to develop and test your headless application before going live. It contains the following artifacts:
In addition to the AEM SDK, you will need additional tooling that facilitates developing and testing your code and content locally:
Because AEM is a Java application, you need to install Java and the Java SDK to support the development of AEM as a Cloud Service.
Git is what you will use to manage source control as well as to check in the changes to Cloud Manager and then deploy them to a production instance.
AEM uses Apache Maven to build projects projects generated from the AEM Maven Project archetype. All major IDEs provide integration support for Maven.
Next, let’s take a look at the constituent parts of an AEM environment.
A full AEM environment is made up of an Author, Publish, and Dispatcher. These same components will be made available in the local development runtime in order to make it easier for you to preview your code and content before going live.
The Author service is where internal users create, manage, and preview content.
The Publish service is considered the “Live” environment and is typically what end users interact with. Content, after being edited and approved on the Author service, is distributed (replicated) to the Publish service. The most common deployment pattern with AEM headless applications is to have the production version of the application connect to an AEM Publish service.
The Dispatcher is a static web server augmented with the AEM dispatcher module. It caches web pages produced by the publish instance to improve performance.
The local development project is built on Apache Maven and is using Git for source control. In order to update the project, developers can use their preferred integrated development environment, such as Eclipse, Visual Studio Code or or IntelliJ, amongst others.
To test code or content updates that will be ingested by your headless application, you need to deploy the updates to the local AEM runtime, which includes local instances of the AEM author and publish services.
Make sure to take note of the distinctions between each component in the local AEM runtime, as it is important to test your updates where they matter the most. For example, test content updates on author or test new code on the publish instance.
In a production system, a dispatcher and an http Apache server will always sit in front of an AEM publish instance. They provide caching and security services for the AEM system, so it is paramount to test code and content updates against the dispatcher as well.
In order to prepare your AEM headless project for launch, you need to make sure all constituent parts of your project are functioning well.
To do that, you need to put everything together: code, content and configuration and test it in a local development environment for go live readiness.
The local development environment is comprised of three main areas:
Once the local development environment is set up, you can simulate content serving to the React app by deploying a static Node server locally.
In order to get a more in depth look at setting up a local development environment and all dependencies needed for content preview see Production Deployment documentation.
Now, it’s time to get your AEM headless application ready for launch, by following the best practices outlined below.
See Additional Resources for more information about CDN and caching.
Last-modified-sinceto refresh resources.
_referenceoutput in JSON file to start downloading assets without having to parse complete JSON files.
Deploying to Production can depend on whether you have a traditional AEM instance that deploys using Maven, or are on Adobe Managed Services (AMS) and therefore using Cloud Manager.
For a traditional deployment (non-AMS) using Maven you can see the WKND Tutorial for an overview.
If you are an AMS customer using Cloud Manager, then once you make sure everything has been tested and is working properly, you are ready to push your code updates to a centralized Git repository in Cloud Manager.
After the updates have been uploaded to Cloud Manager, they can be deployed to AEM using Cloud Manager’s CI/CD pipeline.
In order for users to have the best possible experience when using the AEM headless application, it is important that you monitor key performance metrics, as detailed below:
Follow these best practices as a general approach to debugging:
In order to efficiently log a bug with Support in case you need further assistance, follow the below steps:
Congratulations! You have completed the AEM Headless Developer Journey! You should now have an understanding of:
You have either already launched your first AEM Headless project or now have all the knowledge you need to do so. Great job!
The headless stores in AEM doesn’t need to stop here, though. You might remember in the Getting Started part of the journey we discussed briefly how AEM not only supports headless delivery and traditional full-stack models, but also can support hybrid models that combines the advantages of both.
If this kind of flexibility is something you need for your project, continue on to the optional, additional part of the journey, How to Create Single Page Applications (SPAs) with AEM.