Backend Service

Le tecnologie utilizzate per il Backend Service sono principalmente legate alla gestione dei dati e aggiornamento del database.

Di seguito sono elencate le principali.

Node.js [16]

Node.js `e una delle tecnologie pi`u rivoluzionarie che si sono affermate negli ultimi 10 anni per lo sviluppo di applicativi back-end. Esso ha come obiettivo quello di eseguire codice JavaScript fuori da browser, e questo `e un grande vantaggio in quanto milioni di sviluppatori front-end possono appor- tare modifiche a codice back-end senza aver bisogno di imparare un nuovo linguaggio. Node.js `e basato su V8 [98], JavaScript engine open source svi- luppato da Google e utilizzato in Chrome, che lo rende molto performante. Tra le peculiarit`a spicca il fatto che un’applicazione Node.js `e composta da un singolo thread, al contario di molti altri runtime dove ogni richiesta ge- nera un nuovo thread. Questo ha dei vantaggi consistenti in quanto Node.js pu`o gestire migliaia di richieste concorrenti con un singolo server senza do- versi preoccupare di gestire la concorrenza dei thread e con ci`o risparmiando numerosi bug.

PostgreSQL [99]

PostgreSQL, o pi`u seplicemente Postgres, `e un database relazionale open source che `e da molti anni uno strumento estremamente popolare nella com- munity di sviluppatori back-end. Esso, essendo un RDBMS, garantisce le propriet`a ACID (Atomicity, Consistency, Isolation, Durability) e ha suppor- to completo per funzionalit`a come join, foreign keys e tante altre. Offre inoltre supporto per una grandissima quantit`a di tipi, tra cui array, oggetti in linguaggio JSON, tipi geometrici e tipi compositi. Un’altra caratteristica per cui PostgreSQL `e in cima alle scelte per quanto riguarda i database `e il fatto che un grandissimo numero di provider cloud lo supportano e perci`o

2.3 Principali tecnologie utilizzate 37

non si `e legati ad uno in particolare. Molte soluzioni di basi di dati che sono nate ultimamente, infatti, come Amazon DynamoDB [100] o Firebase Fire- store [101], offrono numerose funzionalit`a interessanti ma non permettono il trasferimento su altri provider cloud o su soluzioni self-hosted.

TypeOrm [102]

Dopo aver citato PostgreSQL, `e doveroso citare le modalit`a con cui si ac- cede ai dati contenuti in esso. Un ORM (“Object Relational Mapper”) [103] `

e indubbiamente una parte fondamentale di ogni applicativo back-end per garantire un accesso ai dati semplificato e una maggiore sicurezza. In breve, l’obiettivo di un ORM `e quello di mappare entit`a presenti nel database ad oggetti in un qualsiasi linguaggio di programmazione object-oriented. Nel panorama JavaScript uno degli ORM pi`u utilizzati e apprezzati dalla com- munity `e TypeOrm. Questa libreria `e estremamente versatile, dato che pu`o essere eseguita da qualsiasi browser, Node.js, React Native e praticamente ogni piattaforma che supporti il runtime JavaScript. Inoltre, `e pensato ap- positamente per TypeScript (`e realizzato in TypeScript) e quindi garantisce un’estrema accuratezza nei tipi delle sue API.

Capitolo 3

Architettura e

Implementazione

Nel terzo capitolo di questo elaborato si procede ad analizzare l’archi- tettura del sistema e come essa `e stata pensata per soddisfare gli obiettivi gi`a introdotti nel capitolo precedente. Dopodich´e `e presente una fase de- dicata all’implementazione della Sentiment Analysis che include le decisioni che hanno portato alla scelta di un particolare provider cloud; ed infine nel- l’ultima parte vengono discussi alcuni aspetti implementativi di particolare interesse, divisi per componenti principali.

3.1

Architettura

L’architettura del progetto DARE-SAM si compone di diversi componenti ben definiti e separati tra di loro. Questo permette, come gi`a visto in pre- cedenza nello scorso capitolo, di superare le varie sfide proposte da Facebook Graph API e allo stesso tempo risulta una soluzione pi`u efficiente. Inoltre, nel caso si introduca la necessit`a di aumentare capacit`a in futuro, la seguente architettura permette di farlo solamente per i componenti che lo necessitano.

40 3. Architettura e Implementazione

3.1.1

Componenti

Di seguito viene riportato uno schema esplicativo dell’architettura di DARE-SAM (3.1):

Figura 3.1: Schema concettuale dell’architettura di DARE-SAM

I componenti in dettaglio sono i seguenti:

• Backend Service: `e il servizio responsabile di estrarre nuovi contenuti dai social network, sottomettere i testi al servizio di Sentiment Analysis per l’elaborazione e aggiornare i dati all’interno del database. I requisiti principali che esso deve soddisfare sono:

– eseguire ad ogni intervallo di tempo precedentemente stabilito (idealmente ogni ora);

– per ogni utente, estrarre i contenuti pubblicati sui suoi profili social registrati ed aggiornarli all’interno del database;

3.1 Architettura 41

– computare il sentimento dei nuovi testi non ancora analizzati (po- st, commenti) tramite l’utilizzo del Sentiment Analysis Cloud Ser- vice.

• Next.js API Routes: considerato come l’API che mette in comunica- zione Client Web e database. I compiti principali sono:

– gestire l’aggiornamento dei profili social da parte degli utenti;

– gestire l’autenticazione;

– rendere i dati contenuti nel database correttamente accessibili dalla piattaforma web.

• database: PostgreSQL, accedibile sia dal Backend Service che dalle Next.js API Routes;

• Sentiment Analysis Cloud Service: servizio responsabile di effettuare Sentiment Analysis sui testi raccolti dalle piattaforme social;

• Client Web: piattaforma web accedibile da qualsiasi browser, permette di visualizzare informazioni e gestire i profili social collegati all’account dell’utente.

3.1.2

Hosting

L’hosting dell’infrastruttura deve essere correttamente progettato per man- tenere i vantaggi che l’architettura scelta permette di raggiungere. `E stato scelto di includere due approcci differenti, uno con lo scopo di una maggior semplicit`a nell’aumentare capacit`a mentre l’altro `e pensato per una mag- gior efficienza (costi ridotti). Prima di elencare le differenze tra essi `e per`o necessario introdurne i punti in comune:

• Sentiment Analysis Cloud Service: l’accesso al servizio di Sentiment Analysis rimane costante per i diversi approcci. Esso avverr`a infatti tramite provider cloud, quindi non `e necessario gestirne la capacit`a e allo stesso modo non `e possibile avera variazioni di prezzo;

42 3. Architettura e Implementazione

• Client Web + Next.js API Routes: come gi`a introdotto nel capitolo pre- cedente, una delle funzionalit`a pi`u interessanti di Next.js `e la presenza delle API Routes, endpoints raggiungibili ad un particolare indirizzo che ricevono una richiesta HTTP e ritornano una risposta. Esse pos- sono essere utilizzate tramite un pi`u classico server (con il comando ‘next start’ [104]), ma il modo suggerito dai creatori del framework `e quello di utilizzare funzioni serverless [105] per ciascuna richiesta, in quanto ci`o semplifica notevolmente l’architettura. Questa `e una delle funzionalit`a pi`u interessanti offerte dalla piattaforma Vercel [106], pro- vider con cui si `e deciso di effettuare hosting di Client Web e Next.js API Routes. Oltre alla gi`a citata possibilit`a di lanciare API Routes in modalit`a serverless, Vercel offre una CDN (Content Delivery Network [107]) globale con cui `e possibile servire le parti statiche del Client Web da una location il pi`u vicina possibile all’utente finale, con l’obiettivo di ridurre il tempo necessario a caricare pagine web. Tutto ci`o `e ottenibile gi`a dal piano Hobby [108] a $ 0 al mese, il che rende Vercel un’ottima scelta per il caso d’uso di DARE-SAM.

Ora si analizzaranno invece le differenze tra i due approcci introdotti in precedenza.

Primo approccio: una singola macchina

In questa architettura, Backend Service e database vengono posizionati su una stessa macchina per avere un costo pi`u basso. Una piattaforma che permette di semplificare numerose azioni relative alla gestione di questa ar- chitettura `e Dokku [109]. Essa `e una PaaS (“Platform as a Service”, [110]) che, sfruttando Docker [111], permette di realizzare architetture componibili con pi`u servizi su una singola macchina. Dokku raggruppa tutte le risorse necessarie al funzionamento di un servizio (database, message buses, ecc.) e rende pi`u semplice il monitoraggio e il deployment di nuovi cambiamenti. Di seguito `e presente uno schema esplicativo di questo approccio (3.2):

3.1 Architettura 43

Figura 3.2: Schema concettuale dell’approccio architetturale ad una singola macchina

Il server potrebbe essere una qualsiasi macchina con Docker e Dokku in- stallati, e alcune soluzioni cloud online sono decisamente economiche. Un esempio di provider cloud che soddisfa pienamente i requisiti di questa ar- chitettura `e DigitalOcean [112], che offre VPS (“Virtual Private Server”) chiamate “Droplets” [113] a partire da $ 5 al mese [114]. Inoltre `e possibi- le creare una Droplet con gi`a Dokku e Docker installati, e ci`o ha permesso di risparmiare tempo per inizializzare il server. Con questo approccio si ottengono i seguenti vantaggi:

• centralizzazione: essendo Backend Service e database sulla stessa mac- china, gestire e deployare modifiche ad entrambi risulta semplificato; ci`o permette inoltre di avere latenza nulla tra i due componenti;

44 3. Architettura e Implementazione

• costo: l’unico costo da sostenere `e quello dell’istanza che, come descritto in precedenza, pu`o essere particolarmente ridotto;

• modulabilit`a: Dokku presenta numerosi plugin e, nel caso si verifichi la necessit`a di aggiungerne di altri (ulteriori database, Message bu- ses, ecc.) all’occorrenza, ci`o sarebbe estremamente semplice e non comporterebbe aumenti di costi.

Gli svantaggi principali invece sono:

• singolo punto di fallimento: un possibile problema all’istanza risulte- rebbe in un malfunzionamento di entrambi Backend Service e database;

• difficile aumentare capacit`a selettivamente: anche se, come abbiamo visto, Dokku permette di installare plugin per aggiungere risorse al- l’architettura, tutte le risorse sarebbero istanziate su una singola mac- china; ci`o renderebbe complesso aumentare la capacit`a di un singolo componente (database o Backend Service) lasciando gli altri invariati.

Secondo approccio: due macchine separate con Database as a Ser- vice

In questa seconda proposta, il Backend Service risiede su una macchina mentre per il database vengono utilizzati servizi all’avanguardia che permet- tono di avere numerosi vantaggi per quanto riguarda hosting di database: Database as a Service (abbr. DBaaS ). Come prima cosa, essi non richie- dono allo sviluppatore installazione e configurazione manuale di macchine in quanto ci`o viene automaticamente eseguito dal provider, risparmiando tempo. Oltre a ci`o, un DBaaS permette di aumentare capacit`a in maniera estremamente semplice, aumentando le risorse hardware dell’istanza (numero di CPU e memoria) oppure aggiungendo “repliche di lettura”, ovvero mac- chine addizionali il cui compito `e quello di rispondere alle richieste al posto del database primario. Infine, numerosi provider cloud permettono di avere un backup automatico del database ad ogni momento in modo da avere la

3.1 Architettura 45

certezza di non perdere dati neanche nel caso di malfunzionamenti all’istan- za. Un esempio di DBaaS `e Amazon RDS [115], servizio che include tutte le funzionalit`a gi`a citate e molte altre, offrendo allo sviluppatore la massima configurabilit`a.

Nella seguente figura (3.3) `e riportato un diagramma di questo secondo approccio:

Figura 3.3: Schema concettuale dell’approccio architetturale con DaaS

I vantaggi principali che questo approccio introduce sono:

• semplicit`a nell’aumentare capacit`a: `e veramente semplice scalare sola- mente uno dei due componenti (Backend Service e database) in quanto essi risiedono su due macchine separate; inoltre, come abbiamo vi- sto, un DBaaS permette di avere numerose funzionalit`a aggiuntive estremamente utili per lavorare con i database;

• affidabilit`a: alcuni DBaaS prevedono funzionalit`a aggiuntive per repli- care i dati in modo da aumentare l’affidabilit`a; oltre a ci`o, in questo

46 3. Architettura e Implementazione

caso un eventuale malfunzionamento ad uno dei due componenti non causerebbe downtime di tutto il servizio.

I punti negativi invece si riassumono in:

• costo maggiore: quest’architettura ha un costo potenziale pi`u alto in quanto sono necessarie pi`u risorse hardware.

Per lo sviluppo e la validazione della fase iniziale del progetto DARE- SAM si `e optato per il primo approccio con una singola macchina in quanto i costi ridotti hanno una rilevanza maggiore rispetto all’affidabilit`a e alla maggiore scalabilit`a. Sono stati incluse entrambe le architetture in quanto eventuali sviluppi futuri del progetto potrebbero avere diversi requisiti per cui il secondo approccio risulterebbe pi`u adeguato.

3.2

Sentiment Analysis

La Sentiment Analysis, come gi`a descritto in precedenza, `e un aspet- to fondamentale del sistema che deve essere accuratamente architettato per garantire un’elevata accuratezza ed efficienza. Nel secondo capitolo (2.2.2) si sono discusse le motivazioni che hanno portato alla scelta di utilizzare un servizio offerto da un provider cloud, mentre ora verr`a affrontata una comparazione dei vari servizi gi`a introdotti per scegliere quello migliore per DARE-SAM.

SentiRace

Per questo scopo `e stato realizzato un software specifico chiamato Sen- tiRace (open source, visitabile all’indirizzo https://github.com/Gobbees/ SentiRace). Esso `e in grado di ricevere una lista di frasi in input (da elencare nel file input.json) assieme alla lingua (in alcuni dei servizi `e obbligatorio specificare la lingua), computare il sentimento per ognuna delle frasi tramite tutti e quattro i servizi visti in precedenza (Google Cloud Natural Langua- ge, Azure Text Analytics, IBM Watson Natural Language Understanding e

3.2 Sentiment Analysis 47

Amazon Comprehend ) e creare un report consultabile dall’utente.

Per scegliere il pi`u accurato relativo al caso d’uso di DARE-SAM sono sta- ti accuratamente scelti testi specifici relativi a vari argomenti di interesse estratti dalla pagina Facebook del sindaco di Ravenna Michele de Pascale [67]. In essi sono presenti vari temi caldi nell’ultimo periodo per la realt`a Ravennate, tra cui Covid 19, politica e Darsena. Il risultato realizzato da SentiRace `e quindi il seguente:

Figura 3.4: Risultato della computazione del sentimento effettuata da

SentiRace

Dopo un’accurata analisi dei risultati e comparazione tra sentimento com- putato dai servizi e sentimento riscontrato da esseri umani, si `e deciso che Azure Text Analytics `e il pi`u accurato, seguito da Google Cloud Natural Language (esso ha un formato del risultato diverso dagli altri in quanto il sentimento `e classificato su una scala da -1 a 1).

Un secondo risultato interessante offerto da SentiRace `e visibile nel file result.json generato a seguito dell’esecuzione, che contiene, per ogni ser-

48 3. Architettura e Implementazione

vizio, la risposta completa ritornato dalla richiesta. Se si analizza il risultato di una frase computato da Azure Text Analytics:

1 { 2 " id ": " 0 ", 3 " w a r n i n g s ": [] , 4 " s e n t i m e n t ": " m i x e d ", 5 " c o n f i d e n c e S c o r e s ": { 6 " p o s i t i v e ": 0.62 , 7 " n e u t r a l ": 0.05 , 8 " n e g a t i v e ": 0 . 3 3 9 } , 10 " s e n t e n c e s ": [ 11 { 12 " t e x t ": " T r o p p o g i o v a n i per m o r i r e dl covid , c o n d o g l i a n z e a t u t t i i p a r e n t i dei d e f u n t i . ", 13 " s e n t i m e n t ": " n e g a t i v e ", 14 " c o n f i d e n c e S c o r e s ": { 15 " p o s i t i v e ": 0.27 , 16 " n e u t r a l ": 0.08 , 17 " n e g a t i v e ": 0 . 6 5 18 } , 19 " o f f s e t ": 0 , 20 " l e n g t h ": 81 21 } , 22 { 23 " t e x t ": " B u o n a n o t t e S i n d a c o e s t a f f . ", 24 " s e n t i m e n t ": " p o s i t i v e ", 25 " c o n f i d e n c e S c o r e s ": { 26 " p o s i t i v e ": 0.97 , 27 " n e u t r a l ": 0.03 , 28 " n e g a t i v e ": 0 29 } , 30 " o f f s e t ": 82 , 31 " l e n g t h ": 28 32 } 33 ] 34 }

3.3 Implementazione 49

si pu`o notare come sia presente una divisione in frasi con computazione del sentimento relativo a ciascuna di esse (nel testo di esempio la prima parte ha sentimento negativo mentre la seconda ha sentimento positivo). Questo consiste in una funzionalit`a interessantissima che potrebbe essere sfruttata in uno sviluppo futuro del software. Una funzionalit`a simile `e offerta anche dal servizio Google Cloud Natural Language.

Grazie alle precedenti considerazioni in materia di accuratezza ed efficien- za (affrontata nel secondo capiolo) e all’introduzione di questa interessante funzionalit`a, si `e quindi deciso di proseguire con l’utilizzo del servizio Azure Text Analytics per la prima versione di DARE-SAM.

3.3

Implementazione

Questa sezione ha come obiettivo quello di far risaltare alcuni aspetti implementativi principali realizzati durante lo sviluppo del progetto DARE- SAM, divisi per componente architetturale, introducendo inoltre una breve sezione che illustra la struttura del repository (visitabile all’indirizzo

https://github.com/Gobbees/dare-sam).