diff --git a/src/data/navigation/sections/app-development.js b/src/data/navigation/sections/app-development.js
index 268aef48..c084e20b 100644
--- a/src/data/navigation/sections/app-development.js
+++ b/src/data/navigation/sections/app-development.js
@@ -11,6 +11,18 @@ module.exports = [
title: "Learning path",
path: "/app-development/learning-path.md"
},
+ {
+ title: "App development comparison",
+ path: "/app-development/app-development-comparison.md"
+ },
+ {
+ title: "Services comparison",
+ path: "/app-development/services-comparison.md"
+ },
+ {
+ title: "Port extensions to apps",
+ path: "/app-development/port-extensions.md"
+ },
{
title: "Best practices",
path: "/app-development/best-practices/index.md",
diff --git a/src/pages/_images/oms1.mmd b/src/pages/_images/oms1.mmd
new file mode 100644
index 00000000..586d67f6
--- /dev/null
+++ b/src/pages/_images/oms1.mmd
@@ -0,0 +1,8 @@
+flowchart LR
+ subgraph Box1[Adobe Commerce]
+ A1[New Order] --> A2[I/O Events to Adobe Commerce]
+ end
+ subgraph Box2[Order Export Service]
+ B1[Transformation]
+ end
+ Box1 --> Box2 --> Box3[Order Management System]
\ No newline at end of file
diff --git a/src/pages/_images/oms1.svg b/src/pages/_images/oms1.svg
new file mode 100644
index 00000000..622e19c7
--- /dev/null
+++ b/src/pages/_images/oms1.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/src/pages/_images/oms2.mmd b/src/pages/_images/oms2.mmd
new file mode 100644
index 00000000..336ad832
--- /dev/null
+++ b/src/pages/_images/oms2.mmd
@@ -0,0 +1,14 @@
+---
+config:
+ theme: mc
+---
+flowchart LR
+ subgraph Box1[Adobe Commerce]
+ A1[New Order] --> A2[I/O Events to Adobe Commerce]
+ A3[Extension that adds custom data to GraphQL or performs custom calculations] --> A4[GraphQL]
+ end
+ subgraph Box2[Order Export Service]
+ B1[Transformation]
+ end
+ A4 --> Box2 --> Box3[Order Management System]
+ A2 --> Box2
diff --git a/src/pages/_images/oms2.svg b/src/pages/_images/oms2.svg
new file mode 100644
index 00000000..560e87fe
--- /dev/null
+++ b/src/pages/_images/oms2.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/src/pages/app-development/app-development-comparison.md b/src/pages/app-development/app-development-comparison.md
new file mode 100644
index 00000000..ed1051cb
--- /dev/null
+++ b/src/pages/app-development/app-development-comparison.md
@@ -0,0 +1,179 @@
+---
+title: App Development Comparison
+description: Learn about the differences in app development between Adobe Commerce and App Builder.
+contributor_name: Comwrap Reply GmbH
+contributor_link: https://www.comwrap.com/en.html
+keywords:
+ - App Builder
+ - Extensibility
+---
+
+# App Development Comparison
+
+Adobe Commerce is a powerful e-commerce platform that allows developers to use in-process extensibility to enhance its functionality. By combining Commerce with Adobe Developer App Builder, developers now have a new out-of-process set of tools. This guide highlights key differences and benefits of using Commerce's out-of-process extensibility with App Builder's [out-of-process development tools](../index.md).
+
+The following sections help developers transition from Adobe Commerce extension development to Adobe Developer App Builder development.
+
+- [Coding convention](#coding-conventions)
+- [Integrating third-party modules](#integrating-third-party-modules)
+- [Services Comparison](./services-comparison.md)
+
+The in-process extensibility model has many disadvantages, such as increased maintenance costs, reduced software stability, and increased AC server overload. These disadvantages along with the increased business complexity and technology stack, we recommend using the out-of-process model whenever possible.
+
+## Coding conventions
+
+Coding conventions are a set of guidelines that define how developers write and format code. This section highlights the differences in coding conventions between Commerce and App Builder.
+
+### Models and resource models
+
+This section highlights the differences in models and resource models between Commerce and App Builder.
+
+#### Commerce
+
+Models in Commerce are responsible for:
+
+- Data operations
+- Interacting with the database
+- Encapsulating business logic
+
+Commerce models are usually found in `app/code///Model/`. They often extend from core Magento classes such as `\Magento\Framework\Model\AbstractModel`.
+
+#### App Builder
+
+**Recommended method**
+
+App Builder replaces the concept of Models with API endpoints and business logic functions that interact with external data sources or Adobe services.
+
+These JavaScript functions are typically contained in the [`actions` directory](https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/configuring-and-extending/app-builder/actions).
+
+### Controllers
+
+This section highlights the differences in controllers between Commerce and App Builder.
+
+#### Commerce
+
+Controllers handle HTTP requests and route them to the appropriate business logic within the Commerce codebase. `app/code///Controller/` contains most controllers.
+
+These controllers usually extend from Magento's core controller classes like `\Magento\Framework\App\Action\Action`.
+
+#### App Builder
+
+**Recommended method**
+
+App Builder uses actions to handle HTTP requests and execute the necessary business logic. They are similar to controllers in traditional Model-View-Controller (MVC) frameworks.
+
+The controllers are JavaScript functions within the [`actions` directory](https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/configuring-and-extending/app-builder/actions).
+
+### Plugins and observers
+
+This section highlights the differences in plugins and observers between Commerce and App Builder.
+
+#### Commerce
+
+Plugins (or interceptors) in Commerce allow developers to modify the behavior of public methods by intercepting calls to those methods. They extend or alter the functionality of existing classes modularly without modifying the original code.
+
+Commerce observers listen to dispatch events during various points of the application lifecycle and execute custom logic in response to those events.
+
+`app/code///Plugin/` contains most plugins.
+
+#### App Builder
+
+**Recommended method**
+
+In App Builder, you can create plugins and observers using [Adobe I/O Events](https://developer.adobe.com/events/docs/). Adobe I/O Events allows Commerce to publish events that services built on App Builder can consume. This enables you to extend the capabilities of Commerce by triggering actions in your custom App Builder application.
+
+Commerce plugins dispatch these events and App Builder actions handle them. For more information, see the [Adobe I/O Events for Adobe Commerce Overview](https://developer.adobe.com/commerce/extensibility/events/).
+
+### Cron jobs and alarms
+
+The following section highlights the differences between cron jobs in Commerce and alarms in App Builder.
+
+#### Commerce
+
+Cron jobs in Commerce are scheduled tasks that execute at specific intervals. They are for recurring tasks such as reindexing, sending emails, and generating reports.
+
+In Commerce, you define Cron jobs in the module's `crontab.xml` file, but the actual logic is in classes found in the `cron` directory within the module.
+
+#### App Builder
+
+**Recommended method**
+
+Alarms in Adobe I/O Runtime are trigger provided by the OpenWhisk ecosystem. They allow you to schedule actions to run at specified intervals, similar to how [cron jobs](https://developer.adobe.com/app-builder/docs/resources/cron-jobs/) work in a traditional server environment.
+
+You can set these alarms to trigger at specific times or on a recurring schedule using cron expressions.
+
+Alarms can trigger any action, such as [Controllers](#controllers), you define in the YAML configuration file.
+
+### Message queue
+
+This section highlights the differences in message queues between Commerce and App Builder.
+
+#### Commerce
+
+Message queues in Commerce manage background processes and decouple tasks to improve performance and scalability. They handle asynchronous communication between different parts of the application.
+
+Message producers send messages to the queue, and message consumers process those messages.
+
+#### App Builder
+
+**Recommended method**
+
+In App Builder, [Adobe I/O Events](https://developer.adobe.com/events/docs/) provides a substitute to message queues. Adobe I/O Events allows you to publish events and consume them asynchronously using Webhooks or the Journaling API. This mechanism helps manage background processes, decouple tasks, and handle asynchronous communication between different parts of the application.
+
+The configuration requires managing multiple XML files.
+
+- Event Publisher - This is analogous to the producer in a message queue system. It publishes events to Adobe I/O Events. You can publish events from different sources, such as Adobe services or custom applications.
+
+- Event Consumer - This is analogous to the consumer in a message queue system. It processes the events asynchronously. You can implement consumers using Webhooks or the Journaling API to listen for and process events.
+
+### Admin modules
+
+This section highlights the differences in Admin modules between Commerce and App Builder.
+
+#### Commerce
+
+Commerce delivers extensive capabilities for developing custom Admin interfaces. These interfaces empower administrators to interact with and manage aspects of the extensions, enhancing the functionality and user experience of the platform. The Commerce Admin user interface uses a combination of PHP, XML, and JavaScript, and it includes a wide array of UI components that developers can use to construct sophisticated and highly interactive admin pages.
+
+#### App Builder
+
+**Recommended method**
+
+App Builder brings a modern approach to creating and integrating admin interfaces by leveraging the [Admin UI SDK](https://developer.adobe.com/commerce/extensibility/admin-ui-sdk/). This SDK allows developers to integrate Single Page Applications (SPAs) directly into the Commerce Admin interface, providing a seamless experience.
+
+## Integrating third-party modules
+
+This section highlights the differences in integrating third-party modules between Commerce and App Builder.
+
+### Composer (Commerce) and NPM (App Builder)
+
+In modern web development, integrating third-party modules and libraries is a common practice which enhances functionality, streamlines development, and leverages community-driven solutions. Both Commerce and App Builder provide robust mechanisms for managing these integrations through different tools.
+
+#### Commerce
+
+Commerce uses Composer, a dependency management tool for PHP, to manage the installation and updates of the Commerce system, as well as third-party extensions and libraries. Composer simplifies the process of declaring and resolving dependencies, ensuring that all necessary packages install properly and are compatible with each other. This tool maintains the integrity and functionality of a Commerce-based application, enabling developers to add, update, and manage PHP packages and Commerce modules.
+
+#### App Builder
+
+**Recommended method**
+
+App Builder leverages Node Package Manager (NPM) to manage dependencies for its serverless functions and other JavaScript-based components. NPM is the default package manager for Node.js and is essential for managing the vast ecosystem of JavaScript libraries and tools. It allows developers to install, update, and manage third-party modules, facilitating the rapid development and deployment of serverless applications within App Builder.
+
+#### Feature Comparison
+
+While both tools serve the same fundamental purpose of dependency management, they operate in different environments and cater to distinct programming languages and ecosystems. The following comparison highlights the key features and differences between Composer packages in Commerce and NPM packages in App Builder.
+
+
+
+| Feature | Composer (Commerce) | NPM (App Builder) |
+|---------|---------------------------|-------------------------|
+| Language | PHP | JavaScript or Node.js |
+| Package Management | Manages PHP packages and Commerce modules | Manages JavaScript packages and Node.js modules |
+| Dependency Resolution | Automatically resolves and installs dependencies | Automatically resolves and installs dependencies |
+| Version Control | Supports version constraints and ranges | Supports version constraints and ranges |
+| Autoloading | PSR-4 autoloading for PHP classes | CommonJS or ES6 module system (require/import) |
+| Repositories | Default: Packagist, supports private and custom repositories | Default: NPM registry, supports private and custom registries |
+| Scripts | Limited script capabilities (via Composer scripts) | Extensive script capabilities via scripts field in `package.json` |
+| Use Cases | Installing Commerce and third-party PHP modules | Installing Node.js modules, building serverless functions |
+| Configuration File | `composer.json` | `package.json` |
+| Example Command to Add Module | `composer require vendor/module-name` | `npm install module-name` |
+| Example Command to Update | `composer update` | `npm update` |
diff --git a/src/pages/app-development/index.md b/src/pages/app-development/index.md
index 7c7ff8a5..eb5175e7 100644
--- a/src/pages/app-development/index.md
+++ b/src/pages/app-development/index.md
@@ -1,75 +1,134 @@
---
-title: Adobe Commerce App Developer's Guide Overview
-description: Learn how to make the transition from developing Commerce PHP extensions to developing Out-of-Process apps.
+title: Extensibility in Adobe Commerce
+description: Learn about in-process, out-of-process, and hybrid extensibility
+contributor_name: Comwrap Reply GmbH
+contributor_link: https://www.comwrap.com
keywords:
- App Builder
- Extensibility
---
-# Adobe Commerce App Developer's Guide Overview
+# Extensibility in Adobe Commerce
-Developers have traditionally used PHP to create in-process extensions that add features, functionality, services, and integrations to Adobe Commerce. This model requires any new code to be compatible with upgrades, the server's PHP version, and many other essential server applications and services that Commerce uses.
+Adobe Commerce is known for its flexibility and extensibility, allowing businesses to adapt their e-commerce platforms to their unique needs. With the evolving demands of e-commerce, Adobe Commerce offers various methods for extending its capabilities. These methods can be broadly categorized into **in-process, out-of-process, and hybrid** extensibility. Adobe recommends using the out-of-process extensibility method where possible due to its ease of maintenance.
-Adobe Developer App Builder uses out-of-process extensibility to avoid these compatibility issues. It provides a unified third-party extensibility framework for integrating and creating custom apps that extend Adobe Commerce. Since this extensibility framework is built on Adobe's infrastructure, developers can also extend Adobe Commerce with third-party systems.
+## In-process extensibility
-## How do I port an extension into an app?
+In-process extensibility refers to the method where custom code or extensions run within the same process as the core Adobe Commerce application. This is the traditional and most commonly used approach for extending Adobe Commerce functionalities.
-Start by becoming familiar with the [App Builder documentation](https://developer.adobe.com/app-builder/docs/overview/) and [create an Adobe developer account](https://developer.adobe.com/app-builder/docs/overview/getting_access/).
+The advantages of this approach include:
-Once you've become comfortable with the Adobe I/O infrastructure, analyze your current extensions and begin mapping their in-process features into the App Builder and Adobe I/O environment. Key areas to consider include:
+* **Performance** - Since the custom code runs within the same process, it can directly interact with the core application, resulting in lower latency and faster execution times.
+* **Simplicity** - In-process extensions are typically easier to develop and deploy, as they leverage the existing infrastructure and codebase.
+* **Access to Core Functions** - Developers have direct access to the core functions and data structures of Adobe Commerce, allowing for deep customization.
-* Frontend development
-* APIs
-* Plugins and observers
-* Backend development
-* Custom cron jobs
-* Database data
-* Filesystem
+The in-process model has some considerations that you must account for:
-### Frontend development
+* **Resource contention**. Extensions share the same resources (CPU, memory) with the core application. Performance bottlenecks can be a result if these resources are not managed properly.
+* **Stability**. Poorly written extensions can potentially destabilize the entire application. It is crucial to perform extensive testing to ensure this doesn't happen.
-[Spectrum](https://spectrum.adobe.com/page/principles/) provides all the tools you need to create the next generation of React-based applications. You can use Spectrum UI components to build apps consistent with Adobe standards and leverage our SDK (#admin-development) to securely create custom app UIs in the Adobe Commerce Admin.
+In addition, Adobe Commerce has some functionality that you should not extend or build out-of-process:
-
+* Creating new blocks and components for native Adobe Commerce (Luma, Base) templates.
+* Modifying existing objects, such as customers, orders, and products.
-Adobe Commerce continues to support the [PWA Studio](https://developer.adobe.com/commerce/pwa-studio/) and [Luma](https://developer.adobe.com/commerce/frontend-core/) storefronts.
+### Use cases
-### APIs
+Developers have long used in-process extensibility solutions to provide additional functionality, such as the following:
-[API Mesh for Adobe Developer App Builder](https://developer.adobe.com/graphql-mesh-gateway/) enables developers to connect multiple APIs from Adobe Commerce, other Adobe products, and 3rd party sources into a single GraphQL endpoint. An orchestration layer transforms data from these disparate sources into the formats required to perform the tasks to fulfill business and user experience requirements.
+* **Customize the default checkout process** - Using in-process extensibility to modify the default checkout workflow allows for seamless integration with the core Adobe Commerce application. This integration enables precise adjustments, such as adding custom fields or changing the sequence of steps to complete the checkout process and better fit business needs.
-### Plugins and observers
+* **Add new payment gateways** - By integrating new payment gateways within the same process as the core application, businesses can ensure faster and more reliable payment processing, leveraging existing infrastructure for a smoother implementation.
-[Adobe I/O Events for Adobe Commerce](../events/index.md) enables building near real-time, event-driven Commerce integrations using App Builder. You can define key events, like customer account updates, to emit from Commerce and construct apps that listen and react to these events.
+* **Modify product display logic** - In-process adjustments to product display logic enable direct manipulation of the core application's data structures and functions, allowing for real-time updates to how products are presented, which can include adding of new custom attributes or PageBuilder sections.
-[Adobe Commerce Webhooks](../webhooks/index.md) enables configuring synchronous logic to execute calls from Commerce to external systems when key events occur. You can use this real-time communication with external systems to validate or modify data in Commerce.
+## Out-of-process extensibility
-### Admin development
+With out-of-process extensibility, custom code and extensions run in separate processes, often on different servers or services. This approach is increasingly popular with the rise of microservices and serverless architectures.
-The [Adobe Commerce Admin UI SDK](../admin-ui-sdk/index.md) enables an App Builder developer to extend the [Commerce Admin](https://experienceleague.adobe.com/docs/commerce-admin/start/admin/admin.html) to include custom menus and pages.
+The advantages of this approach include:
-### Custom cron jobs
+* **Isolation** - Custom code runs independently of the core application, reducing the risk of crashing or slowing down the main site.
+* **Scalability** - Out-of-process services can scale independently, allowing for better resource management and scalability.
+* **Technology agnostic** - Developers can use different programming languages or frameworks for their extensions, providing greater flexibility.
-App Builder uses Apache OpenWhisk Alarms to perform the scheduling services traditionally provided by cron jobs. [Scheduling Cron Jobs with Alarms](https://developer.adobe.com/app-builder/docs/resources/cron-jobs/) walks you through the process of implementing this feature.
+When choosing out-of-process extensibility, Adobe provides developers with serverless runtime to host their apps, which reduces overhead for developers.
-### Database data
+### Use cases
-The [Adobe I/O Key/Value Storage library](https://github.com/adobe/aio-lib-state) is an npm module that provides a JavaScript abstraction on top of distributed/cloud databases with a simple key-value store state persistence API.
+The following use cases illustrate ideal candidates for out-of-process extensibility:
-### Filesystem
+* Integrating with third-party services, such as Customer Relationship Management (CEM) and marketing automation.
-The [Adobe I/O Files library](https://github.com/adobe/aio-lib-state) provides a JavaScript abstraction on top of cloud blob storages with a simple file-system like persistence API.
+ Running integrations as separate processes allows for seamless communication with external systems like CRM or marketing automation tools. This approach enables efficient data exchange and synchronization without impacting the core application's performance.
-## Related information
+* Handling intensive processing tasks, such as data analysis and image processing.
-View the following tutorials for more information about using App Builder to build out-of-process apps:
+ Offloading resource-intensive tasks such as data analysis or image processing to separate processes ensures these operations do not burden the main application, allowing for better scalability and performance.
-* [Introduction to App Builder](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/introduction-to-app-builder.html)
+* Implementing microservices for specific functionalities, such as search and product recommendations.
-* [Extensibility Framework for App Builder](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/extensibility-framework-commerce-eventing.html)
+ Using microservices to handle specific functions like search or recommendations provides specialized, scalable solutions that can be independently developed, deployed, and maintained, improving overall system modularity and flexibility.
-* [Functional demonstration for App Builder](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/app-builder-functional-demonstration.html)
+### Example
-* [Build your first App Builder app](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/first-app/overview.html)
+A typical task for most e-commerce projects is to export orders from Adobe Commerce system to an external Order Management Systems. With Adobe App Builder, you can build an out-of-process microservice to seamlessly transfer this data. (We will name this service _Order Export Service (OES)_.) This service operates independently of the core Commerce application, ensuring efficient data synchronization and reducing the load on the backend. It can leverage APIs and webhooks to facilitate real-time and batch data export, providing a robust solution for keeping the OMS system up to date with the latest order information.
-* [Get started with API Mesh](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/api-mesh/getting-started-api-mesh.html)
+The following diagram illustrates an out-of-process implementation using this service.
+
+
+
+Configure Commerce to trigger [webhooks](https://developer.adobe.com/commerce/extensibility/webhooks/) whenever a customer places an order. These webhooks send order data to the OES. You can achieve this with [Adobe I/O Events for Adobe Commerce](https://developer.adobe.com/commerce/extensibility/events/).
+
+The OES running on App Builder has the following characteristics:
+
+* The service exposes an API endpoint to receive order data from Commerce. This endpoint handles both real-time webhook calls and batch data transmissions.
+
+* The service processes and transforms the incoming order data into a format compatible with the OMS system. This may involve mapping Commerce order fields to corresponding OMS fields, converting data types, and aggregating related information.
+
+* Robust error handling mechanisms are in place to log any issues encountered during data transformation and transmission, ensuring data integrity and providing alerts for troubleshooting.
+
+The service communicates with the OMS system via its API. It transmits order data to the OMS in real-time, depending on the configuration. The service handles API rate limits and retries in case of network or service disruptions.
+
+## Hybrid Extensibility
+
+Hybrid extensibility combines elements of both in-process and out-of-process approaches, leveraging the strengths of each. This method allows for more flexible and resilient extensions while maintaining the performance benefits of in-process code where necessary.
+
+Advantages of this approach include:
+
+* **Flexibility** - Developers can choose the best approach for each specific functionality, allowing for a more tailored solution.
+* **Resilience** - Critical functionalities can be isolated to prevent cascading failures, while less critical or performance-sensitive tasks can be handled in-process.
+* **Optimization** - Hybrid models can optimize performance and resource utilization by balancing in-process and out-of-process workloads.
+
+Alternatively, management can be more difficult:
+
+* Managing hybrid solutions requires careful coordination to ensure seamless communication and integration between in-process and out-of-process components.
+* Efficiently balancing resources between in-process and out-of-process tasks is crucial to avoid bottlenecks and ensure optimal performance.
+
+### Use Cases
+
+The following use cases describe ideal candidates for hybrid extensibility:
+
+* Complex integrations that require both real-time processing and asynchronous tasks.
+* Scenarios where maintaining performance is critical, but isolation is also necessary for certain tasks.
+* Integrations where API coverage of Adobe Commerce is not sufficient but required.
+
+### Example
+
+Recall the out-of-process extensibility example, where the following processes are carried out.
+
+1. A webhook sends order information to the App Builder instance.
+1. App Builder transforms the data to meet the OMS requirements.
+1. App Builder sends the data to OMS.
+
+But what if you need to request additional information from Adobe Commerce to complete the order export? For example, you are exporting an order, but the OMS also requires the customer object to be imported before it can accept the order information. In this case, your App Builder application must make an additional call to Commerce to retrieve the customer data. Perhaps the customer object has some custom metadata that is not available via the default GraphQL or REST APIs?
+
+For this use case, you must develop an extension on the Adobe Commerce side that modifies the GraphQL response, performs some custom logic on the Adobe Commerce instance, and delivers the expected results back.
+
+
+
+## Conclusion
+
+Adobe Commerce's extensibility options provide robust mechanisms for customizing and enhancing e-commerce platforms. In-process extensibility offers simplicity and performance, making it ideal for direct customizations. Out-of-process extensibility provides isolation and scalability, suitable for complex integrations and intensive tasks. Hybrid extensibility offers the best of both worlds, combining flexibility and resilience.
+
+Choosing the right extensibility method depends on the specific needs of the business, the complexity of the required customizations, and the desired performance and scalability outcomes. By leveraging these extensibility approaches, businesses can create a highly customized and efficient e-commerce platform tailored to their unique requirements.
diff --git a/src/pages/app-development/port-extensions.md b/src/pages/app-development/port-extensions.md
new file mode 100644
index 00000000..279cdcc1
--- /dev/null
+++ b/src/pages/app-development/port-extensions.md
@@ -0,0 +1,77 @@
+---
+title: Port extensions to App Builder apps
+description: Learn how to make the transition from developing Commerce PHP extensions to developing Out-of-Process apps.
+keywords:
+ - App Builder
+ - Extensibility
+---
+
+# Port extensions to App Builder apps
+
+Developers have traditionally used PHP to create in-process extensions that add features, functionality, services, and integrations to Adobe Commerce. This model requires any new code to be compatible with upgrades, the server's PHP version, and many other essential server applications and services that Commerce uses.
+
+Adobe Developer App Builder uses out-of-process extensibility to avoid these compatibility issues. It provides a unified third-party extensibility framework for integrating and creating custom apps that extend Adobe Commerce. Since this extensibility framework is built on Adobe's infrastructure, developers can also extend Adobe Commerce with third-party systems.
+
+## How do I port an extension into an app?
+
+Start by becoming familiar with the [App Builder documentation](https://developer.adobe.com/app-builder/docs/overview/) and [create an Adobe developer account](https://developer.adobe.com/app-builder/docs/overview/getting_access/).
+
+Once you've become comfortable with the Adobe I/O infrastructure, analyze your current extensions and begin mapping their in-process features into the App Builder and Adobe I/O environment. Key areas to consider include:
+
+* Frontend development
+* APIs
+* Plugins and observers
+* Backend development
+* Custom cron jobs
+* Database data
+* Filesystem
+
+### Frontend development
+
+[Spectrum](https://spectrum.adobe.com/page/principles/) provides all the tools you need to create the next generation of React-based applications. You can use Spectrum UI components to build apps consistent with Adobe standards and leverage our SDK (#admin-development) to securely create custom app UIs in the Adobe Commerce Admin.
+
+Alternatively, you can use native HTML with CSS to create your UI components.
+
+
+
+Adobe Commerce continues to support the [PWA Studio](https://developer.adobe.com/commerce/pwa-studio/) and [Luma](https://developer.adobe.com/commerce/frontend-core/) storefronts.
+
+### APIs
+
+[API Mesh for Adobe Developer App Builder](https://developer.adobe.com/graphql-mesh-gateway/) enables developers to connect multiple APIs from Adobe Commerce, other Adobe products, and 3rd party sources into a single GraphQL endpoint. An orchestration layer transforms data from these disparate sources into the formats required to perform the tasks to fulfill business and user experience requirements.
+
+### Plugins and observers
+
+[Adobe I/O Events for Adobe Commerce](../events/index.md) enables building near real-time, event-driven Commerce integrations using App Builder. You can define key events, like customer account updates, to emit from Commerce and construct apps that listen and react to these events.
+
+[Adobe Commerce Webhooks](../webhooks/index.md) enables configuring synchronous logic to execute calls from Commerce to external systems when key events occur. You can use this real-time communication with external systems to validate or modify data in Commerce.
+
+### Admin development
+
+The [Adobe Commerce Admin UI SDK](../admin-ui-sdk/index.md) enables an App Builder developer to extend the [Commerce Admin](https://experienceleague.adobe.com/docs/commerce-admin/start/admin/admin.html) to include custom menus and pages.
+
+### Custom cron jobs
+
+App Builder uses Apache OpenWhisk Alarms to perform the scheduling services traditionally provided by cron jobs. [Scheduling Cron Jobs with Alarms](https://developer.adobe.com/app-builder/docs/resources/cron-jobs/) walks you through the process of implementing this feature.
+
+### Database data
+
+The [Adobe I/O Key/Value Storage library](https://github.com/adobe/aio-lib-state) is an npm module that provides a JavaScript abstraction on top of distributed/cloud databases with a simple key-value store state persistence API.
+
+### Filesystem
+
+The [Adobe I/O Files library](https://github.com/adobe/aio-lib-state) provides a JavaScript abstraction on top of cloud blob storages with a simple file-system like persistence API.
+
+## Related information
+
+View the following tutorials for more information about using App Builder to build out-of-process apps:
+
+* [Introduction to App Builder](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/introduction-to-app-builder.html)
+
+* [Extensibility Framework for App Builder](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/extensibility-framework-commerce-eventing.html)
+
+* [Functional demonstration for App Builder](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/app-builder-functional-demonstration.html)
+
+* [Build your first App Builder app](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/first-app/overview.html)
+
+* [Get started with API Mesh](https://experienceleague.adobe.com/docs/commerce-learn/tutorials/adobe-developer-app-builder/api-mesh/getting-started-api-mesh.html)
diff --git a/src/pages/app-development/services-comparison.md b/src/pages/app-development/services-comparison.md
new file mode 100644
index 00000000..29bfd661
--- /dev/null
+++ b/src/pages/app-development/services-comparison.md
@@ -0,0 +1,169 @@
+---
+title: Services Comparison
+description: Learn about the differences in services between Adobe Commerce and App Builder.
+contributor_name: Comwrap Reply GmbH
+contributor_link: https://www.comwrap.com/en.html
+keywords:
+ - App Builder
+ - Extensibility
+---
+
+# Services comparison
+
+This guide highlights key differences and benefits of using Adobe Developer App Builder services over services available within Adobe Commerce. It provides a comparison of services used in both platforms and outlines the differences in their implementation and usage.
+
+For more comparison information, refer to:
+
+- [Out-of-process extensibility overview](../index.md)
+- [Coding convention](./app-development-comparison.md#coding-conventions)
+- [Integrating third-party modules](./app-development-comparison.md#integrating-third-party-modules)
+
+## Persistent Storage
+
+This section compares the persistent storage solutions used in Commerce to those in App Builder.
+
+### Commerce
+
+**MySQL**
+
+MySQL is a relational database management system (RDBMS) used to store and manage structured data.
+
+
+
+Modifying the default MySQL database can cause upgrade issues. Adobe recommends using App Builder with state database for simple app-specific data or a third-party database for more complex needs.
+
+Features:
+
+- Supports SQL for querying data.
+- ACID (Atomicity, Consistency, Isolation, Durability) compliance ensures reliable transactions.
+- Schema-based structure with tables, rows, and columns.
+- Powerful indexing and searching capabilities.
+- Supports complex joins and relationships between tables.
+
+Use Cases:
+
+- Storing any data you need in persistent storage for your extension business logic.
+
+**Redis**
+
+Redis is an in-memory data structure store used as a database, cache, and message broker.
+
+Features:
+
+- Fast read and write operations.
+- Supports multiple data structures like strings, hashes, lists, sets, and sorted sets.
+- Persistence options to save data to disk.
+- Pub/Sub messaging functionality.
+- High availability and partitioning (Redis Cluster).
+
+Use cases:
+
+- Caching frequently accessed data.
+- Session management.
+- Real-time analytics and leaderboard systems.
+
+### App builder
+
+**Recommended method**
+
+[State Database](https://developer.adobe.com/app-builder/docs/guides/application_state/) is a key-value store provided by [Adobe I/O Runtime](https://developer.adobe.com/runtime/docs/guides/overview/) to store and manage stateful data.
+
+Features:
+
+- Simple key-value storage.
+- Supports CRUD operations with APIs.
+- Designed for fast read and write operations.
+- Integrated with Adobe I/O Runtime, so you can use it within serverless workflows.
+
+Use cases:
+
+State Database allows you to store information required for operational microservices. It is ideal for storing simple, unstructured data. However, for more complex data storage needs, external databases such as MySQL are often necessary.
+
+State Database is a straightforward and efficient way to store basic data in key-value pairs. This type of storage is highly suitable for:
+
+- Configuration settings - Storing application configuration parameters.
+- Session data - Maintaining session information for users.
+- Cache data - Temporarily storing frequently accessed data to improve performance.
+- Simple data structures - Handling simple data that does not require complex querying or relational integrity.
+
+These features allow for quick access and retrieval of data, making it an excellent choice for scenarios where the data structure is not complex.
+
+
+
+The [maximum TTL](https://developer.adobe.com/app-builder/docs/guides/application_state/#feature-matrix) for all Application State entities is limited to 365 days.
+
+#### External Databases for Complex Solutions
+
+When a microservice requires more advanced data management capabilities, such as intricate querying, transactional support, or relational integrity, consider external databases. MySQL, a widely-used relational database, is a prime example of an external database that can handle these requirements.
+
+External databases are essential for:
+
+- Complex Queries - Running sophisticated SQL queries to retrieve data based on multiple conditions.
+- Transactional Support - Ensuring data integrity and consistency through ACID (Atomicity, Consistency, Isolation, Durability) properties.
+- Relational Data - Managing relationships between different types of data, which is crucial for maintaining data integrity and reducing redundancy.
+- Scalability - Supporting large-scale data storage and processing needs as the application grows.
+
+## File storage
+
+This section compares the file storage solutions between Commerce and App Builder.
+
+### Commerce
+
+Commerce uses local file systems or cloud-based storage solutions to manage files.
+
+Use cases:
+
+- Media management - Storing images, videos, and other multimedia files used in the e-commerce storefront.
+- Product assets - Managing product-related files such as manuals, specifications, and related documents.
+- Configuration files - Keeping system and application configuration files that are essential for the proper functioning of the storefront.
+- Logs - Storing application log files.
+
+For massive data flows, you can consider external storage as an option.
+
+### App Builder
+
+**Recommended method**
+
+App builder uses an Adobe I/O Runtime service to store and manage files.
+
+Features:
+
+- Supports storing multiple file types (images, documents, and more).
+- Integrated with Adobe I/O Runtime for easy access and manipulation.
+- Provides APIs for uploading, downloading, and managing files.
+- Suitable for large file storage and media management.
+
+Use cases:
+
+- Storing media assets (images and videos).
+- Managing document storage.
+- Large data exports and imports.
+- Storing information that is too big for state storage.
+
+For massive data flows, you can consider external storage as an option.
+
+## Search and OpenSearch
+
+This section compares the search capabilities between Adobe Commerce and App Builder.
+
+### Commerce
+
+- OpenSearch - Adobe Commerce utilizes OpenSearch as its primary search engine. OpenSearch is a highly scalable, open-source search and analytics engine, which is a fork of Elasticsearch and provides similar functionalities.
+- Live Search - Adobe Commerce has integrated [Live Search](https://experienceleague.adobe.com/en/docs/commerce-merchant-services/live-search/overview) as a standard feature, which provides advanced search capabilities powered by Adobe Sensei, a suite of AI and machine learning technologies. Live Search delivers more relevant and personalized search results to users, enhancing the shopping experience.
+- Third-party integrations - For businesses with specific needs or preferences, Adobe Commerce supports the integration of third-party search solutions.
+
+### App Builder
+
+**Recommended method**
+
+Adobe App Builder does not come with a built-in full-text search service. However, developers can integrate external search services or implement custom search functionalities using multiple tools and technologies:
+
+Integrating OpenSearch: Developers can deploy OpenSearch as an external service and integrate it with their App Builder applications to provide robust search capabilities.
+
+- Adobe Live Search - Live Search provides advanced search capabilities powered by Adobe Sensei, a suite of AI and machine learning technologies.
+- Adobe Experience Manager (AEM): For applications closely integrated with AEM, developers can leverage AEM's search capabilities.
+- Custom Search Solutions: Implementing custom search logic using database queries, indexing techniques, and third-party search APIs.
+
+
+
+By default, App Builder does not have an integrated search solution, you will need to integrate your own solution.