In this part of the AEM Headless Developer Journey, you get familiar with learn how to use the AEM development tooling and the Headless SDK to put your application together.
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 aims to help you understand how to put your AEM headless application together by:
The AEM SDK is used to build and deploy custom code. It is the main tool that you need in order to develop and test your headless application before going live. It contains the following artifacts:
Different from the AEM SDK, the AEM Headless SDK is set of libraries that can be used by clients to quickly and easily interact with AEM Headless APIs over HTTP.
For more information on the AEM Headless SDK, see the documentation here.
Besides the AEM SDK, you 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 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 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 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 IntelliJ, among others.
To test code or content updates that are ingested by your headless application, you must 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 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 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.
Now that you have completed this part of the AEM Headless Developer Journey, you should:
Continue your AEM headless journey by next reviewing the document How to Go Live with Your Headless Application where you actually take your AEM Headless project live!