Javascript lato server? E’ la scelta giusta?

Fin dalla sua nascita Javascript ha avuto una vita travagliata, è stato creato per aggiungere dinamicità a pagine web ma negli anni è diventato molto di più. Ha avuto anche momenti bui (quando Google ha creato GWT sembrava che stesse quasi per scomparire) ma è sempre tornato alla ribalta. Adesso Javascript sembra essere il linguaggio cool del momento e per questo lo troviamo ovunque, dal database alla logica di business lato server al client dentro la pagina web. Ma è sempre la scelta giusta quella di scrivere tutto in Javascript?

Le lean startup

lean startup

Il mondo delle startup d’oltreoceano è molto diverso dal mondo dello sviluppo software che siamo abituati a vedere qui in Italia. Una startup deve essere agile e poter cambiare rotta continuamente per capire quale è il modo migliore per trasformare una idea in un business sostenibile. Per questo motivo si punta su tecnologie che permettono di ridurre il time to market per poter avere un prodotto funzionante prima possibile. Per approfondire l’argomento startup (molto più vasto di quello che potrebbe sembrare) una lettura obbligata è Lean Startup di Eric Ries, un libro molto interessante che fa capire bene il cambio di prospettiva e di mentalità fra una azienda classica e una statup.

La valigia magica

Nella prima edizione di BetterSoftware Francesco Cirillo fece nel suo talk (qui trovate un post sul suo blog) un esempio molto interessante parlando della valigia da portare in un viaggio. In pratica più la valigia è grande e meno siamo veloci nello spostarsi (magari in una serata piovosa in cui c’è lo sciopero dei mezzi pubblici). Tornando a parlare di software più roba ci portiamo dietro (framework, librerie, metodologie e altro) e meno siamo reattivi al cambiamento. In alcuni software anche aggiungere un campo in una interfaccia può essere lungo fra alter table su database, modifica delle classi corrispondenti, aggiustamenti dell’interfaccia e degli altri strati del software. Diciamo la verità, su questo punto Java (soprattutto fino a qualche anno fa) rappresenta una valigia bella grossa da portare dietro: application server mastodontici da riavviare spesso, un ide che da solo riempie la memoria, un linguaggio che alcune volte non permette di scrivere in modo semplice le cose.

Lo stack Javascript per startup: MongoDB, ExpressJS, AngularJS e Node.js

Nell’ottica di avere una valigia leggera da portare in giro Javascript ci viene in aiuto. Infatti lo stack software che sta diventando molto usato soprattutto in ambito startup è tutto basato su Javascript. Alcuni dei componenti che possono essere usati in questo stack sono:

  • MongoDB per la parte di salvataggio dei dati: db NoSQL di cui abbiamo già parlato in un altro post. E’ schema less (quindi permette di cambiare la struttura dei dati al volo) ed scala facilmente su più server anche non troppo performanti;
  • Node.js per contenere la logica lato server: piattaforma basata su V8 (il motore Javascript di Chrome), è leggera e facile da usare (un server in ascolto su una porta si tira su in tre righe di codice);
  • ExpressJS come framework lato server: permette di sfruttare al massimo Node.js senza partire da zero;
  • AngulaJS per la parte di vista: framework sviluppato da Google che permette di usare il paradigma MVC anche in una pagina html. Ne parleremo presto nel dettaglio anche in questo blog.

Ovviamente non poteva mancare un acronimo per sintetizzare questo stack, per questo è stato coniato MEAN. Alcune valide alternative, che comunque non snaturano questo stack, sono CouchDB al posto di MongoDB e Ember.js o BackBone.js al posto di AngularJS.

mongodb

La scelta di andare verso un NoSQL sta diventando sempre più uno standard, i vantaggi sono molti sia dal punto di vista dello sviluppo del software (il modello object oriented è molto più vicino a un db NoSQL che non a quello relazionale) che dell’infrastruttura. MongoDB e gli altri NoSQL possono essere utilizzati tranquillamente anche in Java, i driver sono disponibili e ultimamente ci sono anche alcuni framework interessanti che aiutano nell’interfacciamento. Per esempio Spring data supporta anche MongoDB e Hibernate OGM dovrebbe diventare una implementazione JPA completa (o quasi) che si appoggia a database NoSQL.

AngularJS

AngularJS sta prendendo sempre più spazio a discapito dei framework Javascript classici (primo fra tutti JQuery). In effetti sfruttando il binding di AngularJS è possibile scrivere codice molto più pulito senza dover perdere troppo tempo nella manipolazione del dom della pagina. In più AngularJS permette di scrivere codice testabile facilmente e organizzarlo in modo pulito sfruttando la dependency injection. Insomma è un framework Javascript che piace anche a chi è abituato a usare linguaggi più strutturati! Per quanto riguarda il design di un sito web ormai sta diventando quasi uno standard per i portali Bootstrap, framework css e Javascript sviluppato per creare Twitter e poi rilasciato come progetto open source.

Node.js e la logica dell’applicazione in Javascript

nodejs

Ultimamente si parla molto di Node.js e per alcuni è una rivoluzione dello sviluppo di una web application. Qualcosa di buono l’ha sicuramente portato, secondo me almeno due cose:

  1. un Hello World si scrive in 5 minuti e con pochissime linee di codice, non c’è una infrastruttura complicata con tanti framework da mettere insieme anche per fare un semplice esempio;
  2. il server è leggerissimo, parte in attimo e occupa pochissima memoria. E’ molto veloce nel servire le pagine in quanto basato su eventi asincroni e I/O non bloccante.

Ok, sembra tutto bello se non fosse per un piccolo dettaglio: la logica di business dell’applicazione va scritta in Javascript! Per chi, come il sottoscritto, è abituato a errori in compilazione, refactoring e roba tipica dei linguaggi strong typed è una cosa abbastanza traumatizzante. Poco fa ho elogiato AngularJS e adesso sto criticando il Javascript, non sono impazzito (almeno spero!) e un motivo c’è. Una cosa è l’interfaccia grafica di una applicazione web, è di solito la parte che cambia con maggiore frequenza e solitamente anche quella meno ingegnerizzata. Un’altra cosa è quello che è il cuore dell’applicazione, il motore di tutto che deve essere solido, versatile e durare nel tempo. Insomma per l’interfaccia può andare bene scrivere un po’ di Javascript (anche perché non ci sono alternative, a parte GWT) ma per il resto no.

Domain Driven Design

Implementing domain driven design

La logica di business di una applicazione è una cosa seria, deve essere organizzata nel modo giusto e basata su una architettura che permetta di non perdere il controllo di tutto. Ma quale è il modo giusto di organizzare il core di una applicazione? Una delle possibili risposte è in un acronimo: DDD. Il Domain Driven Design è stato portato alla ribalta nel 2003 dal libro Domain-Driven Design: Tackling Complexity in the Heart of Software di Eric Evans che descrive una serie di pattern e accorgimenti da usare nell’organizzazione infrastrutturale e interna di una applicazione. Da poco è uscito anche Implementing Domain-Driven Design di Vaughn Vernon che, a distanza di dieci anni, rielabora gli stessi concetti ma con un taglio molto più pratico. Due libri consigliati (soprattutto il secondo che è un po’ più semplice da leggere) che contengono tantissimi spunti interessanti.

L’alternative Java a Node.js: Vert.x

Se vi piace l’approccio allo sviluppo di Node.js ma volete scegliere il linguaggio di programmazione da usare la soluzione può essere Vert.x. Infatti Vert.x si basa sullo stesso principio di Node.js ma permette di programmare usando Java, Ruby, Groovy, Python o JavaScript. E’ uscita recentemente la versione 2.0 da poco, può essere una valida alternativa ad un application server in alcuni contesti non troppo complessi.

Restiamo su un application server: JBoss AS diventa WildFly

Node.js ha, come già detto, il pregio della leggerezza. Non so se per “competere” con Node.js ma la direzione in cui stanno andando le nuove versioni degli application server Java è quella della leggerezza. Infatti JBoss 7 è molto più veloce (soprattutto nei tempi di startup) di JBoss 6 e anche WebSphere 8.5 è su un altro pianeta rispetto alle versioni precedenti di WebSphere.

Nell’autunno 2013 uscirà anche la versione 8 di JBoss AS che per l’occasione ha cambiato anche nome: si chiamerà WildFly e, come dice il sito ufficiale, it’s even @#$%ing faster. Sicuramente è questa la direzione giusta per vari motivi, uno di questi è quello di poter sfruttare al meglio Amazon AWS e gli altri cloud disponibili sul mercato.

Conclusioni: in che direzione andare?

In questo post abbiamo visto una carrellata di alcune tecnologie che probabilmente saranno le protagoniste del prossimo futuro. La mia opinione probabilmente l’avete intuita, potremmo coniare un nuovo acronimo, qualcosa tipo MOSAB (MongoDB, Hibernate OGM, Spring, AngularJS e Twitter Bootstrap). Ma come spesso succede nell’informatica niente è bianco o nero… Infatti una delle cose più difficile in questo mondo consiste nel trovare il giusto trade off fra due o più soluzioni. In questo caso una soluzione intermedia adottata in alcune realtà è quella di usare sia un application server Java che Node.js. La logica può essere scritta in Java mentre Node.js può essere sfruttato per servizi rest a cui si interfacciano per esempio delle app mobile. Probabilmente esistono molte altre possibili soluzioni, basta solo (si fa per dire…) scegliere quella giusta in base al contesto in cui dobbiamo adottarla!

Fabio Collini

Software Architect con esperienza su piattaforma J2EE e attualmente focalizzato principalmente in progetti di sviluppo di applicazioni Android. Attualmente sono nel team Android di Cynny, ci stiamo occupando dello sviluppo dell'app Morphcast. Coautore della seconda edizione di Android Programmazione Avanzata e docente di corsi di sviluppo su piattaforma Android. Follow me on Twitter - LinkedIn profile - Google+

  • Marco

    Ciao Fabio,
    nel progetto in cui sto lavorando mi avvicino al Mosab :), infatti sto usando spring per i servizi Rest, twitter bootstrap per la parte grafica, ma invece di Angular.js stiamo usando un’altro framework MVC javascript, e cioè Backbone. Quest’ultimo proprio non mi va giù… ormai sono mesi che ci lavoriamo ma secondo me un framework javascript non velocizza il lavoro, il più delle volte lo complica, forse rende solo un po’ più ordinato il codice js. Fosse per me userei ancora JQuery nudo e puro.

    • Fabio Collini

      Ciao Marco,
      Backbone lo conosco poco ma AngularJs mi sembra un’altro mondo rispetto a JQuery. O meglio è proprio un’altra “filosofia”, di sicuro JQuery è più immediato ma diverse volte usando JQuery in un progetto ho rimpianto di non aver utilizzato AngularJs. Poi sarà che essendo abituato a JSF AngularJs mi sembra simile solo che invece di essere lato server è lato client.
      Comunque vedremo che fine faranno questi framework Javascript… Adesso come dicevo nel post il Javascript è diventato “cool”, sono curioso di vedere chi prenderà piede nel futuro!

      • Laars Camot

        Javascript è diventato “cool”?. Javascript non ha mai avuto rivali o alternative. Non è una moda, è uno standard fin dagli anni ’90.