Le promesse del low-code: si sviluppa tutto in poco tempo
È entusiasmante l’idea di una piattaforma low-code che permetta di sviluppare il software senza dover conoscere i linguaggi di programmazione. Definire con strumenti visuali i dati, la logica con cui questi devono essere trattati, e anche l’interfaccia utente, è una realtà concreta proposta da alcune piattaforme low-code.
Queste piattaforme le possiamo considerare come piattaforme general-purpose che, ad un primo utilizzo, ci semplificano tutti gli aspetti dello sviluppo applicativo. È un approccio utile per applicazioni dove, la velocità dello sviluppo e la produzione dei risultati richiesti, è il requisito fondamentale. Applicazioni rivolte ad una utenza identificata e non destinata a crescere, dove i processi da automatizzare sono ben definiti e non richiedono molte modifiche nel tempo.
I limiti di questo approccio generalista vengono alla luce quando ci si confronta con la necessità di scalabilità o con logiche che vengono modificate in continuazione.
Che significano queste considerazioni, che il low-code non è adatto per applicazioni di tipo enterprise? No, significa che, anche usando piattaforme low-code, è importante avere la conoscenza per disegnare un’architettura applicativa. Inoltre le piattaforme devono essere concepite per aiutare questo disegno.
L’alternativa è quella di scoprire i vincoli della piattaforma scelta, quando questi diventano dei limiti insormontabili alla crescita dell’applicazione già in produzione. Che si può fare in questi casi? O ci si rivolge al fornitore della piattaforma per vedere se, e a che costi, ci permette di superare questi vincoli, oppure si deve rifare tutto su una piattforma che non ponga tali limiti (aiuto! è una migrazione di un’applicazione in produzione….).
Il low-code applicato in modo specializzato
Per applicazioni che hanno ambizioni di tipo enterprise è possibile abbracciare il low code utilizzando, ad esempio, delle piattaforme specializzate nella realizzazione di front-end insieme a piattaforme specializzate nella realizzazione di back-end.
Questo tipo di piattaforme le possiamo considerare di tipo fit-for-purpose. Ossia piattaforme che, essendo focalizzate su un aspetto dello svulippo applicativo, garantiscono meglio anche gli attuali (o futuri) requisiti non funzionali della nostra applicazione.
È chiaro che in questo caso ci sono altre valutazioni da fare. Dobbiamo rispondere queste domande:
- è possibile far cooperare piattaforme differenti?
- quanto è difficile, o meglio, quanto codice si deve scrivere, per integrarle?
L'obiettivo che ci poniamo: facciamo lavorare insieme due piattaforme
In questo articolo, senza altri preamboli, vogliamo mostrare in pratica e in modo semplice come ciò è possibile. Useremo due piattaforme.
Livebase che è una piattaforma low-code, per i back-end, e si propone come
una piattaforma per disegnare, generare, mettere in produzione e mantenere componenti di backend, chiamati Cloudlet, senza dover scrivere dcodice.
Smetti di lottare con le librerie dell'interfaccia utente, integrare fra loro le origini dei dati e capire i meccanismi di accesso.
Retool permette di utilizzare una molteplicità di back-end, DBMS, API, ecc. A noi interessa perché permette l’integrazione con GraphQL.
L'obiettivo che non abbiamo: la recensione delle piattaforme
Non vi aspettate una doppia recensione, ci focalizziamo solo su come integrarle per mostrare quanto è semplice.
Se volete saperne di più o andate sui loro siti, oppure fatecelo sapere compilando il semplice sondaggio sul low-code dal bottone in basso a destra.
Proprio per questo lo scenario che esploriamo non mostra tutte le potenialità di ciascuna piattaforma, ma si limita ad un caso semplicissimo per focalizzarci sulla facilità di integrazione.
Infatti, lo scenario preso ad esempio rasenta l’imbarazzante. Su Livetool abbiamo UNA tabella e vogliamo che questa venga visualizzata da Retool.
Livetool - cosa abbiamo preparato
Nella parte back-end , aprendo l’applicazione Livebase Dashboard, abbiamo preparato una Cloudlet, che rappresenta il nostro back-end, dal nome RetoolCloudlet.
Al centro si vedono i tre elementi necessari:
- i membri – qui ne abbiamo definito solo uno che sarà l’utente con cui Retool accede .
- il modello – nel nostro è definita una sola tabella dal nome Persone
- gli oggetti – sono le righe della nostra tabella
In basso, nella riga di stato, si vede che la cloudlet non è attiva e, sulla destra, il bottone per avviarla.
Prima di di farla partire clicchiamo il simbolo 
per configurare l’URL con cui accedere con le query GraphQL. Ci verrà mostrata la finestra API & Public URLs dove dobbiamo assicurarci di aver impostato ad ON l’interruttore in basso a sinistra:
A questo punto possiamo avviare la cloudlet. Tornando alla finestra precedente la vedremo cambiata:
In basso ora è mostrata l’URL con cui accedere alla cloudlet.
Tutto quello che ci server oltre a questa URL è l’utenza e la password definite nel membro della cloudlet.
Entriamo in Retool
Dopo il logon su Retool ci viene mostrato questo menù:
Le scelte che ci interessano ora sono:
- Apps – dove definiamo la nostra applicazione
- Resources – dove configuriamo l’accesso ai back-end che gestiscono i dati
- Query Library – dove costruiamo le query sulle risorse che verranno utilizzate dalle Apps.
Definiamo Livebase, come risorsa GraphQL, su Retool
Andiamo nella scelta Resources e clicchiamo il bottone Create New e scegliamo Resouces dal menù a tendina.
Si vede subito che Retool ha nel suo DNA la possibilità di connettersi ad una molteplicità di risorse dati. Da quello che ci viene proposto, ovviamente, andiamo a scegliere GraphQL.
Il pannello di configurazione della connessione è il primo step determinante all’integrazione delle due piattaforme. Non facciamoci fuorviare dai campi richiesti, sono solo quelli necessari a far creare un oggetto di tipo connessione a Retool. Non sono tutti quelli che servono per far funzionare la connessione. I primi due campi che vanno compilati sono:
- Name – è il nome della connessione
noi usiamo Livebase Demo - Folder – è richiesto ed è utile per organizzare le varie connessioni usate dall’applicazione. Per lo scopo di questo articolo possiamo lasciare Unassigned.
- Base URL – qui si deve inserire l’URL che ci siamo annotati dalla finestra API & Public URLs di Livebase;
- Authentication – scegliamo Basic Auth come metodo di autenticazione;
- Username/Password – qui si inserisce utenze e password dell’utente che abbiamo definito come membro della Cloudlet di Livebase;
- Test connection – A questo putno possiamo provare la connessione premendo il tasto in basso;
- Test connection successful – E’ il messaggio che appare se sutto è configurto bene.
NON DIMENTICHIAMO DI SALVARE IL TUTTO PREMENDO IL TASTO Create resource !!
Avremo la certezza quando ci verrà mostrato questo popup
Chiudiamo il popup. Per ora non passiamo all’App, ma vedimo come fare le query.
La prima query GraphQL da Retool
I dati di Livetool
In Livetool abbiamo definito una tabella (ossia una classe) dal nome Persona. Attivata la Cloudelet Livebase mette a disposizione dei servizi predefiniti, per ogni classe, per effettuare query GraphQL. Noi useremo il servizio getPage, per la classe Persona, che restituisce un insieme di record. Il servizio ha una naming convention di questo tipo:
<ClassName>___getPage
Dove tra iol nome della classe e getPage ci sono 3 caratteri _ (underscore). Nel nostro caso useremo il servizio
Persona___getPage
Per ottenere i dati usiamo la seguente query:
query ALL_CPERSONA {
Persona___getPage {
items {
Nominativo
Nome
Cognome
}
}
}
Torniamo su Retool e, dal menu in alto, scegliamo Query Library. Dalla finetra che ci viene mostrata:
- Clicchiamo sul bottone New – verrà aggiunta una nuova query
- Clicchiamo sul titolo – inseriemo il nome della query. Nel nostro caso Persone_query
- Scegliamo la risors su cui verrà effettuata la query – Noi andremo a scegliere la risorsa Livebase demo creata precedentemente.
A questo punto inseriamo la nostra query nel campo sottostante e, premendo il tasto play alla destra del tasto save, andiamo ad eseguirla.
Se tutto è corretto, sotto il pannello della query appare il risultato. Possiamo salvare e passare alla nostra app.
Una funzione utile di Retool, che ci mostra l’avvenuta integrazione, è il campo Explorer, sulla destra sotto i tasti Share, Save e Play. Digitando il nome della classe Persona appaiono i servizi e le mutation che si possono usare da Retool.
Un’ultima cosa importante è quello di condividere con le App la query appena creata. Per questo, dopo averla salvata, premiamo il bottone Share.
Usiamo i dati nell'interfaccia utente
Creiamo l'app di test
Dal menu in alto selezioniamo la scelta Apps. Premendo il bottone Create New scegliamo App.
Scriviamo il nome dell’app Livebase_Retool nel popup che ci viene presentato. A questo punto Retool ci mette in Edit dell’applicazione mostrando un pannello con già una tabella che ha dei dati di esempio.
Per vedere esattamente quali sono i primi passi, selezioniamo la tabella e cancelliamola, premendo il tasto destro e scegliendo delete dal menu che appare. A questo punto dovremmo avere il nostro workspace vuoto, inizializzato con una tabella contenente dei dato di esempio.
Le tre parti che ci interessano sono:
- Il canva – dove è visualizzata la tabella-esempio.
- I dati – è il campo che collega la tabella ai dati ottenuti. All’inizio contiene, in formato Json, esattamente i dati da visualizzare.
- Risorse e query – le informazioni sulle risorse dati utilizzate e le query.
Concentrandoci in quest’ultima parte andiamo nel campo Resource e, dal menù scegliamo di collegarci attraverso la Query Library.
Il pannello cambia un po’ e ci permette di selezionare, dal campo Select query, la query definita in precedenza dal nome Persone_query. A questo punto, con il bottone Run possiamo vedere i dati forniti dalla query.
Sotto, appare il messaggio Query ran succesfully e ci vengono mostrati i dati ricevuti dalla query.
Ma la tabella riporta ancora i dati di esempio, come mai?
Questo perché ancora non è collegata la sorgente dei dati della tabella con il risultato fornito dalla query. Selezioniamo la tabella e vedremo, all’interno del tab Inspect, che il campo Data contiene ancora l’elenco Json. Selezioniamolo tutto e cancelliamolo. Al suo posto si dovrà
Questo perché ancora non è collegata la sorgente dei dati della tabella con il risultato fornito dalla query. Selezioniamo la tabella e vedremo, all’interno del tab Inspect, che il campo Data contiene ancora l’elenco Json. Selezioniamolo tutto e cancelliamolo.
Iniziamo a scrivere {{ e ci verranno proposte una serire di possibilità. Scegliamo query1.data e mettiamo il punto. Retool continua a suggerirci le opzioni valide. Continuiamo fino a scrivere
{{query1.data.Persona___getPage.items}}
Ora premendo il bottone in alto a destra 
otteniamo il risultato finale:
A questo punto si può sviluppare la nostra app, certi di avere dietro un solido backend-
Conclusioni
L’integrazione può sembrare macchinosa leggendo l’articolo. Ma il suo flusso è logico.
Trovo questa abbinata molto potente perché una volta definita la risorsa a Retool avremo tutte le informazioni della struttura del backend a disposizione.
La possibilità fornita da Livebase di avere più versioni dei modelli delle classi, aiuta uno sviluppo incrementale. È possibile iniziare a realizzare il front-end appena le prime classi sono definite.
