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 must 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 that you must develop and test your headless application before going live. It contains the following artifacts:
In addition to the AEM SDK, you need additional tooling that facilitates developing and testing your code and content locally:
Because AEM is a Java™ application, you must install Java™ and the Java™ SDK to support the development of AEM as a Cloud Service.
Git is what you use to manage source control and to check in the changes to Cloud Manager and then deploy them to a production instance.
AEM uses Apache Maven to build projects generated from the AEM Maven Project archetype. All major IDEs provide integration support for Maven.
Next, let’s 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 are made available in the local development runtime 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. To update the project, developers can use their preferred integrated development environment, such as Eclipse, Visual Studio Code, or IntelliJ, among others.
To test code or content updates that are ingested by your headless application, deploy the updates to the local AEM runtime. These include 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.
To prepare your AEM headless project for launch, make sure that all constituent parts of your project are functioning well.
To do that, you must put everything together: code, content, and configuration, and test it in a local development environment for go live readiness.
The local development environment is composed of three main areas:
After the local development environment is set up, you can simulate content serving to the React app by deploying a static Node server locally.
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, see the WKND Tutorial for an overview.
If you are an AMS customer using Cloud Manager, after you make sure that everything is tested and working properly, you can push your code updates to a centralized Git repository in Cloud Manager.
After the updates have been uploaded to Cloud Manager, deploy them to AEM using Cloud Manager’s CI/CD pipeline.
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:
To efficiently log a bug with Support, in case you need further assistance, complete the following 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 to do so. Great job!
No need to stop the headless stores in AEM, though. In the Getting Started part of the journey, it discussed how AEM not only supports headless delivery and traditional full-stack models, but also supports hybrid models that combine the advantages of both.
If this kind of flexibility is something you need for your project, continue to the optional, additional part of the journey, How to Create Single Page Applications (SPAs) with AEM.
Configuring the CDN Rewriter (search for CDN Rewriter)