Propensione

Presentazione progetto:

Infrastruttura hardware e servizi usati su aws

Viene usata un’istanza t2.medium su Amazon aws con 2 processori ad alta frequenza Intel Xeon e 4 GB di RAM.

Principalmente impieghiamo EC2 (Elastic Compute Cloud) per la gestione della macchina e S3 (Simple Storage Service) per la memorizzazione del backup creato automaticamente ogni giorno.

Inoltre per l’invio delle e-mail ai clienti si passa tramite Amazon SES (Simple Email Service).

Architettura dei componenti software

Framework e librerie

Il back-end è scritto quasi interamente in Java 8 usando il framework Spring 4 mentre il tool di build utilizzato è Maven 3.

Per quanto riguarda la parte java:

– Spring Boot che permette di costruire un’applicazione con le funzionalità e le configurazioni migliori per l’ambiente enterprise.

Inoltre il pacchetto creato dalla compilazione è direttamente avviabile poiché include Tomcat.

– Spring MVC (Model View Controller framework) si occupa di gestire le richieste http del client.

– Spring WS (Web Services) usato per gestire agevolmente i servizi SOAP.

– Spring Mail, un’estensione di Spring per l’invio delle e-mail.

– Spring Security, un framework per gestire l’autenticazione ed il controllo dell’accesso.

– JDBC, un’API per la connessione, l’accesso al database e relative queries.

– Flyway, un tool per la migrazione di database che serve per coordinare le modifiche che vengono sul database. Si occupa di capire a che versione si trova il database e di portarlo all’ultima versione necessaria per poter avviare correttamente l’applicazione.

Affianco a Java viene usato anche Python per il parsing dei file excel e la scrittura del database, poiché la libreria OpenPyxl si presta a tale scopo.

Database

Il database utilizzato è MySQL poiché è usato anche da WordPress.

Linguaggi di programmazione

Java, Python

Elementi di sicurezza

Viene utilizzato Apache con modulo per https, il certificato utilizzato è fornito da Let’s encrypt.

Tramite Spring Security viene controllato l’accesso ai diversi servizi forniti dal back-end, poiché alcune funzionalità sono presenti solo nell’area privata, mentre altre sono pubbliche.

Sull’istanza di MySQL sono presenti due database, uno per il back-end ed uno per WordPress.

Nel database del back-end vengono memorizzati gli utenti con la loro e-mail e l’hash della password con il salt, in modo che due utenti con la stessa password non abbiano lo stesso hash.

In un’altra tabella sono anche memorizzati i ruoli dei vari utenti rispetto alle funzionalità.

WordPress gestisce automaticamente il secondo database

Storico:

Progettazione iniziale

L’idea sarebbe quella di mantenere l’engine delle proposte (con l’implementazione della prima bozza dell’algoritmo) indipendente dal database in modo da poterla testare in modo unitario (senza “mockare” il database).

In questo modo, se vengono richieste proposte tramite l’api, queste verrano rigirate al gestore delle proposte che si occuperà di recuperare i dati che servono dal database e poi passarli all’engine per l’elaborazione.

 

Proposta tecnologie (da scheda Trello).

@karriemoore: Sebastiano ha proposto di “imparare da Generisk” per cominciare questo progetto, inoltre ha anche proposto una soluzione REST riutilizzabile.
Non si sa molto di questo progetto per ora a parte che verranno compilate delle form e salvate su un database e poi le informazioni contenute nel database verranno rielaborate.

L’idea sarebbe quindi quella di utilizzare (nel back end) le seguenti tecnologie:

-Spring boot: con moduli: web, security, jdbc, jdbc-mysql.
(proviamo ad evitare data-jpa per il momento).
-MySQL

Per quanto riguarda il front-end non so bene quali tecnologie è meglio usare, ma la mia proposta è di rendere disponibile una API REST e lasciare a chi si occupa del front-end la libertà di usarla come meglio crede.

Quindi sarà possibile usare AngularJS o NodeJS o altro.

Questo obbligherà ad avere un deploy tramite due pacchetti, ma permetterà anche di avere la parte UI e BL “deployabili” separatamente in caso fosse necessario.

Ultima cosa: Davide ha insistito sull’avere flyway per gestire le patch.

Fatemi sapere cosa ne pensate!

@angeloselvini: @karriemoore Lato frontend va benissimo l’API REST con cui interagire e lasciarci liberi di setuppare un nostro ambiente; mi chiedo se questa parte vada pensata come servita da un webserver separato/isolato o come modulo di un’unica app.

@marcoceleri: +1 per flyway.

In generisk abbiamo imparato che il FE non può essere “stupido”. Per favore, evitiamo di importare il “protocollo” di comunicazione BE/FE di generisk, dove il BE decide cosa può vedere/modificare il FE.

Lato BE cercherei di tenere aperta la porta a NoSQL (elasticsearch o altro) per i dati non anagrafici.

JPA o meno… L’importante è mantenere una buona separazione dei compiti. Senza sapere che dati mettere in SQL, difficile dire cosa sia più comodo.

@marcoceleri: Penso che sarebbe anche bene partire presto con i test di integrazione, in Bravofly mi sono trovato molto bene con DB in memory (H2) e spring-test. Così da poter testare tutto il flusso, dall’arrivo della chiamata HTTP al DB andata e ritorno.
Per farlo però bisogna evitare query SQL basate sul dialetto MySQL e usare datatype semplici.

Ricordiamoci anche i casini che abbiamo su generisk con le date nel DB. Personalmente mi trovo bene a salvare le date come numeri nel DB (salvando il timestamp in long) evitando DATE e TIMESTAMP come datatype del DB. Può sembrare un hack ma mi pare semplificare tutto.

@angeloselvini: @marcoceleri Il FE in questo caso lo immagino più simile a la EOC in cui la logica di gestione dei contenuti è tutta lato frontend e il server si limita a salvare e restituire i dati al client. Non so in questo caso quanto sia necessario caricare il frontend di logica, immagino sarà l’API REST che sottenderà il suo ruolo.

@marcoceleri: @angeloselvini Mi piace

Allegati

Propensione-pensione_integrativa_flow