In the past, deploying UI updates has required packaging them alongside OSGi bundles and HTL-driven components. While this is still a usable way to deploy projects in AEM, it cannot isolate the UI and hot reload updates. Furthermore, front-end developers and designers often need to only focus attention on the app experience. They may not require all the features of a local AEM environment or maintaining one.
AEM as a Cloud Service provides the means to isolate UI design along with deployment pipelines dedicated to them. This is set up using npm commands, a workflow most front-end developers are familiar with, while not requiring a dedicated local AEM instance.
The theme designs can be isolated to a dedicated repository, with only the relevant files present.
Setting Up AEM Cloud Service Sites
For this test drive, I followed the steps laid out in the AEM Quick Site Creation Journey documentation. I encourage you to walk through this to set up your own front-end design project and deployment pipeline. I set up a site designs repository and front-end pipeline in Cloud Manager and configured the pipeline to build from the main branch of my repo.
I set up a proxy user in the dev author instance of our cloud service program. Be sure to securely store the credentials for this in some sort of password vault. As noted in the documentation, front-end developers need to log into the AEM instance using these credentials when updating designs via the proxy (more on this below).
In our dev author, I also created a test app using the site from template option in AEM Sites. In my case, I chose the Tailwind AEM site template. With the site created, I downloaded the theme sources.
After extracting the downloaded theme folder and navigating into it, I had to run npm install and then finally npm run live. This last step will start the proxy and open your browser to the home page of your site, under http://localhost:7001. Note, that this is not a local AEM instance. The NodeJS proxy is serving content from a Cloud Service instance (dev author in my case) and exposing it via that localhost domain. When you make changes, they are rendered if the proxy is running. (No actual changes are persisted to the AEM instance here, which requires a deployment.)
Making Design Updates
Something to keep in mind, only typescript and SASS file changes cause an immediate page re-render in the browser. CSS changes require a manual page refresh. This is expected. As a good practice, most of the design updates should be made to your theme’s pre-processed files.
With the proxy running, I signed into http://localhost:7001 using the SIGN IN LOCALLY (ADMIN TASKS ONLY) option. At that point, I was able to begin making design changes. There’s a considerable number of things that can be updated. I wanted to try out a few simple ones and one complex change.
Test 1: I updated the site background color.
Original:
Updated Theme:
Test 2: I tested a change specific to a component’s design. In my case, the navigation component.
Original:
Updated Theme:
Test 3: I was even able to swap out images used on the site, rendering a different image from our AEM Assets service.
Original:
Updated Theme:
These changes were saved, and the theme folder was committed to my site designs repository. I then pushed the updates to the remote repo in Cloud Manager and triggered the frontend pipeline to deploy and persist my changes in our dev author. This repo could be used in a production pipeline to deploy the changes into Stage and Production environments as well.
Issues and Resolutions
During testing, I did encounter a few “gotcha” moments.
Browser Compatibility
First off, I could not log in to our AEM author via the proxy when using Chrome but was able to when using Firefox and Safari. This compatibility is likely to change over time, but something to keep in mind when setting this up.
Node Version Compatibility
Newer versions of NodeJS (19, 20, and 21) may encounter the following error when installing the project:
This is caused by an incompatibility with the LMDB interface package (a transitive dependency of the parcel-namer-rewrite dev dependency in the theme’s package.json) and newer NodeJS versions. To get around this, you either need to use an older version of Node or run the following command to ensure the latest version of the LMDB interface is used:
This will add the dependency in your package.json as:
With this in place, the project should install successfully using NodeJS 19 and up.
Pipeline Code Location
When your changes have been tested and you’re ready to deploy via the front-end pipeline, be sure to configure the pipeline’s code location field to point to the folder where your theme files are committed in the source repository.
For example, I stored my site theme files in a folder called “brand-able-theme-sources” (which is just the folder I retrieved from AEM Sites when downloading the theme sources), placed this folder in the root of the git project, committed it, and pushed to the remote repo in Cloud Manager. I configured the front-end pipeline’s code location as follows:
AEM Cloud Service Sites is a Game Changer
The speed of being able to hot reload your site designs without waiting on a pipeline or even a local maven build is a serious game changer when testing. Limiting what can be changed to just your site’s overall branding helps ensure consistency. However, you can set this up to allow more precise component-level changes as well. I recommend that you go through the Quick Site Creation Journey and see how this can benefit your front-end team’s development and design processes.
For more AEM as a Cloud Service-related content, check out our Adobe blogs.
