Escaping the Adobe App Builder: Building Serverless Commerce Integrations on Your Own Terms
Why enterprise developers are rejecting proprietary Node.js runtimes in favor of AWS Lambda, Python, and cloud-native freedom.
If you are building on Adobe Commerce today, you know the push is on. The monolith is out; composable, out-of-process SaaS architectures are in. To facilitate this, Adobe heavily promotes Adobe App Builder (built on Adobe I/O Runtime and Apache OpenWhisk) as the default way to write custom integrations, webhooks, and microservices without Hyva crap.
On paper, it sounds great: a fully managed, serverless eventing framework tightly integrated into the Adobe ecosystem.
In practice? It is a masterclass in vendor lock-in, forcing engineering teams to write bloated Node.js boilerplate inside a proprietary black box.
As a DevOps architect, I watch teams struggle with this transition. Instead of writing clean business logic, developers spend their time fighting configuration yaml manifests, navigating endless node_modules dependency chains, and figuring out how to debug inside Adobe’s walled garden.
There is a better way. You do not have to use App Builder to integrate with Adobe Commerce. You can build faster, cleaner, and completely lock-in-free microservices using AWS Lambda and Python.
Here is why many enterprise merchants are making the switch, and how an open-source Python framework makes it effortless.
The Problem with Adobe App Builder
When you commit your integration layer to App Builder, you are making architectural sacrifices that have long-term consequences.
1. The Ultimate Vendor Lock-in
App Builder binds your custom business logic directly to Adobe’s infrastructure, routing pipelines, and authorization mechanisms. If you ever decide to replatform, or simply want to move a generic microservice (like an ERP sync or a PIM transformer) to your own AWS environment, you cannot just lift and shift. You have to completely rewrite it.
2. The Node.js Dependency Nightmare
App Builder relies heavily on Node.js. For simple serverless integrations, Node.js often results in deeply nested, high-maintenance code. You end up managing heavy runtime overhead and security vulnerabilities in third-party packages just to process a basic webhook payload. It is the definition of bloated code.
3. Limited DevOps Tooling
Enterprise architectures require standard, mature tooling. When you use App Builder, you are trading the infinite observability of AWS CloudWatch, X-Ray, and native Terraform support for a constrained, multi-tenant layer managed by a vendor whose primary expertise is not infrastructure-as-a-service.
The Alternative: AWS Lambda + Python
If you strip away the marketing, what is an Adobe Commerce integration? It is an event (a webhook or an Adobe I/O Event) that triggers a function, transforms some data, and sends it somewhere else.
You don’t need a proprietary platform for this. You need AWS Lambda.
By routing Adobe Commerce webhooks through an AWS API Gateway to a Lambda function, you get:
- Zero Lock-in: Your code runs on standard AWS infrastructure. It is yours.
- Incredible Performance: Python on AWS Lambda boasts incredibly fast cold starts (often under 50ms) and a lean memory footprint.
- Massive Scalability: It naturally handles massive traffic spikes — like Black Friday order volumes — without breaking a sweat.
- Clean Code: Python is readable, maintainable, and devoid of the callback-hell and deep dependency trees that plague Node.js serverless functions.
Introducing lambda-toolkit: The Micro-Framework for Commerce
To make this architecture as seamless as possible, we open-sourced lambda-toolkit—a lightweight AWS Lambda micro-framework written in Python.
Get Yegor Shytikov’s stories in your inbox
Join Medium for free to get updates from this writer.
It strips away the unnecessary layers of traditional frameworks (like Flask or Django, which are too heavy for Lambda) and gives you a clean, declarative routing environment tailored specifically for handling event-driven commerce workflows.
How It Works
Instead of maintaining dozens of fragmented files and complex configuration manifests, lambda-toolkit lets you write clean, pythonic microservices.
When an event occurs in Adobe Commerce (e.g., sales_order_place), it fires an HTTP POST request. Your API Gateway catches it, and lambda-toolkit routes it beautifully:
from lambda_toolkit import LambdaToolkit
app = LambdaToolkit()
@app.route('/commerce/webhook/order-sync', methods=['POST'])
def handle_order_placement(request):
# Extract the payload sent by Adobe Commerce
order_data = request.json
order_id = order_data.get('entity_id')
# Your custom Python business logic goes here
# E.g., Map to ERP schema, save to DynamoDB, or send to SQS
print(f"Processing order #{order_id} via lean Python worker.")
return {"status": "success", "processed_order": order_id}, 200
# AWS Lambda entry point
def handler(event, context):
return app.run(event, context)That’s it. No lock-in. No bloated Node packages. Just standard, highly performant Python code executing on AWS infrastructure that you control.
In Adobe App Builder, you cannot do this in a single file with an elegant decorator. It requires a rigid configuration architecture consisting of a JavaScript/Node.js action file and an ext.config.yaml configuration manifest to set up the routing and permissions.
1. The Action Code (actions/order-sync/index.js)
Instead of standard request parsing, App Builder actions run on Apache OpenWhisk, requiring you to handle a generic params object and manually construct an HTTP response payload.
const { Core } = require('@adobe/aio-sdk')
// Main entry point for the Adobe App Builder Action
async function main (params) {
// Initialize Adobe Logger
const logger = Core.Logger('order-sync', { level: 'info' })
try {
// In App Builder, incoming POST bodies are mapped straight onto the 'params' object
const orderData = params;
const orderId = orderData.entity_id;
if (!orderId) {
return {
statusCode: 400,
body: { error: 'Missing entity_id in payload.' }
};
}
// Your custom Node.js business logic goes here
// E.g., fetch secrets from Adobe Vault, map to an ERP, etc.
logger.info(`Processing order #${orderId} via Node.js runtime.`);
// Return the specific JSON format expected by the App Builder router
return {
statusCode: 200,
headers: {
'Content-Type': 'application/json'
},
body: {
status: 'success',
processed_order: orderId
}
};
} catch (error) {
logger.error(error);
return {
statusCode: 500,
body: { error: 'Internal Server Error' }
};
}
}
// Export the main entry point
exports.main = main2. The Manifest Configuration (ext.config.yaml)
To make this code reachable as a webhook endpoint (/commerce/webhook/order-sync), you must register it in your application's package manifest file.
operations:
view:
- type: web
path: index.html
actions:
# Define the package name
commerce-integrations:
actions:
# Match the action folder name
order-sync:
function: actions/order-sync/index.js
web: 'yes' # Exposes it to the public internet
runtime: 'nodejs:18' # Forced Node.js environment dependency
inputs:
LOG_LEVEL: 'info'
# Annotation telling App Builder to bypass full JWT checking
# so Adobe Commerce webhooks can hit it natively
annotations:
require-adobe-auth: falseWhy You Should Use It
- Zero Infrastructure Bloat: The framework has virtually no dependencies, resulting in a tiny deployment package and ultra-fast cold starts.
- Familiar Syntax: If you know how to write standard Python web routes, you know how to use this framework.
- Complete Autonomy: You separate your core commerce platform from your custom edge logic. You pay only for exact execution time, utilize standard enterprise monitoring, and write code your DevOps team actually wants to maintain.
Reclaim Your Architecture
Choosing AWS Lambda and Python for your Adobe Commerce ecosystem isn’t just a technical preference; it is a strategic decision to maintain ownership over your application architecture.
Stop writing complex, vendor-locked boilerplate. Keep your Adobe Commerce ecosystem clean, decoupled, and fast.
Ready to build better integrations? Check out the code, fork it, and start building your serverless pipelines today.
Get lambda-toolkit on GitHub: Genaker/lambda-toolkit: AWS lambda micro framework on Python
