Introduzione
In questa ultima puntata su Vert.x [1] andremo a completare e rifinire il nostro codice in maniera tale da far funzionare la nostra applicazione.
Dopo attenta riflessione, mi sono deciso a completare la pagina web in maniera tale da avere un Layer per interagire con la nostra API e mostrare che si può effettivamente fare una applicazione Vert.x completa e rilasciarla con un semplice jar eseguibile.
Come sempre anche in questo caso prendiamo il nostro master aggiornato e creiamo la nostra branch di lavoro: “final” [2]
Completiamo il codice
Come accennato l’ultima volta, provando a testare la nostra API tramite curl, notiamo che non tutto va come avevamo pensato. Anche lanciando i test ci ritroviamo con dei test non superati, sopratutto per quanto riguarda la parte riguardante le API Rest.
Analizzando i log, possiamo facilmente capire gli interventi da effettuare sul nostro codice. Un primo intervento da fare risulta essere la rimozione del datastore implementato la volta precedente con una semplice lista, nella parte del WebVerticle.
Chiamate verso il DB
Una volta rimosso il codice andiamo a implementare le chiamate verso il DB. Per fare questo utilizziamo la coda (Event Bus) che Vert.x mette a disposizione.
Il lavoro da fare è semplice visto che non dobbiamo fare altro che prendere il codice sviluppato nella scorsa puntata all’interno della nostra classe di test: TodoDataStoreVerticleTestCase.java. Non sto a mostrarvi tutte le modifiche fatte alla classe WebVerticle.java: per questo vi rimando al repository su ghithub. Mi limito a mostrarvi le modifiche fatte per la lettura di tutti i TODO e quelle fatte per la creazione. Li potete vedere nel codice riportato qui sotto.
Gestione degli errori
Ho poi migliorato la gestione di eventuali errori durante la lettura o nella creazione dei dati. In generale ora, in caso di errore, oltre a ritornare il codice di errore HTTP, restituisco anche un messaggio di errore da mostrare a video. Nel caso l’operazione di salvataggio o di aggiornamento sia eseguita correttamente, viene restituito il nuovo oggetto.
Test e chiamate
Una volta completata l’implementazione del codice su tutti gli handler che compongono la nostra API, rilanciando i test otteniamo lo stato “green” in perfetto stile TDD.
Ho provato poi l’applicazione preparando una serie di chiamate da eseguire con curl per verificare che tutto funzioni come preventivato e anche per avvallare il risultato dei test eseguiti precedentemente. Qui sotto potete vedere due delle chiamate preparate.
ReactJS
Come più volte promesso nelle puntate precedenti, ho trovato anche il tempo per lavorare alla pagina web, da utilizzare come front-end per la nostra applicazione. Premetto che non ho voluto sviluppare funzionalità lato utente per tutte le API presenti, questo per non togliere l’attenzione da Vert.x.
All’inizio pensavo di sviluppare il front-end utilizzando JQuery [3], ottima libreria che lavora a basso livello con il DOM e permette di creare velocemente le chiamate HTTP verso la API rest in maniera semplice.
Successivamente guardando qualche post su Linkedin, che parlava di ReactJS [4], ho deciso di leggermi un pò di documentazione e la tentazione di utilizzarlo è stata grande. Ho quindi deciso di utilizzare proprio quest’ultimo per creare la parte di front-end. Il risultato è stato secondo me buono, considerando alcuni aspetti:
- creazione di un’applicazione leggera;
- nessun utilizzo di strumenti per la creazione del codice.
I punti di forza di ReactJS
Non mi dilungo a parlare di ReactJS. Servirebbero per quello almeno altre cinque puntate; mi basta dire che ad oggi è uno dei due framework principali insieme ad Angular, per creare applicazioni Single page e che ha alcuni punti di forza che posso riassumere così:
- È una libreria che si occupa solo della view, quindi tutto il resto è lasciato nelle mani del programmatore. Penso a comunicazione col server, traduzioni, o più semplicemente gestione dello stato. Per ognuna di queste cose si possono usare librerie esterne (fatte molto bene).
- React è abbastanza semplice da imparare e usare.
- Live previewdei cambiamenti, sfruttando le magie di webpack e dell’hot module reloading.
- React gestisce i cambiamenti di migliaia di componenti su una sola pagina senza appesantire il browser.
Un ulteriore vantaggio è la possibilità di programmare sia con ES5 sia con ES6 e quindi, in base alla crescita dello sviluppatore, di migrare alla nuova versione di JS con calma.
Sul repository GitHub potete trovare il file index.js che contiene il codice per la parte di React e che non fa altro che creare la pagina con una input text per inserire nuove Todo, e successivamente mostrarle in una lista. Facendo un click su una di esse viene cancellata. Avrei voluto inserire il codice del file, ma sarebbe troppo lungo e noioso leggerlo tutto qui; inoltre la lettura poteva essere compromessa dalle dimensioni del font.
Conclusioni
Siamo arrivati alla fine di questa avventura dove, utilizzando un semplice esempio, ho introdotto Vert.x e mostrato almeno in parte le sue potenzialità. Ci sarebbe ancora molto di cui parlare e magari in futuro ritornerò sull’argomento. Nel frattempo spero che qualcuno lo utilizzi per qualche applicazione reale e attendo feedback da voi lettori.
Un’ultima nota è che, proprio al momento di scrivere questo articolo, è stata rilasciata la versione 3.5.1 di Vert.x che apporta una serie di bug-fix e alcune nuove migliorie in molte parti dei suoi componenti. E ovviamente non mi sono lasciato perdere l’occasione di aggiornare le dipendenze del progetto.