With over a decade of experience developing AEM solutions, I have adhered to well-established patterns and practices. This includes implementing front-end features using templates and components. Integrating back-office systems with OSGi services. And fine-tuning caching on the dispatcher. Among many other standard solutions to common issues.
Along the way, Adobe has introduced new tools and features. And changed the architecture here and there. By and large, development was business as usual. But this past year I started to dig into Edge Delivery Services & The Universal Editor. Which brought me to App Builder, the topic for today. But before I get into it, it’s worth taking a step back to understand the context and history leading up to it.
The Monolithic Architecture of AEM
In 2009, Adobe acquired Omniture. A company specializing in online marketing and web analytics. The following year, it acquired Day CQ5. An enterprise content & digital asset management system. And in 2012, after a few more acquisitions, they came together under the Adobe Marketing Cloud. Later to get rebranded the Adobe Experience Cloud.
During this period of cloud transformation, AEM was a happy little monolithic application. And Adobe did its best to integrate it into its cloud. But as we all know, clouds do not like monoliths. And the opposite of monolithic is composable. So how do you go from a monolithic architecture to a composable one? Well you have to decompose the monolith!
Decomposing the Monolith
As an on-premise monolith, the biggest problem AEM had was a slow adoption rate of new features. Once a release became generally available, customers would be hesitant to upgrade. And upgrades could take a long time. In part because of all the customization work they had put into the previous version. To change this, Adobe introduced AEM as a Cloud Service in 2020. Getting rid of the slow upgrade cycle by replacing it with a continuous update model. And putting strict guard rails on what customers could deploy.
This move to the cloud marked the first decomposition event I remember. This was when AEM assets got redesigned. In particular, the asset workflow got deprecated. This was the workflow that ran on the host to generate asset renditions. It got replaced with the asset compute service. Built on a serverless computing platform provided by Adobe I/O Runtime.
The continuous update model allows features and improvements to get introduced much faster. And are much more likely to gain adoption quickly. Because clients do not need to wait for the next upgrade. Some examples of feature that have decomposed the monolith are:
AEM Headless: Getting rid of server-side rendering. And delivering content via APIs like GraphQL. This decoupled approach enables content reuse. And supports flexible front-end development for multichannel experiences.
AEM Events: Producing events to signal state changes. Such as the creation, modification, or deletion of content. External systems can then subscribe to these events, decoupling the producer from the consumer. Which enables clients to build event-driven integrations and business processes.
Edge Delivery Services: This replaces the publish & dispatcher tier. By publishing content directly to the edge where it is closer to the users. Improving speed and scalability.
Universal Editor: By decoupling the Page Editor form the content, various architectures and frameworks can now be supported. Allowing clients to use their preferred technologies without constraints.
Adobe IMS and OAuth: Replacing LDAP with an Adobe IMS integration provides centralized authentication and authorization. Managed via the Admin Console with SSO support.
So What Is App Builder?
Back to the topic at hand. What is App Builder and why should AEM developers and architects care? Thats a great FAQ! In fact take a look at the FAQ page. Where you will find the first question is: "What is App Builder?"
App Builder is a complete design, application, and runtime framework for building 3rd-party cloud native applications. These custom web apps run on Adobe infrastructure and extend the functionality of Adobe Experience Platform and Adobe Experience Cloud. With App Builder, customers can build custom integrations between Adobe products and 3rd-party products, enabling greater efficiency and improved workflows.
The key words here are extend and integrate. You see, what makes the AEM monolith so loved by enterprise clients is that it is very customizable. You need a custom integration? No problem, build custom OSGi components to take care of that. The content editor is not good enough? No problem, extend the authoring dialogs as you wish. But when you begin to break up the monolith, you lose that central place.
This is where App Builder comes in. It fills the gap left by the decomposition of the monolith. For AEM developers and architects, this is important to note. Because it signals a transition away from traditional AEM development. And into cloud-based development within Adobe’s broader ecosystem.
Don't worry, this isn't going to happen overnight. The Universal Editor is no where near feature-parity with the AEM Page Editor. And to be honest, some clients have invested way too much in what they have now. They could never justify re-architecting everything to make the jump to Edge Delivery. But new clients are way more flexible. While the transition will take time, the direction is clear. AEM development is evolving to embrace cloud-native principles and composability.
Show Me What App Builder App Can Do
You may be getting excited at the thought of cloud development. But you are still unclear what an App Builder app is. Some of the things you can do with it. And its potential. So you say "Show me the money!".
Lets talk about "extension points" which is key a key concept. Adobe products define their own extension points. And developers create App Builder apps that target those points. Currently, there are two types. One extension point for AEM Asset Microservices. And several others that extend the Experience Cloud UI. I encourage you to take a look at this: Introduction to Extensions.
Extending Asset Compute Microservices
To create an Asset Compute extension, follow this tutorial. I am not going to get hands-on in this post. I'm just showing you the money. Here are a couple tips if you decide to dive in.
The video in that tutorial seems outdated. Most videos are in fact, because the aio-cli changes so much. To init the project and get the option for an asset compute worker, use aio app init <my-app-name> --standalone-app.
When you begin to Google about this, be mindful. There is an old way to create workers. And there is the new App Builder extension way. Take a look at this GitHub project: adobe/asset-compute-example-workers. Look at the difference between the legacy worker-cc-photoshop. And the App Builder extension worker-cc-photoshop. You'll see the use of the dx-asset-compute-worker-1 extension.
If you would like to know more about the asset compute worker with PhotoShop API, check out this code lab.
Extending the Experience Cloud UI
There are way more extension points for UI extensibility. The ones that we would care about for AEM are
Lets focus on one example. Navigate to the extension manager:
What you see depends on the licences your organization has. In my case, I see two services: "AEM as a Cloud Service", and the "Universal Editor".
You can click into a service to see the list of installed & available extensions. But lets stick to the root page. Where you see the cards promoting some of the extensions. One caught my eye, the "Rich Text Editor Toolbar Button". How many times did a client ask you to customize the RTE? And there is a link to a project named cf-editor-rte-toolbar-configurable-buttons. Which is under a GitHub repo named adobe/aem-uix-examples. Which has even more examples. And this one also caught my eye: cf-editor-rte-toolbar-configurable-buttons. After spending some time looking at it, it occurred to me. This would be an excellent use case for integration with the Azure App Configuration Service. I'm going to have to work on that some other time.
It is worth noting that these are Content Fragment Editor extensions (aem-cf-editor-1). And I did not see any Universal Editor (universal-editor-ui-1) samples specific to the RTE. So another thing I could investigate is extension of the RTE in the Universal Editor.
You can run any of these samples using the local preview feature. The ext URL parameter works for the Content Fragment Editor as well for the Universal Editor. Assuming the following
Your local extension is running on https://localhost:9080
You have deployed Edge Delivery AEM content to /content/my-site
Your AEM author is author-pNNNNN-eNNNNNNN.adobeaemcloud.com
You just add the ext parameter and your editor URL becomes
https://experience.adobe.com/#/aem/editor/canvas/author-pNNNNN-eNNNNNNN.adobeaemcloud.com/content/my-site/index.html?ext=https%3A%2F%2Flocalhost%3A9080%2Findex.htmlThe Adobe I/O Extensible CLI
If you are like me, you might want to dive straight into some of the samples mentioned above. But sooner or later you ware going to start to wonder about the Adobe I/O CLI. This CLI is an extensible, and based on the Open CLI Framework. Which means every time you are use a command, you are working with a plugin. For example
aio runtime is implemented by @adobe/aio-cli-plugin-runtime
aio app is implemented by @adobe/aio-cli-plugin-app
To get a complete listing of the core plugins use aio plugins --core.
Be aware that when developing with App Builder, the primary plugin you will use is the @adobe/aio-cli-plugin-app. My experience so far has been that there is a close coupling between the local environment. And the templated project on the Developer Console.
Also, understand that the plugin has some useful commands to run, test and deploy the app. But its primary function is code generation. Every time you use aio app init, it will go through a series of prompts to get input from you. So it knows what to scaffold. And it does so with the help of templates from the template registry. To discover what templates are available, use the aio templates discover command.
When prompted for a template, if you don't select one, a standalone project will get created. Same thing as if you had invoked the init command aio app init --standalone-app.
Things to Look Out for in the Future
The Universal Editor will use an extension to persist content. Which I mentioned in my previous post: Three Laps Around the Universal Editor. You might remember this diagram.
The connection to the persistence layer gets instrumented via the following meta tag.
The protocol indicates which persistence plugin to use. And I have only seen references to two protocols. aem and xwalk. I have not seen any references on how to create a custom persistence extension. I hope that in the future this is an option. Wouldn't it be cool if we can edit content in an SQL database? A horrible idea, I know But I'm just saying...
The other thing that I will be keeping an eye out for is certification paths. Right now, Adobe's certification paths are very product specific. But App Builder spans many products. So I would like to see certification tracks that focus on App Builder. And the many ways it can get used to extend and integrate the AEC. Like Azure's AZ-204. Which covers development using several of Azure's services.
Conclusion
AEM is changing from a single, all-in-one system to a flexible, cloud-based platform. This is a big change for developers and architects. Tools like App Builder make it easier to customize without changing AEM’s core. They also let us choose the best tools and frameworks for our needs, making it simple to add features, connect systems, and build better solutions. It also makes it easier to connect AEM with other Adobe Experience Cloud products, helping everything work together more smoothly. As AEM continues to change, developers will need to learn these new tools to keep up.
コメント