For many years, extending Magento and Adobe Commerce has followed a familiar approach: install a module directly inside the Commerce application, add PHP classes and configuration, integrate third-party APIs, and deploy everything as part of the Magento codebase.
That approach is still important, but Adobe Commerce extensibility is evolving.
One of the technologies driving this change is Adobe App Builder.
Adobe App Builder provides a cloud-native development platform that allows developers to build applications and integrations outside the Adobe Commerce core while communicating with Commerce through APIs, events, and other Adobe services.
For companies running complex Adobe Commerce stores, this opens the door to a different architecture.
Traditional Magento Extensions vs. App Builder
A traditional Magento extension generally runs inside the Magento application.
For example, a shipping integration might work like this:
Customer Checkout → Magento Shipping Module → Carrier API → Magento → Customer
The Magento server is responsible for executing the integration and waiting for responses from external services.
With an App Builder-based architecture, we can potentially move more integration logic outside Commerce:
Adobe Commerce → API / Event → Adobe App Builder → External Service
This separation can be especially valuable for large integrations involving multiple external systems.
Why Move Functionality Outside Adobe Commerce?
Magento is already responsible for a significant amount of work: catalog management, pricing, inventory, customers, checkout, orders, promotions, indexing, search, and much more.
Adding every business integration directly into the Magento application increases the amount of code that must be deployed and maintained.
Externalizing appropriate functionality can provide several benefits.
1. Reduce Magento Core Customization
Instead of placing all integration logic inside custom Magento modules, some functionality can run independently.
This can reduce the size and complexity of the Commerce application.
2. Easier Adobe Commerce Upgrades
Custom extensions can create additional work during Magento upgrades.
Every major upgrade may require checking PHP compatibility, Magento API changes, dependency changes, deprecated classes, plugins, observers, and other customizations.
Keeping suitable business logic outside Commerce can reduce this dependency.
3. Better Scalability
Some integrations require significant processing.
Shipping calculations, ERP synchronization, marketplace communication, inventory processing, or large API operations may not always need to execute directly on the Magento application server.
A cloud-native application architecture allows these workloads to be separated from Commerce.
4. Better Separation of Responsibilities
Instead of creating one large Magento application responsible for everything, functionality can be divided into specialized services.
For example:
Adobe Commerce
Handles products, customers, carts, checkout, and orders.
Shipping Application
Handles carriers, shipping rules, freight calculations, and rate normalization.
ERP Integration
Handles order and inventory synchronization.
Analytics Services
Handle reporting and data processing.
This approach moves Adobe Commerce architecture closer to a modern services-based model.
Example: Building an LTL Shipping App with Adobe App Builder
At EcomPlugins, shipping integrations have been one of our primary areas of Magento development.
LTL freight shipping is considerably more complicated than simply sending a ZIP code and package weight to a carrier.
A freight rate request may depend on:
- Origin and destination
- Freight class
- Product dimensions
- Weight
- Pallet information
- Residential or commercial delivery
- Liftgate requirements
- Inside delivery
- Limited-access locations
- Carrier-specific accessorial services
- Customer-specific carrier accounts
- Negotiated pricing
Traditionally, most of this logic would exist inside a Magento shipping extension.
With Adobe App Builder, we are exploring a different architecture.
Possible LTL App Architecture
Adobe Commerce Checkout
↓
Commerce API / Events
↓
EcomPlugins LTL Shipping App
↓
Carrier Integration Layer
↓
FedEx Freight / Estes / R+L Carriers / XPO / Other LTL Carriers
↓
Normalized Freight Rates
↓
Adobe Commerce Checkout
Instead of building all carrier integrations directly into Magento, the shipping application can become an independent integration layer.
One API, Multiple LTL Carriers
This architecture becomes particularly interesting when multiple carriers are involved.
Different freight carriers return completely different API structures.
One carrier might return:
service_name
total_charge
transit_days
Another carrier may use entirely different field names and response structures.
The application layer can normalize those responses into one consistent format before returning them to Adobe Commerce.
For example:
Carrier A: $425 – 3 Days
Carrier B: $398 – 4 Days
Carrier C: $447 – 2 Days
Adobe Commerce does not necessarily need to understand the internal API structure of every carrier.
It only needs the final shipping options.
Beyond Rate Quotes
An external shipping application could eventually handle much more than checkout rates.
The same platform could support:
- LTL rate shopping
- Bill of Lading generation
- Shipment creation
- Pickup requests
- PRO number management
- Shipment tracking
- Delivery status updates
- Freight document storage
- Shipping rules
- Carrier account management
- Shipping analytics
- Delayed shipment detection
- Customer notifications
This starts to transform a Magento shipping extension into a broader shipping platform connected to Adobe Commerce.
Does This Mean Traditional Magento Extensions Are Going Away?
No.
There are many situations where a normal Magento module remains the simplest and most effective solution.
The important change is that developers now have another architectural option.
Instead of automatically asking:
“How do we build this Magento module?”
we can first ask:
“Does this functionality actually need to run inside Magento?”
That is a much more important architectural question.
In some cases, a traditional Magento extension will still be the right answer.
In other cases, APIs, events, Adobe App Builder, and external services may provide a cleaner long-term architecture.
What This Means for Magento Developers
Magento development is increasingly becoming more than PHP module development.
Developers working with modern Adobe Commerce environments need to understand:
- REST and GraphQL APIs
- Event-driven architecture
- Webhooks
- Serverless applications
- API security
- Authentication
- Cloud services
- Asynchronous processing
- Microservices architecture
- External application development
PHP and Magento framework knowledge remain extremely valuable, but the surrounding architecture is becoming broader.
What We Are Exploring at EcomPlugins
At EcomPlugins, we have spent years developing Magento and Adobe Commerce shipping extensions and custom integrations.
We are now exploring how Adobe App Builder can be used to build the next generation of those integrations.
One of our current areas of research and development is an EcomPlugins LTL Shipping App for Adobe Commerce, designed around a more decoupled architecture for communicating with multiple freight carriers.
Our goal is not simply to replace Magento extensions.
The goal is to determine where traditional Magento modules make sense and where cloud-native applications can provide a more scalable and maintainable solution.
Adobe Commerce extensibility is changing, and we believe understanding both approaches will become increasingly important.
Need Custom Adobe Commerce Development?
If your business needs a custom Adobe Commerce integration, shipping solution, LTL freight integration, Magento extension, or help modernizing an existing Magento customization, EcomPlugins can help.
We specialize in Magento and Adobe Commerce shipping solutions, custom development, API integrations, and complex ecommerce requirements.
Contact EcomPlugins to discuss your Adobe Commerce project.