Livebase è una piattaforma di sviluppo low-code che offre potenti strumenti di modellazione, generazione di codice e lifecycle management per realizzare da zero applicazioni database gestionali in modo semplice, veloce e sicuro.
Il modello #
Sviluppare unâapplicazione con Livebase vuol dire realizzare un diagramma delle classi UML âspecialeâ, che prende il nome di modello. Esso è un diagramma concettuale che descrive la business logic dellâapplicazione su diversi livelli di astrazione, e che viene tradotto da Livebase non solo in un database, ma anche in tutta la logica applicativa coinvolta nelle letture e scritture dei dati rappresentati.
Un modello Livebase.
Nel modello, tutto ruota intorno ai dati: classi, attributi e relazioni definiscono la struttura del dato, mentre altri aspetti - come le form - definiscono la rappresentazione del dato, e altri ancora definiscono i permessi sul dato. PoichÊ sarebbe complicato rappresentare tutte queste informazioni contemporaneamente, il modello è dotato di diverse viste trasparenti, dette schema;
ogni schema consente al modellatore di concentrarsi su uno specifico aspetto dellâapplicazione, senza mai perdere di vista il diagramma delle classi.
Gli schema #
Gli schema piĂš importanti sono di tre tipi: Database Schema , Application Schema e Profile Schema .
La rappresentazione a âlivelli trasparentiâ, migliora la leggibilitĂ del modello, favorisce la separazione degli interessi e permette allo sviluppatore di navigare la gerarchia di informazioni con la sensazione di guardare fondamentalmente sempre lo stesso diagramma.
Il Database Schema è il cuore del modello. Istruisce Livebase su come generare il database relazionale, descrivendone la struttura concettuale in termini di classi, attributi, relazioni, vincoli dâintegritĂ e restrizioni dei domini dei dati. Il Database Schema è unico e da esso dipendono tutti gli altri livelli della gerarchia.
Gli Application Schema consentono di realizzare il partizionamento del database. Ciascuno di essi gestisce un sotto-dominio del modello, ovvero una selezione di classi, attributi e relazioni; nella vista applicativa che ne risulta, il resto del modello è completamente oscurato e inaccessibile, come se non esistesse. Ă inoltre possibile definire dei filtri per escludere certi oggetti dalla vista e restringere ulteriormente la porzione di database gestita. Gli Application Schema descrivono anche lâaspetto dellâinterfaccia utente e la rappresentazione dei dati.
I Profile Schema descrivono i grant (diritti) che gli utenti con quel profilo hanno nel sistema. Un profilo può essere abilitato o meno ad accedere a un insieme di viste applicative, e per ciascuna vista/Application schema è possibile specificare i diritti di lettura e modifica sugli oggetti resi accessibili dalla vista. Lo schema che consente di configurare questi diritti per la coppia profilo-vista applicativa è detta Permission Schema . Un profilo può inoltre essere abilitato per aspetti generali, come la configurazione del sistema o la gestione degli utenti.
Di default, nei nuovi modelli sono definiti un solo Application Schema (Application) con tutte le classi abilitate, e due Profile Schema: Member e Guest; non essendoci alcun partizionamento, gli utenti hanno accesso a tutto il modello con pieni diritti di lettura e scrittura.
Altri schema che non trattiamo nel tutorial sono i seguenti:
- Localization Schema : definisce le stringhe di localizzazione di tutti gli elementi del modello rispetto a una lingua supportata. Al momento le lingue supportate sono italiano e inglese .
- Report Schema : definisce un template per generare report di vario tipo (tabellare, a campi incrociati, etc.) sui dati del modello.
Il Designer #
Il Designer è lâambiente di modellazione di Livebase; lo useremo per realizzare classi e relazioni e navigare la gerarchia degli schema.
Il Designer Livebase.
In ogni momento, il Designer controlla ogni modifica che il modellatore effettua e valuta le loro ripercussioni nella gerarchia degli schema; è pertanto virtualmente impossibile disegnare modelli inconsistenti. Questo aspetto è molto importante soprattutto nella manutenzione di modelli pre-esistenti.
Il Designer è uno strumento incluso nella Dashboard, che vediamo a breve. Alla fine del corso avremo esplorato gran parte dei suoi strumenti e funzioni.
Lâapplicazione generata e la Cloudlet #
A partire dal modello, Livebase genera automaticamente tutto lo stack applicativo necessario al corretto funzionamento del sistema, senza richiedere ulteriore configurazione. Nel dettaglio, il risultato della modellazione è:
- un database relazionale (MariaDB), opportunamente normalizzato e ottimizzato;
- un engine applicativo (in linguaggio Java) corredato di servizi di lettura e scrittura sul database, autenticazione, gestione degli utenti e della concorrenza, viste applicative, logging, etc.;
- una API REST tradizionale e una API GraphQL mappate sugli elementi del modello;
- una libreria di interfacce di sviluppo Java mappate sugli elementi del modello per realizzare Plugin.
Tutto questo stack - database incluso - risiede in un server virtuale autonomo che prende il nome di Cloudlet. Una Cloudlet è un sistema multi-utente con un indirizzo URL, che consente di accedere alle sue interfacce; la maggior parte di queste risorse è protetto e richiede autenticazione.
API e Plugin #
Le API generate dal sistema sono due: REST e GraphQL; entrambe vengono mappate sulle risorse dichiarate nel modello, e consentono (previa autenticazione) di interrogare lâapplicazione generata per leggere e scrivere dati, con le stesse politiche modellate nei Profile Schema. In particolare, la API GraphQL offre un linguaggio di interrogazione fortemente tipato per soddisfare query complesse in modo flessibile.
Le API della Cloudlet consentono lâaccesso allâapplicazione tramite lo schema GraphQL generato. Questo consente di interfacciare la Cloudlet con altri sistemi esterni allâorganizzazione, e rendono possibile realizzare client web personalizzati da includere tra le risorse dellâapplicazione Livebase.
I Plugin sono invece estensioni custom della logica applicativa. Gli sviluppatori possono usare le librerie generate per scrivere Plugin e agganciarli allâengine applicativo; queste estensioni vengono richiamate durante lâesecuzione di alcune operazioni note (come durante il salvataggio di un oggetto), e consentono di eseguire codice arbitrario sfruttando il contesto dâesecuzione dellâapplicazione (come oggetti in memoria, connessioni aperte al database) o altri servizi offerti dal framework dellâengine applicativo.
La Dashboard #
La Dashboard è lâambiente di amministrazione di modelli e Cloudlet. Da qui possiamo aprire il Designer per visualizzare, creare o modificare modelli; possiamo inoltre gestire tutto il ciclo di vita delle Cloudlet: creazione, avvio/arresto e demolizione.
La Dashboard Livebase.
Nella Dashboard, il proprietario di una Cloudlet può:
- gestire i membri, crearne di nuovi e assegnare loro profili utente per accedere allâapplicazione generata;
- gestire le risorse da assegnare alle sue Cloudlet (dimensione del database o del file storage, larghezza di banda, etc.) dal resource pool disponibile per il suo piano;
- gestire il database e il modello corrente.
Di default, Livebase effettua automaticamente il deploy delle nuove Cloudlet sul nostro hosting cloud; Cloudlet dispiegate in questo modo hanno giĂ a disposizione un URL pubblico, nel formato <ServerNumber>.fhoster.com/<AccountName>/<CloudletName>, dove <AccountName> è lo username dellâaccount proprietario della Cloudlet.
Flusso di lavoro Livebase #
Per creare da zero unâapplicazione Livebase è sufficiente:
- creare un modello in libreria;
- creare una Cloudlet;
- trascinare il modello sulla Cloudlet per installarlo;
- avviare la Cloudlet.
Creazione di unâapplicazione Livebase.
Livebase genera tutto lo stack applicativo ogni volta la Cloudlet viene avviata con un nuovo modello. Se non è presente un database, anchâesso viene creato da zero. Una volta generato il codice al primo avvio, la Cloudlet può essere arrestata e riavviata piĂš rapidamente.
Ciclo di sviluppo #
In qualunque momento, una Cloudlet in esecuzione può essere arrestata e il suo engine può essere sostituito con un altro modello o aggiornato modificandolo nel Designer. Questa operazione è detta manutenzione evolutiva e rende possibile apportare modifiche a unâapplicazione Livebase esistente minimizzando il rischio di perdere i dati memorizzati nel pre-esistente database.
Lo sviluppo di applicazioni Livebase è quindi un ciclo composto di tre fasi: modellazione, allineamento e rigenerazione:
Ciclo di sviluppo di unâapplicazione Livebase.
Quando un modello/engine installato su una Cloudlet viene aperto e modificato nel Designer, Livebase controlla le modifiche effettuate dallâutente tenendo conto della struttura corrente del database e dei dati memorizzati in esso.
Quando lâutente salva le modifiche, Livebase elabora un piano dâintervento per aggiornare database e applicazione individuando e catalogando eventuali disallineamenti con i dati esistenti e la struttura del database:
- se si tratta di cambiamenti di basso impatto (low issue), è possibile riavviare la Cloudlet senza problemi;
- in presenza di disallineamenti che comporterebbero perdite di informazioni (medium issue), Livebase chiede allâutente di rivedere le modifiche e dare conferma esplicita prima di procedere;
- nel caso di problemi ancora piĂš gravi (high issue) che non sono risolvibili automaticamente e che renderebbero i dati pre-esistenti inconsistenti, Livebase impedisce di avviare la Cloudlet e obbliga lâutente a risolvere manualmente gli errori sul Designer.
Concluso lâallineamento col database, è possibile riavviare la Cloudlet. A questo punto, tutte le parti dellâapplicazione coinvolte dalle modifiche vengono rigenerate.
Durante il corso effettueremo numerosi interventi di manutenzione evolutiva e affronteremo tutti i diversi scenari che abbiamo elencato.
Nella prossima lezione⌠#
Descriviamo i requisiti del sistema gestionale che guiderĂ la modellazione: Scenario di esempio.