The magical world of Adobe App Builder

Author: Florian Sydekum

Herzförmige elektronische Schaltung auf dunklem Hintergrund, symbolisiert den Newsroom der TechDivision.

For some time now, Adobe has been offering a powerful tool in the form of the App Builder, which will reveal unimagined value creation potential for many.

Part 1 - A paradigm shift in development with Adobe Commerce

For some time now, Adobe has been offering App Builder, a powerful tool that will reveal unimagined value creation potential for many. From my own experience as a long-time Adobe Commerce developer, I can say that it was not very trivial at first to recognize the full potential of App Builder. But after weeks of intensive work and use in real projects, I am convinced that this is the start of something really big: Future e-commerce landscapes will be more flexible, scalable and based on a microservice architecture. App Builder pursues a system-independent approach (i.e. not just a focus on commerce) and originally comes from the AEM corner and Experience Cloud. As part of the Experience Cloud, this opens up enormous potential for Adobe Commerce. It quickly becomes clear that Adobe Commerce will join the ranks of many other services in a large e-commerce landscape. This article will take a closer look at how to get there.

How Adobe App Builder works

With the App Builder, it is possible to run applications in a serverless landscape. This allows web apps to be written with a user interface, API extensions and small functions. The latter run according to the "function as a service principle" in the Adobe Cloud, based on Apache OpenWhisk technology. A wide range of APIs from the Adobe ecosystem can be accessed (e.g. AEM, Analytics, Photoshop, Stock, Commerce, etc.). It is also incredibly easy to connect external systems and integrate them into a homogeneous system architecture.

(Example I: User Interface/UI of the Adobe App Builder - Source: Adobe App Builder)

Particularly noteworthy is the minimal effort required to create such functionalities/applications in App Builder and to further develop existing systems without modifying them directly. Within a few minutes, code can be written that specifically extends functionality in Adobe Commerce, for example. These functions can be deployed and executed in the Adobe Cloud within the Adobe I/O Runtime. In the meantime, not even a thought was wasted on infrastructure or security - the big advantage of serverless: 100% focus on the few lines of code for the respective feature or function.

The advantages

The App Builder pursues two important goals with regard to Adobe Commerce, which bring enormous advantages over the previously known architectures:

Adobe Commerce can and should be extended in such a way that the monolithic code of Adobe Commerce from a microservice perspective remains untouched: Any extension is deployed and executed in the I/O Runtime. Virtually all relevant data from Adobe Commerce can be transferred to actions in the I/O Runtime via events and processed there.

Adobe Commerce is gradually disappearing into a larger e-commerce system landscape. Especially in the headless approach, Adobe Commerce coexists with many other small services in the Adobe Cloud. The perfect prerequisite for a homogeneous e-commerce landscape. From a client perspective, data and services can come from anywhere (e.g. product data from PIM, Catalog Service, Adobe Commerce, etc.). The services can be exchanged with each other almost invisibly or exist side by side.

(Example Il: E-Commerce system landscape - Source: Adobe Experience Coud Blog - https://business.adobe.com/blog/the-latest/next-generation-extensibility-digital-commerce)

First steps with App Builder

Getting started with your first application is relatively easy. You start in the App Builder backend and have two workspaces available by default: Stage and Production. The names are self-evident for their purpose. Further workspaces can be added and various apps, i.e. API or event connections, can be created within a workspace. Authentication for data communication takes place entirely via Adobe IMS and therefore via OAuth.

(Example III: Workspace view - Source: Adobe App Builder)

Similar to the official App Builder Quick-Start from Adobe, after installing the AIO CLI Tool you have a powerful tool that enables developers to work with the project on the console. Projects can be initialized and changed, boilerplate code can be generated and deployed. The tool can do so much more and a detailed reference of the individual commands can be found here.

A comprehensive overview to get you started :

Deployment workflow

The locally developed apps and functions can be deployed very easily to the Adobe Cloud. After you have successfully set up your project via the AIO CLI, you can check in advance which project and workspace you are in:

aio where

You are currently in:

  1. Org: TechDivision GmbH
  2. Project: appbuilder-demo
  3. Workspace: Stage

With a simple aio app deploy it is already done. You can then use an aio runtime action list to check which actions are available and that the corresponding version has been increased by the deployment.

(Example IV: Developer Architecture - Source: Adobe Developer Blog - https://developer.adobe.com/app-builder/docs/guides/deployment/)

The runtime actions are deployed in the I/O Runtime Cloud and are then available for execution. Optional web UI (web-src) is uploaded as static files to a CDN. After deployment from the console, a URL is displayed that can be called up to access the web UI.

Alternatively, you can also run the app locally: aio app run

(Example V: Developer Alternative Architecture - Source: Adobe Developer Blog - https://developer.adobe.com/app-builder/docs/guides/deployment/)

Adobe recommends for everyday project work that the apps are generally managed under version control so that the development team can work with them as usual. During project initialization, a rudimentary CI/CD workflow process can also be set up via AIO CLI for Github Actions can also be created. The two workspaces Stage and Production can then only be deployed using the CI/CD workflow. In turn, each developer can create any dev workspaces in the App Builder backend and use them for themselves.

(Example V: Developer Alternative Architecture - Source: Adobe Developer Blog - https://developer.adobe.com/app-builder/docs/guides/deployment/)

Conclusion

The longer you work with App Builder, the clearer its potential becomes. After some initial familiarization and getting used to the new way of thinking about the development process and system architecture, it gradually becomes clear how many different use cases (Link 1 and Link 2) are possible with App Builder. From the perspective of Adobe Commerce, projects should be closely scrutinized to determine the extent to which App Builder can be used sensibly.

Outsourcing the generation of a product data feed to App Builder relieves the store system enormously and at the same time provides an independent data source for feed-consuming systems within the microservice architecture (marketplaces, etc.). All in all, a powerful tool that is really fun to work with and you won't want to wait much longer to finally develop real applications.

Do you have any questions?

Simply fill in the form opposite or send us an e-mail to anfragen (at) techdivision.com or call us on +49 8031 22105-0.

Vereinbaren Sie einen unverbindlichen Beratungstermin zu unseren Leistungen mit uns.