Premesse
Ho aperto questa serie parlando di frammentazione dei dati e di architettura no-code come principio, non come funzionalità isolata. È arrivato il momento di scendere nel concreto e guardare a cosa succede, tecnicamente, quando quel principio viene applicato al livello che l’utente incontra ogni giorno: la tabella dati, la griglia in cui si cercano, si filtrano e si modificano le informazioni. È lì che la promessa del no-code si verifica davvero, perché è lo strumento che un facility manager, un building manager o un tecnico di manutenzione apre decine di volte al giorno.
La domanda tecnica di fondo è questa: quando un’organizzazione ha bisogno di gestire un nuovo tipo di entità – un nuovo tipo di contratto, una nuova categoria di verifica, un nuovo censimento specifico del proprio settore – cosa succede davvero dietro le quinte? Si scrive una nuova interfaccia da zero, o si compila una configurazione che un motore generico interpreta a runtime?
Come fa un motore applicativo a generare un’interfaccia tabellare completa senza codice scritto per quella specifica tabella?
Il meccanismo si basa su un livello di metadati che descrive le tabelle applicative: per ogni tabella gestita, righe di configurazione specificano quali colonne mostrare, con quale tipo di dato, con quale formato di visualizzazione, con quali permessi di lettura o scrittura per ciascun gruppo di utenti.
Un motore generico legge questa configurazione a runtime e costruisce dinamicamente l’interfaccia – intestazioni, filtri, editor delle celle – senza che una sola riga di codice frontend sia stata scritta appositamente per quella tabella. La stessa componente che visualizza l’anagrafica degli asset visualizza, con la stessa logica, un nuovo censimento aggiunto ieri da un amministratore, perché entrambe attingono allo stesso motore di interpretazione dei metadati.
Questo richiede un disaccoppiamento netto tra il motore di rendering, scritto una volta e mantenuto con cura ingegneristica, e la configurazione, che può essere modificata in autonomia da chi amministra il sistema senza toccare il codice applicativo. È la stessa distinzione che in altri ambiti informatici separa un interprete da uno script: il motore resta stabile, cambia solo cosa gli si chiede di interpretare.
Come vengono generate le celle per tipi di dato diversi?
Un aspetto spesso sottovalutato è quanto sia ricca la varietà di modi in cui un valore deve poter essere presentato: un campo di stato come badge colorato, una percentuale come barra di avanzamento, un’immagine come anteprima cliccabile, un valore numerico come indicatore a stelle, un colore come selettore editabile direttamente nella cella.
Un motore maturo implementa questi renderer come funzioni pure, ciascuna dedicata a un formato dichiarato nei metadati, disaccoppiate dalla logica di caricamento dei dati: la stessa colonna può cambiare rappresentazione visiva semplicemente cambiando un parametro di configurazione, senza toccare il motore che recupera e aggiorna i dati.
Un caso interessante sono i codici QR e i codici a barre: generarli come immagine richiederebbe una chiamata a un servizio esterno o un’elaborazione lato server per ogni cella visualizzata, con un costo di rete e di calcolo che non regge su una griglia con centinaia di righe visibili. Generarli invece come vettoriale SVG calcolato direttamente nel browser, con il risultato memorizzato in cache per evitare ricalcoli durante lo scorrimento, è una scelta tecnica che mantiene la griglia fluida anche quando quasi ogni riga porta con sé un codice identificativo scansionabile.
Perché la virtualizzazione delle righe è un requisito tecnico, non un dettaglio di ottimizzazione secondaria?
Perché senza di essa, una tabella con migliaia di record – non un caso raro in un patrimonio immobiliare di dimensioni medio-grandi, dove gli asset censiti possono facilmente superare le decine di migliaia – costringerebbe il browser a costruire altrettanti elementi nel DOM, con un degrado delle prestazioni che rende l’interfaccia inutilizzabile ben prima di arrivare in fondo all’elenco.
Questo tipo di ottimizzazione, se non prevista fin dal progetto del motore, è difficilissima da aggiungere in un secondo momento senza riscrivere l’intero componente: è un altro esempio di come una scelta architetturale fatta all’inizio determini, anni dopo, se un sistema regge davvero alla scala reale di un’organizzazione o resta valido solo nelle demo con pochi dati di prova.
Come si gestiscono le relazioni tra tabelle senza dover scrivere query dedicate per ogni caso?
Un requisito ricorrente nella gestione FM è la navigazione annidata: aprire un edificio e vedere i suoi piani, aprire un piano e vedere i suoi locali, aprire un locale e vedere i suoi asset. Un motore che vuole restare generico deve saper inferire automaticamente queste relazioni a partire dai vincoli di chiave esterna dichiarati nei metadati – incluso il caso, tutt’altro che raro in un modello dati FM con chiavi leggibili invece di interi surrogati, delle chiavi esterne composte da più colonne – e costruire di conseguenza le query di drill-down senza che ogni nuova relazione richieda una riga di codice dedicata.
Un’ulteriore raffinatezza tecnica utile è il prefetch predittivo: caricare in anticipo, in background, i dati del livello di annidamento successivo più probabile, così che l’apertura di una sotto-griglia appaia istantanea invece di mostrare un caricamento visibile ogni volta.
Che tipo di export deve generare un motore di questo tipo, e perché farlo lato client conta?
Esportare i dati in PDF, Excel, formato tabulare semplice o come istruzioni SQL pronte per un altro database sono esigenze ricorrenti e diverse tra loro: un report da presentare, un foglio da elaborare ulteriormente, un dato da importare altrove.
Generare questi export interamente nel browser, con librerie caricate una sola volta e mantenute localmente invece di dipendere da un servizio esterno richiamato ogni volta, riduce il carico sul server – che non deve elaborare un export per ogni richiesta – e riduce la dipendenza da infrastruttura di terze parti raggiungibile solo con una connessione internet stabile, un dettaglio non irrilevante per chi lavora da un cantiere con connettività incerta.
Quale impatto ha, concretamente, questo approccio sulle quattro figure che vivono il sistema ogni giorno?
Per il proprietario, significa che il costo di adattare il sistema a una nuova esigenza gestionale resta contenuto e prevedibile nel tempo, invece di crescere ogni volta che il patrimonio o l’organizzazione cambiano. Per il building manager, significa poter proporre lui stesso l’aggiunta di un nuovo censimento o di una nuova vista, senza dover convincere qualcun altro a stanziare un budget di sviluppo.
Per il manutentore interno, significa un’interfaccia coerente e familiare qualunque sia l’entità che sta consultando, riducendo la curva di apprendimento ogni volta che si aggiunge qualcosa di nuovo. Per la ditta esterna o il global service, significa poter adattare lo stesso strumento a convenzioni diverse da cliente a cliente attraverso la sola configurazione, senza dover mantenere versioni software separate per ciascuno.
Conclusioni
Una griglia dati generica, capace di trasformare qualunque tabella in un’interfaccia interattiva completa – filtri, permessi, renderer ricchi, relazioni annidate, export – a partire da sola configurazione, è la manifestazione concreta del principio no-code di cui ho parlato in un articolo precedente: non una funzionalità isolata, ma l’infrastruttura su cui poggia la capacità dell’intero sistema di adattarsi senza sviluppo dedicato.
Nel prossimo articolo vedremo come questa stessa griglia possa parlare la lingua dell’utente attraverso filtri visuali, viste personali e azioni configurabili, senza richiedere competenze tecniche a chi la usa ogni giorno.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui