Adobe I/O

I will now first try to classify these terms below to get a better overview.

Adobe I/O is designed to be a platform for developers and system integrators around the products and services offered by Adobe. The Adobe I/O platform offers the following areas at entry:

The platform is presented via the website www.adobe.io. This is also the first point of contact for anyone who wants to get involved with the platform. On the site itself, you can find a wide variety of documentation about the services and interfaces offered. Another extensive component is the so-called Code Labs, where you can find detailed tutorials for various application scenarios, see https://www.adobe.io/app-builder/docs/resources.

On this web page you will find the entry point to the so-called Adobe Developer Console. Using the Adobe Developer Console, you can create your own integration projects with the help of templates. When using these templates, different so-called workspaces are created directly. In one of the workspaces, the services that are required for the development of an application or integration of Adobe services are bundled. Classically, workspaces are created for "Stage" and "Production". But you can also create your own workspaces for development. In addition to using templates, you can also start from scratch and create your own workspaces.

Access management is also located at the workspace level. All services and APIs bundled in this way share the same access data per workspace, usually JSON Web Token (JWT) authentication. This reduces the integration effort, especially when connecting different APIs. The templates also integrate the Adobe I/O Runtime as a central component in the workspaces. Additional services and APIs have to be clicked together via the Developer Console in the browser.

Adobe I/O acts as an API hub for the various services and APIs offered in the Adobe cosmos. If you add a service to one of the workspaces mentioned above, you will find that the catalog of available APIs now includes a whole range of very different applications. The spectrum is now enormous and ranges from a user management API, which can be used to access user information, to AI-based services, such as the Photoshop API for cropping images.

This is also where Adobe's various solutions are made interconnectable. For example, the catalog of services offered also includes APIs from Adobe Analytics, Adobe Campaign, or Adobe Target. Of course, it is not enough to "click" the services together. There is still a need for an integration in which, for example, the various APIs are addressed. Such an integration is developed and encapsulated in the Adobe I/O environment in a so-called Firefly Application.

With App Builder, Adobe has created a development and runtime environment integrations around Adobe I/O can be quickly and purposefully implemented and operated. integrations can be implemented and operated quickly and efficiently. Here we are talking about a developer activity, because at this point we are leaving the path of simply clicking together.

But let's start from the beginning: Project Firefly was the label under which Adobe has combined various components. In the future, the the whole thing under the name App Builder. The following parts fall under it:

• Adobe I/O Runtime
• Adobe I/O Events
• Adobe I/O CLI
• Adobe SDK

The Adobe I/O Runtime is the central component and quasi the runtime environment that Adobe provides so that the developed integrations can be operated. Using so-called "serverless functions" can be used to extend or interconnect the Adobe Experience Platform and its services. services can be extended or interconnected.

The Adobe I/O Runtime is based on Apache OpenWhisk and Node.js. OpenWhisk is an open source, serverless platform that can execute functions in response to events. in response to specific events. OpenWhisk, or the Adobe I/O runtime manages the infrastructure, servers, and scaling using Docker containers. As a result, you don't have to worry about scaling issues during development and can focus on solving the problem. focus on solving the problem.

As the platform is based on Node.js, development mostly takes place in JavaScript. The platform supports a programming model in which application code is encapsulated in functions. These functions are called OpenWhisk Actions. These functions are mostly triggered by triggers (e.g. events) or HTTP requests. For example, you can develop a function that uses JavaScript and a corresponding client library to call Adobe's Photoshop API. The whole thing can then be used to generate renditions from AEM via HTTP requests, for example. The advantage of this approach is obvious: The individual functions are encapsulated and are automatically scaled via the Adobe I/O Runtime (Function-as-a-Service). The load is thus distributed from the AEM system to the Adobe I/O Runtime.

In addition to these actions, web applications can also be deployed and operated via the Adobe I/O Runtime. Adobe uses specially developed React components for this purpose, which are based on Adobe's design system. The web interfaces developed in this way can then be used, for example, to test the actions mentioned above. In general, many different use cases can be mapped here. However, the extent to which it makes sense to run a web application via Adobe I/O Runtime must be evaluated on a case-by-case basis. This makes the most sense for applications that function as a web front end for the "Serverless Functions".