Flussi guidati da schema con configurazione come codice

Il problema

I flussi per molti mercati significavano codice duplicato e un ticket di ingegneria ogni volta che prodotto o conformità volevano cambiare una regola regionale.

L’approccio

• Generare i moduli dallo schema. L’interfaccia legge la configurazione JSON o YAML tramite jsonform: lo schema genera i campi e le regole di validazione. Le azioni personalizzate, come l’avvio di un bridge nativo, restano nel codice.
• Un passaggio, esiti diversi. La configurazione decide cosa fa un passaggio per ogni mercato e piattaforma. Dove una funzione nativa è supportata, il passaggio mostra una guida e un pulsante di scansione; altrimenti mostra i normali campi del modulo e un pulsante Continua. Il prodotto lo cambia nella configurazione, non nel codice.
• Configurazione come codice. Le modifiche vengono inviate tramite Git. Ogni modifica apre una pull request automatica ed esegue la CI con una validazione rigorosa dello schema, supportata dai tipi TypeScript, così una configurazione malformata fallisce prima della produzione.

Due decisioni che meritano una spiegazione

jsonform per il rendering, codice per le azioni. Un’interfaccia interamente guidata dal server che esegue logica arbitraria inviata da esso invita rischi di esecuzione di codice remoto e problemi di prestazioni. Un rendering guidato dai dati con azioni legate a handler precompilati mantiene la flessibilità senza quell’esposizione.

Git invece di un modulo di amministrazione. Modifiche facili senza governance rompono i flussi di produzione. Pull request, controlli dei tipi e CI rendono ogni modifica attribuibile, rivista e facile da annullare.

Il risultato

I rilasci di configurazione non dipendono più dai deploy del frontend, quindi gli aggiornamenti multi-mercato sono passati da settimane a ore e la duplicazione del codice regionale ha smesso di crescere.