grafico spiegata in precedenza, quindi sar`a possibile specificare le caratteristiche del grafico e salvarlo nella dashboard;
• Edit Chart permette di modificare il grafico selezionato all’interno della dash-board. Anche in questo caso la pagina di creazione di un grafico viene visualizzata in un dialog ma, a differenza della situazione precedente, si presenta con tutti i campi gi`a specificati. Questa operazione `e disponibile solo quando `e presente un unico grafico selezionato, infatti se due o pi`u grafici sono selezionati, il bottone Edit Chart non `e pi`u disponibile;
• Delete Chart permette l’eliminazione di un grafico dalla dashboard. A differenza della modifica, l’operazione di eliminazione `e disponibile anche con pi`u grafici selezionati;
• Save permette di salvare il nuovo layout della dashboard. Una volta salvato l’ap-plicazione indirizza nuovamente l’utente verso la visualizzazione della dashboard non in modalit`a editing.
Figura 5.11: Modifica di una dashboard
verranno presentate tre libreria che, per ragioni differenti, sono state fondamentali nello sviluppo del software.
La prima libreria `e quella di Axios, un client HTTP per Node.js basato sul concetto della promessa. Una promessa `e un oggetto che rappresenta l’eventuale completamento o fallimento di una richiesta asincrona, quindi al suo interno ci sar`a il risultato della richiesta oppure un errore che descrive il motivo per il quale non `e possibile ottenere una risposta. Il motivo principale per il quale si `e deciso di utilizzare Axios all’interno dell’applicazione `e che d`a la possibilit`a di gestire l’autenticazione del client tramite un file di configurazione. Entrando nel dettaglio della questione, ogni volta che il client effettua una richiesta al server `e necessario trasportare delle informazioni per dimostrare di essere un client legittimo. Per evitare di inserire queste informazioni in ogni richiesta,
`e possibile specificarle in un file ed Axios inserisce automaticamente queste informazioni nell’header di ogni richiesta effettuata.
Un’altra libreria `e axios-hooks, che si basa su Axios ma aggiunge delle funzionalit`a molto utili. Una di queste `e la possibilit`a di gestire in automatico l’attesa per la ricezione di una risposta. In alcuni casi `e utile visualizzare all’utente un loader, soprattutto in quei casi dove `e necessario prendere dal server una grande quantit`a di dati. Per questo motivo, axios-hooks mette a disposizione una funzione hook simile a quella rappresentata di seguito.
[ { data , l o a d i n g , e r r o r , r e s p o n s e } , e x e c u t e , manualCancel ] = u s e A x i o s ( u r l | c o n f i g , o p t i o n s ) ;
Come possiamo notare, la funzione useAxios accetta due parametri: il primo pu`o essere un’url, cio`e l’endpoint del server che deve essere contattato, oppure un oggetto che ha lo scopo di definire diverse configurazioni tra cui l’url, il metodo (get, post, delete, ecc), l’header, il body ed altre ancora. Il secondo parametro, invece, `e un altro oggetto in cui possono essere settate alcune opzioni, come ad esempio manual, cio`e se la richiesta deve essere eseguita alla creazione del componente oppure se deve essere invocata manualmente, useCache, cio`e se la cache deve essere attivata o meno, ssr, per attivare o disattivare SSR ed autoCancel per attivare o disattivare la cancellazione automatica delle richieste pending.
Inoltre, la funzione useAxios ritorna un array composto da diversi parametri, ve-diamoli insieme:
• data contiene il risultato della richiesta;
• loading vale True se la richiesta `e in corso, altrimenti `e False;
• error contiene l’eventuale errore della richiesta;
• response contiene l’intero oggetto della risposta;
• execute permette di eseguire la richiesta manualmente. Infatti, nelle options `e possibile specificare se la richiesta deve essere fatta al rendering della pagina o in un secondo momento, in quest’ultimo caso `e possibile utilizzare la funzione execute;
• manualCancel permette di cancellare manualmente una richiesta in corso.
Avendo questi parametri a disposizione, `e facile utilizzare il valore di loading per capire se la richiesta `e terminata o meno, ed eventualmente fare il rendering di un loader o del risultato della richiesta.
La seconda libreria utilizzata `e quella di Vega - Lite, una versione pi`u ad alto livello di Vega, un linguaggio dichiarativo per creare, salvare e condividere grafici interattivi.
Con Vega, la struttura e il comportamento interattivo del grafico vengono descritti in un formato JSON, dal quale viene generata la visualizzazione. Tutti i grafici all’inter-no dell’applicazione soall’inter-no gestiti con la libreria react-vega, scelta soprattutto per una grande flessibilit`a che permette di descrivere a propria scelta tutte le caratteristiche che contraddistinguono un grafico, come ad esempio assi, scale, trasformazioni, legende, ecc.
Le specifiche di Vega-Lite descrivono un grafico partendo dai dati disponibili per arrivare alle propriet`a dei segni grafici, come ad esempio punti o barre. Il compilatore Vega-Lite produce in automatico tutti i componenti necessari per la visualizzazione come assi, legende e scale. Il vantaggio di Vega-Lite rispetto a Vega `e che, essendo pi`u ad alto livello, permette di essere pi`u coincisi per una creazione rapida del grafico.
Una caratteristica importante di Vega-Lite `e la possibilit`a di analisi dei dati, infatti supporta sia la trasformazione dei dati che le trasformazioni visive. Infine, l’ultima funzionalit`a altamente sfruttata all’interno del lavoro di tesi `e la possibilit`a di creare un grafico multi-livello, cio`e la capacit`a di integrare all’interno di un unico grafico pi`u dati anche con visualizzazioni differenti.
React-vega mette a disposizione un tag JSX per la rappresentazione del grafico, al quale `e necessario passare la descrizione in formato JSON del grafico, i dati da visualizzare ed altri attributi che possono essere utilizzati per specificare lo stile del grafico, come ad esempio altezza e larghezza.
L’ultima libreria che vorrei introdurre all’interno di questo documento `e Leaflet, necessaria per lo sviluppo di mappe geografiche interattive. Infatti, questa libreria `e stata utilizzata per introdurre la possibilit`a di selezionare i device di interesse tramite una mappa, come spiegato in precedenza. Nonostante le molte alternative presenti per la gestione di una mappa, la scelta `e ricaduta su Leaflet poich´e open-source e soprattutto facile da utilizzare. Inoltre, mette a disposizione tutte le caratteristiche necessarie nel nostro caso, come la possibilit`a di visualizzare dei luoghi di interesse (device) e di disegnare linee ed aree.
Le caratteristiche che hanno reso Leaflet una delle migliori alternative per la visua-lizzazione di una mappa sono:
• Possibilit`a di aggiungere pi`u livelli per la raffigurazione di marker o aree, carat-teristica molto utile nel caso d’uso del progetto in questione;
• Funzioni di personalizzazione con le quali `e possibile modificare tutti i componenti della mappa, ad esempio modificando i colori dei Marker o delle aree disegnate;
• Ottimo supporto da parte dei browser;
• Caratteristiche di interazione come zoom, eventi, trascinamento dei marker, ecc;
• Performance ottimali;
• Caratteristiche visuali;
• Possibilit`a di aggiungere controlli sulla mappa, ad esempio bottoni o form;
• La sua estrema leggerezza non avendo dipendenze esterne.
Leaflet React mette a disposizione diversi strumenti per rendere il suo utilizzo sem-plice e veloce. Primo su tutti `e il componente MapContainer che accetta diversi attri-buti, come il centro utilizzato per rappresentare la mappa o lo zoom iniziale. Inoltre,
altri componenti importanti sono il Marker, Polygon, che serve per raffigurare un po-ligono all’interno della mappa e Tooltip, necessario per la visualizzazione di tooltip personalizzati.
Capitolo 6
Back-end
Lo scopo principale del back-end `e quello di preservare lo stato dell’applicazione e di implementare la logica necessaria per svolgere tutte le funzionalit`a richieste. Di solito vengono identificati due componenti chiave all’interno del back-end: il server, che comunica con il front-end esponendo delle API raggiungibili dal client ed implementa la logica applicativa e il database, dove vengono salvate tutte le risorse dell’applicazione.
Questi due componenti interagiscono continuamente per fornire all’utente le risorse di cui ha bisogno e per aggiornare lo stato dell’applicazione.
Entrando nel dettaglio del presente lavoro di tesi, si `e deciso di non includere le nuove funzionalit`a all’interno del back-end di XTAP ma di creare un nuovo server e di utilizzare un database diverso da MongoDB. Lo scopo `e quello di fornire ai sensori un’API per inviare verso il server tutti i dati raccolti, inoltre `e necessario recuperare i dati degli eventi EPCIS da XTAP utilizzando i Connectors di Kafka. Questi dati, sia quelli raw che quelli proveniente dagli eventi, devono essere salvati all’interno del database ed `e necessario esporre delle API per permette al front-end di richiedere tutte le risorse di cui ha bisogno l’utente.
Come gi`a accennato all’interno di questo documento, per l’implementazione del back-end si `e deciso di utilizzare FastAPI, un web framework moderno e veloce che permette di creare delle API con Python. Questa tecnologia si adatta perfettamente a quelle che sono le esigenze del progetto, cio`e creare un server che possa servire ve-locemente tutte le richieste che arrivano dai client per evitare situazioni che possano portare ad un rallentamento dell’applicazione. Nonostante la scelta della tecnologia da utilizzare per l’implementazione del server sia stata abbastanza semplice, `e stato necessario effettuare delle analisi per individuare la migliore soluzione per il database.
Analizziamo gli studi effettuati nel paragrafo successivo.