Stored procedures vs workflow visuali: dove dovrebbe vivere la logica

Cosa significa davvero questa decisione

La logica di business è l'insieme di regole che decidono cosa è permesso, cosa succede dopo e cosa deve fare il sistema quando le persone lo usano. Non è il dato in sé, ma il comportamento: chi può fare cosa, in quali condizioni e con quali effetti collaterali.

Quindi la discussione su stored procedures vs flussi di lavoro visuali riguarda soprattutto dove dovrebbero risiedere queste regole in modo che restino facili da cambiare, difficili da rompere e chiare per chi possiede il processo.

La maggior parte dei team finisce per avere tre “case” possibili per la logica:

• Nel database (stored procedure, trigger, vincoli): le regole girano vicino ai dati. Può essere veloce e coerente, ma più difficile da cambiare per chi non è specialista di database.
• Nei workflow visuali (process builders drag-and-drop): le regole sono espresse come passi e decisioni. Spesso è più facile da leggere, revisionare e adattare quando il processo cambia.
• Nel codice personalizzato (servizi, app, script): le regole sono scritte in un linguaggio di programmazione. Questo dà massima flessibilità, ma le modifiche richiedono di solito più disciplina ingegneristica e test.

La scelta impatta la velocità operativa quotidiana e la manutenzione a lungo termine. Mettere la logica nel posto sbagliato porta a consegne lente (ogni modifica richiede la persona che conosce il database), più errori (regole duplicate in più punti) e debug dolorosi (nessuno sa perché un record è stato rifiutato).

La maggior parte dei sistemi contiene diversi tipi di logica di business. Esempi comuni includono validazione (campi obbligatori, range consentiti), approvazioni, prezzi e sconti, notifiche e regole di accesso.

Un modo pratico per pensarci: il database è eccellente per proteggere l'integrità dei dati, i workflow visuali sono ottimi per esprimere processi di business e il codice personalizzato è indicato quando la regola è troppo unica o complessa da modellare pulitamente. Piattaforme come AppMaster stanno saldamente nel mezzo: puoi modellare i dati e poi implementare il processo come logica visiva leggibile senza spargere regole su molte app.

I criteri: cosa stai ottimizzando

Non è davvero una questione di gusto. Si tratta di cosa stai cercando di proteggere: i dati, le persone che cambiano il sistema e la velocità di cambiamento.

Gli esiti che contano di più

Nomina gli obiettivi principali per il tuo progetto. La maggior parte dei team bilancia una combinazione di questi:

• Correttezza: le regole devono eseguirsi sempre allo stesso modo, anche sotto carico.
• Chiarezza: una persona nuova dovrebbe capire cosa succede senza supposizioni.
• Velocità: la logica deve eseguire in modo rapido e vicino ai dati quando necessario.
• Auditabilità: devi poter dimostrare chi ha cambiato cosa e quando è stato eseguito.
• Frequenza di cambiamento: ti aspetti requisiti che cambiano settimanalmente, non annualmente.

Raramente massimizzi tutti e cinque. Spostare la logica più vicino al database può migliorare correttezza e velocità, ma ridurre la chiarezza per chi non vive in SQL.

Chi cambierà la logica (e quanto spesso)

Sii onesto su chi possiederà le modifiche giorno per giorno. Una regola che l'ops deve modificare ogni settimana non dovrebbe richiedere un DBA per distribuire una stored procedure. Allo stesso tempo, una regola che riguarda soldi non dovrebbe essere modificabile senza revisione.

Pensa in termini di attrito al cambiamento. Se i requisiti cambiano spesso, vuoi un posto dove gli aggiornamenti siano sicuri, visibili e rapidi da rilasciare. I tool di workflow visuale (per esempio, il Business Process Editor di AppMaster) funzionano bene quando product, ops e engineering devono collaborare sulla logica senza editare codice di basso livello. Se i cambiamenti sono rari e la regola è critica, un attrito maggiore può essere accettabile.

Un modo rapido per mettere alla prova la proprietà:

• Chi viene chiamato quando si rompe alle 2 di notte?
• Quanto velocemente devi correggere una regola?
• Le modifiche richiedono approvazioni o una traccia cartacea?
• Più app dipenderanno dalla stessa regola?
• La logica è soprattutto shaping dei dati o decisioni di business?

Nota i vincoli presto. Alcune industrie richiedono controllo degli accessi rigoroso, separazione dei compiti o log dettagliati. Considera anche i limiti di accesso ai dati: se solo certi servizi dovrebbero vedere certi campi, questo influenza dove la logica può essere eseguita in sicurezza.

Quando la logica appartiene alle stored procedure

Le stored procedure sono pezzi di logica che girano dentro il database. In PostgreSQL si scrivono in SQL (e talvolta in un linguaggio di database come PL/pgSQL). Invece di far uscire le righe dall'app, iterare e riscriverle, il database fa il lavoro dove risiedono i dati.

Una regola semplice: metti la logica nel database quando il compito principale è proteggere i dati e fare lavori su insiemi di dati, non coordinare persone o sistemi.

Dove le stored procedure brillano

Le stored procedure sono adatte per regole che devono essere sempre vere, qualunque app o integrazione tocchi il database. Pensa ai guardrail che impediscono dati errati.

Eccellono anche negli aggiornamenti set-based, dove una singola istruzione può aggiornare migliaia di righe in modo sicuro e veloce. Calcoli semplici che riguardano solo i dati, come computare totali o applicare una formula di sconto fissa, possono vivere qui quando riducono i round trip e mantengono risultati coerenti.

Esempio: quando un ordine viene segnato come paid, una procedure può aggiornare in modo atomico lo stato dell'ordine, decrementare l'inventario e scrivere una riga di audit. Se un passo fallisce, l'intera modifica viene rollbackata.

Quando le stored procedure diventano rischiose

Le stored procedure possono essere più difficili da testare e versionare rispetto al codice applicativo, specialmente se il team non tratta i cambi di database come vere release. La logica può anche diventare “nascosta” dall'app, creando accoppiamenti che scopri più tardi.

Il debug diventa inoltre più complesso. Gli errori possono emergere come messaggi di database con meno contesto su cosa abbia fatto l'utente. I nuovi membri faticano perché le regole sono divise tra app e database, e la logica nel database è facile da non notare durante l'onboarding.

Se usi uno strumento visuale per la maggior parte della logica, riserva le stored procedure per il nucleo piccolo e stabile che deve girare vicino ai dati. Tieni tutto il resto dove è più facile da leggere, tracciare e cambiare.

Quando la logica è più adatta ai workflow visuali

I workflow visuali sono logiche di processo passo-passo che puoi leggere come una checklist: quando succede qualcosa, esegui queste azioni in questo ordine, con punti di decisione chiari. Sono meno su calcoli pesanti e più su come il lavoro si muove tra persone, sistemi e tempo.

Brillano quando ti interessa la comprensione condivisa. Se product, ops, support e engineering devono concordare su come funziona un processo, un workflow visivo rende le regole visibili. Quella visibilità spesso fa la differenza tra “il sistema è rotto” e “il processo è cambiato la settimana scorsa.”

I workflow visuali sono solitamente adatti per approvazioni e revisioni, instradamenti, notifiche e promemoria, passi temporizzati (aspetta 2 giorni, poi scala) e integrazioni (chiama Stripe, invia un messaggio, aggiorna un CRM).

Esempio: un cliente richiede un rimborso. Il workflow controlla l'età dell'ordine, instrada a un manager se supera una soglia, notifica la finanza quando approvato e invia al cliente un aggiornamento. Ogni passo è facile da indicare e discutere in linguaggio semplice, il che aiuta gli stakeholder a convalidare e i nuovi membri a capire il “perché.”

Strumenti come il Business Process Editor di AppMaster sono pensati per questo tipo di logica: puoi vedere il percorso, le condizioni e gli effetti collaterali (messaggi, chiamate API, cambi di stato) senza scavare in script di database.

Per evitare che i workflow diventino spaghetti, tienili piccoli e leggibili. Dai a ogni workflow un solo risultato, usa nomi chiari per passi e rami, limita decisioni troppo nidificate e registra le scelte chiave così da poter rispondere dopo “perché è successo questo?”.

Quando un workflow inizia a fare calcoli complessi o a toccare molte tabelle, è spesso un segnale per spostare parte della logica altrove. I workflow visuali funzionano meglio come direttore d'orchestra, non come tutta l'orchestra.

Quando il codice personalizzato è lo strumento giusto

Il codice personalizzato è la logica che scrivi e mantieni come software: funzioni, servizi o librerie che girano come parte della tua app. È l'opzione più flessibile, e per questo dovrebbe essere usata con intenzione, non come default.

Il codice guadagna il suo posto quando la logica è difficile da esprimere in sicurezza in una stored procedure o in un workflow drag-and-drop. Se ti ritrovi a piegare gli strumenti per adattarli al problema, il codice spesso è più chiaro e più semplice da mantenere corretto.

Segnali forti per scegliere il codice:

• Il problema è algoritmico (regole di prezzo, pianificazione di rotte, scoring, matching, controlli antifrode) e ha molti casi limite.
• Hai bisogno di un'integrazione non ordinaria (API partner con auth strana, retry complessi, regole di idempotency rigorose).
• La performance è sensibile (elaborazioni ad alto volume, calcoli pesanti, caching attento) e hai bisogno di controllo stretto.
• Devi condividere la stessa logica in più punti (web, mobile, job batch) senza copiarla.
• Hai bisogno di forti test automatici attorno alla logica perché gli errori sono costosi.

Il codice rende anche più chiara la proprietà. Un team può essere responsabile di revisionare le modifiche, mantenere i test verdi e documentare il comportamento. Questo è meglio di “vive in tre workflow e nessuno è sicuro quale venga eseguito prima.”

Esempio: un motore di decisione per rimborsi che considera storia ordini, segnali antifrode, stato di spedizione e finestre temporali. Puoi comunque mantenere i passi di approvazione in un workflow visivo, ma la decisione vera e propria è spesso migliore come codice con unit test e versioning.

Il costo è reale. Il codice personalizzato richiede tempo ingegneristico, revisioni e manutenzione continua. Le modifiche possono richiedere più tempo che editare un workflow, e serve un processo di rilascio. AppMaster può ridurre quanto codice serve coprendo parti comuni con logica visiva e moduli, permettendo comunque di esportare sorgente ed estendere dove è davvero necessario.

Un framework passo-passo riutilizzabile

I team saltano spesso la parte più utile: scrivere la regola chiaramente, poi scegliere una casa che corrisponda a come la regola si comporta.

Usa questo framework ogni volta che appare una nuova logica:

• Scrivi la regola in una frase, poi etichettala. Se riguarda dati validi (vincoli, unicità, totali che devono combaciare), è una regola sui dati. Se riguarda passi e passaggi (approvazioni, attese, notifiche), è una regola di processo. Se è matematica pesante o trasformazioni complesse, è una regola di computazione.
• Chiedi chi la modifica e quanto spesso. Se persone non tecniche devono cambiarla ogni settimana, non seppellirla in SQL o in una release di codice. Se cambia raramente e deve essere applicata sempre, il database è candidato più forte.
• Verifica l'impatto di un errore e la traccia di audit necessaria. Se un errore può causare perdita di denaro, problemi di compliance o dati difficili da riparare, preferisci un posto con logging chiaro e controllo stretto.
• Scegli la posizione e definisci il confine. Sii esplicito su input, output ed errori. Esempio: “Dato un order_id, restituisci allowed_refund_amount o un codice motivo chiaro.” Quel confine evita che la logica si disperda ovunque.
• Tieni uno strato sottile. Decidi cosa dovrebbe restare per lo più “dumb” così non duplichi regole. Scelte comuni: mantenere il database sottile (solo integrità dei dati), mantenere i workflow sottili (solo orchestrazione) o mantenere il codice sottile (solo glue).

Regola pratica: metti le regole sui dati più vicine ai dati, le regole di processo in uno strumento di workflow e le regole di computazione dove sono più facili da testare e versionare.

Se usi una piattaforma come AppMaster, puoi trattare il database come guardrail (tabelle, relazioni, vincoli base) e usare il Business Process Editor visivo per le parti “chi fa cosa dopo”, riservando codice personalizzato per i pochi casi che lo richiedono.

Errori comuni che generano sistemi disordinati

I sistemi disordinati raramente nascono da una sola cattiva scelta. Succede quando la logica viene sparsa, nascosta o copiata finché nessuno sa più cosa fa davvero il sistema.

La duplicazione è il problema classico: la stessa regola esiste in due posti e poi si scordano. Esempio: il database rifiuta rimborsi sopra i $500 a meno che non ci sia un record di approvazione, ma un workflow continua a inviare la richiesta al pagamento perché controlla un limite diverso. Entrambi “funzionano” fino al primo caso limite reale, poi il support riceve un bug misterioso.

Le regole nascoste sono il passo successivo. Trigger, stored procedure e fix veloci nel database possono essere invisibili a chi costruisce l'UI o i workflow. Se la regola non è documentata vicino al workflow o all'API che dipende da essa, le modifiche diventano congetture e i test si trasformano in tentativi ed errori.

I workflow sovraccarichi creano un altro tipo di disordine. Una lunga catena drag-and-drop con decine di rami diventa un oggetto fragile che nessuno vuole toccare. In strumenti come AppMaster è facile aggiungere blocchi perché è veloce, ma la velocità di oggi può trasformarsi in confusione domani se il workflow non ha confini chiari.

Due errori opposti di eccesso causano dolore a lungo termine:

• Troppo nel database: ogni cambiamento di policy diventa un progetto di migration e piccoli aggiustamenti di prodotto aspettano release di database.
• Troppo nel codice applicativo: regole basilari sui dati (campi obbligatori, stati permessi, vincoli di unicità) vengono dimenticate e dati errati filtrano tramite importazioni, strumenti admin o future integrazioni.

Un'abitudine semplice previene la maggior parte di questo: tieni ogni regola in una casa primaria e scrivi dove vive e perché. Se non sai rispondere in 10 secondi a “dove è applicata questa regola?”, stai già pagando il prezzo del disordine.

Controlli rapidi: decidi in 2 minuti

Stai scegliendo dove è più facile mantenere una regola corretta, visibile e modificabile.

Inizia con una domanda: questa regola riguarda la correttezza dei dati, cioè non deve mai essere bypassata? Se sì, spingila più vicino al database. Se riguarda passi, approvazioni o notifiche, lasciala più vicino al layer workflow.

Una checklist veloce:

• Impone correttezza dei dati (evitare inventario negativo, bloccare record “active” duplicati)? Tendi al database.
• Tocca molte tabelle e richiede aggiornamenti set-based (molte righe alla volta)? Tendi al database.
• Serve una traccia leggibile di chi ha approvato cosa e quando? Tendi al workflow.
• Gli non ingegneri devono modificarla settimanalmente o mensilmente? Tendi al workflow.
• Chiama servizi esterni (pagamenti, messaggistica, AI)? Tendi all'applicazione o al workflow, non al database.

Ora pensa al fallimento. Una regola che può fallire dovrebbe fallire in modo che gli umani possano recuperare.

Se hai bisogno di retry sicuri e messaggi d'errore chiari, preferisci uno strato di orchestrazione dove puoi tracciare lo stato e gestire eccezioni passo per passo. I tool di workflow visuale spesso semplificano questo perché ogni passo è esplicito e può essere loggato.

Un tie-breaker pratico:

• Se il sistema deve rimanere corretto anche quando qualcuno scrive una nuova app in futuro, applicala nel database.
• Se il processo deve essere letto e revisionato dai team ops, lascialo in un workflow visivo.
• Se comporta integrazioni complesse, computazioni pesanti o librerie speciali, usa codice personalizzato.

Esempio: “L'importo del rimborso non può superare il pagamento originale” è correttezza, quindi applicalo vicino ai dati. “I rimborsi sopra $500 richiedono approvazione manager e poi inviano un messaggio Telegram” è un workflow. In AppMaster, quella catena di approvazione si adatta naturalmente al Business Process Editor, mentre vincoli rigorosi restano nel modello dati.

Scenario d'esempio: rimborsi con approvazioni

Un caso reale comune è un rimborso che richiede approvazione manager sopra una certa soglia, più notifiche e una traccia di audit pulita.

Inizia definendo una sorgente di verità: un singolo record Refund con importi e un campo di stato chiaro (per esempio: requested, needs_approval, approved, rejected, processing, paid, failed). Ogni parte del sistema dovrebbe leggere e scrivere quegli stessi campi, invece di mantenere stati paralleli in posti diversi.

Cosa appartiene al database

Metti le regole che proteggono il denaro e la consistenza dei dati più vicino ai dati.

Usa vincoli (e talvolta una stored procedure) per assicurarti che non si possa rimborsare più dell'importo catturato, rimborsare un ordine già completamente rimborsato, creare due richieste di rimborso attive per lo stesso ordine o modificare importi chiave dopo che il rimborso è stato approvato.

Mantieni anche l'aggiornamento atomico qui: quando si crea una richiesta di rimborso, scrivi la riga Refund e aggiorna i totali dell'Order in una sola transazione. Se una delle scritture fallisce, nulla deve aggiornarsi parzialmente.

Cosa va meglio in un workflow visuale

I passaggi di approvazione sono processo, non protezione dei dati. Un workflow visivo è una buona casa per instradare la richiesta al manager giusto, aspettare una decisione, aggiornare lo stato, inviare promemoria e notificare il richiedente.

Un flusso semplice potrebbe essere: create request -> se l'importo è sopra la soglia, imposta lo stato su needs_approval -> notifica manager -> se approvato, imposta approved -> notifica il richiedente -> se nessuna risposta in 24 ore, invia un promemoria.

In uno strumento come AppMaster, questo si mappa pulitamente a un Business Process che reagisce ai cambi di stato e attiva email, SMS o messaggi Telegram.

Cosa dovrebbe essere codice personalizzato

I provider di pagamento hanno casi limite che non sempre si adattano bene a regole o passi drag-and-drop. Tieni la logica specifica del provider in codice personalizzato, come rimborsi parziali con commissioni o pagamenti multi-capture, riconciliazione di webhook (il provider dice “paid” ma la tua app dice “processing”) e gestione di idempotency e retry quando il provider va in timeout.

La chiave è che il codice non dovrebbe inventare stati propri. Legge il record Refund, esegue l'azione sul provider, poi scrive lo stato successivo e gli importi confermati così che il database resti il ledger di fiducia per tutti.

Prossimi passi: far sì che la scelta resti valida

Una buona decisione conta solo se resta vera tra sei mesi. L'obiettivo è rendere la scelta “dove deve vivere questa logica?” facile da vedere, facile da testare e difficile da aggirare accidentalmente.

Crea una mappa semplice della logica: un elenco breve delle regole chiave e la casa scelta per ciascuna. Mantienila breve e aggiornala quando una regola cambia. Includi il nome della regola, dove vive (database, workflow, codice personalizzato), perché (una frase), cosa legge e scrive e chi approva le modifiche.

Scrivi i confini come non negoziabili che proteggono il sistema quando le persone aggiungono funzionalità in seguito. Un formato utile è: “Il database garantisce X” e “I workflow applicano Y.” Per esempio, il database garantisce che un record refund non possa esistere senza un order, mentre il workflow impone che rimborsi sopra $500 richiedano approvazione manager.

Pianifica i test prima di cambiare qualsiasi cosa. Non serve un piano di test enorme, solo alcuni casi che rieseguirai ogni volta che la regola cambia:

• Happy path (input previsto, risultato atteso)
• Path di errore (dati mancanti, stato non valido, richiesta duplicata)
• Concorrenza (due persone che attivano la stessa azione contemporaneamente)
• Sicurezza (un utente che prova a saltare passi o chiamare un endpoint direttamente)

Definisci anche proprietà e regole di revisione. Decidi chi può editare stored procedure, chi può editare workflow e cosa richiede peer review. Qui molti sistemi restano sani o scivolano in “nessuno sa perché questo funziona.”

Se vuoi workflow drag-and-drop senza perdere una struttura backend reale, una piattaforma come AppMaster (appmaster.io) può essere un buon compromesso: modella i tuoi dati, esprimi il processo nel Business Process Editor e rigenera e distribuisci mentre i requisiti cambiano.

Scegli una regola ad alto impatto, mappala, aggiungi i confini e scrivi tre casi di test. Questa singola abitudine previene la maggior parte della dispersione della logica.