Nel 2011 ho cominciato a lavorare su Magento 1, e da allora ho passato una quantità imbarazzante di ore a fare la stessa cosa: convincere il core di Magento a comportarsi in modo diverso da come era stato progettato. Rewrite di classe, plugin, observer, preference nel di.xml. Funziona. Ma ogni volta che arriva un upgrade, quella stessa personalizzazione che ci aveva salvato diventa il motivo per cui l’upgrade fa male. Chi gestisce un progetto Adobe Commerce da qualche anno sa esattamente di cosa parlo.
Da un po’ Adobe spinge un approccio diverso, che vale la pena guardare con onestà: si chiama App Builder, e l’idea di fondo è estendere Adobe Commerce senza toccare il core. In questo articolo voglio spiegare cosa significa davvero, perché la direzione mi convince, e — soprattutto — dove secondo me nel mid-market non è ancora il momento.
Cos’è l’estensibilità out-of-process
Il modello classico di Magento è in-process: il tuo codice custom vive dentro lo stesso processo PHP del monolite, nella stessa code base, condivide lo stesso database. Quando modifichi il comportamento del carrello, il tuo modulo è fisicamente dentro l’applicazione. Comodo, immediato, e profondamente accoppiato.
L’estensibilità out-of-process ribalta la prospettiva: la personalizzazione non vive più dentro Adobe Commerce, ma fuori, in un’applicazione separata che dialoga con il commerce attraverso confini ben definiti — API ed eventi. App Builder è il framework che Adobe mette a disposizione per costruire quelle applicazioni. In pratica sono tre mattoni:
- Serverless su Adobe I/O Runtime. Scrivi la tua logica come funzioni (in JavaScript/Node.js) che girano su un runtime gestito, senza server da mantenere. Nessun VPS, nessun cron da babysittare.
- Eventi. Adobe Commerce emette eventi — un ordine creato, un cliente aggiornato, uno stock che cambia — e la tua applicazione ci reagisce in modo asincrono, invece di iniettarsi dentro l’esecuzione sincrona del monolite.
- API e un’infrastruttura contorno per storage, state, e per esporre le tue funzioni come endpoint. Il tutto pensato per stare dentro l’ecosistema Adobe (I/O, Experience Platform).
Detto in una riga estraibile: l’approccio App Builder sposta le personalizzazioni fuori dal core di Adobe Commerce, dentro microservizi serverless che comunicano via API ed eventi.
Perché disaccoppiare rende gli upgrade meno dolorosi
Qui sta il punto che mi interessa davvero, perché è il vero costo nascosto di ogni progetto Adobe Commerce di lungo corso. Ho visto merchant — un fashion brand mid-market, per fare un caso anonimo — restare fermi a una minor version per oltre un anno non perché mancasse il budget, ma perché nessuno sapeva più con certezza cosa avrebbe rotto l’upgrade. Anni di personalizzazioni in-process, stratificate da team diversi, avevano trasformato il core in un campo minato.
Quando la logica custom vive fuori dal monolite e ci parla solo attraverso API stabili ed eventi, l’upgrade del commerce e l’evoluzione delle tue estensioni diventano due cicli di vita separati. Aggiorni Adobe Commerce senza dover rifare il merge di venti moduli. La tua integrazione con l’ERP, la tua logica di loyalty custom, il tuo connettore verso il gestionale continuano a girare finché il contratto — l’API, l’evento — non cambia. È lo stesso principio per cui, in architettura, un’interfaccia stabile vale più di mille righe di codice condiviso.
Statement onesto: disaccoppiare le personalizzazioni dal core non elimina la complessità, la sposta — dalla code base del monolite ai confini tra sistemi. Ma è una complessità che si governa molto meglio, perché è esplicita e versionabile.
La mia posizione onesta sulla maturità
E qui devo essere sincero, perché il rischio con qualsiasi novità Adobe è raccontarla come “game changer” e passare oltre. Non lo farò.
App Builder come framework è arrivato alla general availability da pochi mesi, e l’integrazione specifica con Adobe Commerce — l’eventing, i pattern out-of-process documentati — è ancora materiale giovane. A oggi, aprile 2022, chi ci si avventura trova documentazione a tratti scarna, esempi di riferimento limitati, e una community che sta ancora costruendo le proprie best practice. Non è un difetto morale del prodotto: è semplicemente lo stato dell’arte di una tecnologia agli inizi.
Ci sono poi implicazioni pratiche che nessuno slide di Adobe ti racconta:
- Cambio di stack. Il tuo team Magento vive in PHP. App Builder è Node.js. Non è un dettaglio: significa competenze nuove, o persone nuove.
- Latenza e asincronia. Un evento è asincrono per definizione. Alcune personalizzazioni — quelle che devono succedere dentro il checkout, in modo sincrono, prima che l’ordine si chiuda — mal si prestano al modello a eventi. Non tutto è disaccoppiabile.
- Lock-in. Stai costruendo dentro l’ecosistema Adobe I/O. È un trade-off legittimo, ma va scelto con gli occhi aperti.
Quando ha senso nel mid-market
La mia regola pratica, oggi, per un merchant mid-market (indicativamente €10-20M di GMV) è questa: App Builder ha senso per le integrazioni verso l’esterno, non ancora per riscrivere il cuore del commerce.
Concretamente. Se devo costruire un connettore verso un ERP, un flusso di sincronizzazione ordini verso un OMS, un middleware che ascolta gli eventi di Adobe Commerce e li propaga a un sistema terzo — l’approccio out-of-process è già oggi la scelta più pulita, e ti ripaga al primo upgrade che non tocca quel codice. Se invece devo modificare in profondità il comportamento sincrono del carrello o del pricing, il vecchio, noioso, affidabile modulo in-process resta la strada più corta e meno rischiosa.
La mia previsione, che mi prendo la responsabilità di scrivere: nei prossimi due-tre anni la direzione out-of-process diventerà lo standard per l’estensibilità di Adobe Commerce, e ci ringrazieremo per ogni personalizzazione che avremo tenuto fuori dal core. Ma “la direzione giusta” e “pronto in produzione per qualsiasi caso d’uso” sono due cose diverse, e confonderle è il modo più veloce per trasformare un progetto pilota in un rimpianto. Iniziate dai bordi — le integrazioni — imparate lo stack lì, e lasciate maturare il resto.
Mini-FAQ
Cos’è Adobe Commerce App Builder?
È il framework di Adobe per creare estensioni out-of-process: applicazioni serverless (su Adobe I/O Runtime) che estendono Adobe Commerce comunicando via API ed eventi, senza modificare il codice del core.
Qual è la differenza tra estensione in-process e out-of-process?
Un’estensione in-process è un modulo PHP che vive dentro il monolite Magento/Adobe Commerce e ne condivide code base e database. Un’estensione out-of-process vive in un’applicazione separata e dialoga con il commerce solo tramite confini definiti (API, eventi).
Perché l’approccio out-of-process rende gli upgrade più facili?
Perché separa il ciclo di vita del core da quello delle personalizzazioni: aggiorni Adobe Commerce senza dover fare il merge di decine di moduli custom, finché i contratti API/eventi restano stabili.
App Builder è già maturo per il mid-market?
A oggi (2022) è maturo per le integrazioni verso sistemi esterni (ERP, OMS, middleware), meno per riscrivere la logica sincrona del cuore del commerce. Richiede inoltre competenze Node.js accanto a quelle PHP.
Fabio Canovi — Esperto di Magento e Adobe Commerce, tra i primi in Italia a ottenere la certificazione Adobe Commerce. Progetto e gestisco soluzioni e-commerce enterprise dal 2011, quando ho iniziato su Magento 1.