Dopo anni in cui PHP (e lo stack LAMP) ha dominato il mondo del WEB, e la gran parte delle piccole/medie applicazioni utilizzava questo linguaggio…. Un altro stack applicativo si sta imponendo sul “mercato”. L’acronimo del nuovo stack è MEAN. Ho deciso quindi di provare a confrontare il nuovo che avanza contro il vecchio di successo: MEAN vs LAMP.

Questi i componenti dell’architettura LAMP:

  • Linux
  • Apache web server
  • MySql
  • PHP

E ora i componenti di MEAN:

Lo stack, a mio parere è stato trascinato al successo da AngularJS (grazie anche all’appoggio fornito da Google).

Inizierei ad analizzare le principali differenze (componente per componente):

? vs L (qualsiasi sistema operativo vs Linux)

LAMP richiede Linux, le tecnologie dello stack MEAN non hanno preferenze per il sistema operativo, però a mio parere questo non è un limite di LAMP; infatti non vedo perché non si debba utilizzare linux come sistema operativo per gestire un server di un’applicazione web. 0 costì d’acquisto e 0 vulnerabilità date da questa scelta.

M vs M (MongoDB vs MySql)

Questo confronto fa capire quanto siano differenti questi due stack. La differenza è infinita, cambia proprio l’idea di come gestire e con che logica gestire i dati. Si parla di un DB relazionale, della “vecchia concezione”, MySql, e un DB document oriented.

La popolarità e la quantità di applicazioni che utilizzano MySql è nettamente superiore a quella che utilizza MongoDB, questo però potrebbe anche essere dovuto alla grandissima “differenza d’età”: 1995 contro 2009!

Facendo un compare sulle specifiche tra i due (+ Postgresql che ritengo un ottimo upgrade prestazionale rispetto a MySql) si può notare che oltre a quello già detto, la grossa differenza stia nell’impossibilità di MongoDB di gestire la transazionalità. Per un data modeller aggrappato alla concezione dei DB relazionali questo limite lo porterà a mantenersi su MySql o comunque su DB che gestiscano la transazionalità. Per data modeller che conoscono le idee del document oriented, questo limite non sarà nemmeno preso in considerazione.

Dando per scontato la conoscenza da parte dei lettori dei DB relazionali, andrei a spiegare alcuni concetti chiave della concezione document oriented:

  • Le vecchie tabelle sono sostituite dal concetto di collection (che è un contenitore di oggetti). La collection ha lo stesso significato che possiede nei linguaggi di programmazione ad oggetti, cioè un insieme di oggetti con proprietà simili. In generale, MongoDB si avvicina molto ai linguaggi di programmazione OO, questo porta grossi vantaggi in termini di associazione (mapping) tra un’entità su DB e un oggetto Java/JS/…
  • Il singolo oggetto all’interno del documento viene visualizzato attraverso JSON (javascript object notation) che è lo standard per il trasferimento di informazioni sulla rete tra server e la web application utilizzando un formato leggibile per noi umani ma viene salvato in BSON (binary JSON). Gli oggetti possono a loro volta contenere array di altri tipi/oggetti.
  • Non esiste SQL, l’interrogazione avviene attraverso la chiamata a API che svolgono le stesse funzioni
  • La possibilità di replicazione e alta affidabilità sono garantite (così come su MySql)

Da programmatore i vantaggi forniti da MongoDB non sono da sottovalutare, e la rimozione del disaccoppiamento tra DB e rappresentazione su applicazione web è un vantaggio.

EA vs P (Express e Angular vs PHP)

Ok, sono nato come sviluppatore Java, apprezzo molto quel linguaggio e la sua filosofia. Mi sono adattato abbastanza in fretta a Javascript/JQuery e ormai sono entrati nel mio piccolo background. Data questa premessa, come potrei dire che PHP sia qualcosa di buono?

Tornando oggettivo: PHP unisce quello che viene gestito attraverso Express, Angular e Node. Sono due i casi: PHP è un linguaggio geniale, oppure bisogna essere dei geni per riuscire a gestire questo linguaggio senza scrivere codice incomprensibile. Questo linguaggio (forse un po’ meno nella versione 5) riesce a rendere complicato e illeggibile qualsiasi cosa sia non sia semplice da implementare. Infatti non permette una comoda divisione dell’architettura MVC che a mio parere oggigiorno è un must, soprattutto quando le applicazioni iniziano a complicarsi e la manutenibilità diventa un aspetto da prendere attentamente in considerazione.

Questo non succede con AngularJS, infatti questa tecnologia consente di dividere la vista e il controller dal model (NodeJS + Express). L’intelligenza di Angular sta nell’aver preso una tecnologia di grande successo ma che aveva limiti (HTML 5) e aver lavorato in modo da eliminare questi limiti.

HTML non permette la gestione di dati dinamici, Angular l’ha implementato!

Attraverso la notazione su componenti standard qualsiasi è possibile associare questi componenti a delle proprietà di oggetti descritti nel controller e probabilmente recuperati dal model.

HTML non consente la definizione di componenti diversi da quelli standard, Angular si!

Angular permette la definizione di questi componenti non standard, essi non sono altro che delle strutture HTML con componenti standard che consentono una scrittura più pulita e leggibile di codice. Gli sviluppatori di Angular chiamano queste componenti directives. Le directives consentono agli sviluppatori di applicazioni web di risparmiare parecchie righe di codice (utilizzando pochi caratteri per replicare strutture complesse).

Ovviamente non voglio sputare sul linguaggio che nel passato a fatto la voce tra le applicazioni web grazie alla sua flessibilità e potenza, cosa che rimane e che continua ad essere il punto di forza di questo linguaggio.

Non mi soffermerei molto in questo articolo su Express: questo è un web application framework, a detta degli sviluppatori minimale e flessibile che consente a noi sviluppatori di gestire, utilizzare e sviluppare la nostra applicazione basata su Node.JS senza perdere tempo in sviluppi di cose già fatte (magari anche meglio).  Vi invito nuovamente ad andare a questo indirizzo per approfondire maggiormente.

A vs N (Apache vs Node.JS)

Il confronto è forzato, però ho letto più di un articolo che confrontando aspetti delle varie architetture cercava di fare questo confronto.

In realtà, apache è il “motore” che trasforma il PHP residente sul server in HTML che viene inviato dallo stesso e letto dai browser. NodeJS si occupa di eseguire il codice Javascript scritto e residente sul server e di fornire una risposta al controller. Altri analogisimi non ci sono… Quindi inutile continuare a discuterne, però vorrei comunque parlare un attimo di NodeJS e quanto io lo ritenga una grossa innovazione (senza comunque aver inventato nulla di fuori dal mondo):

Node.JS non è altro che l’unione tra un linguaggio di programmazione conosciutissimo nel mondo del web (JS) e un motore che esegue le istruzioni scritte (questo è il motore JS presente su chrome). Può essere utilizzato per esporre dei servizi WEB che facciano da tramite tra le varie risorse e il controller. Un server NodeJS può mettersi in ascolto su delle porte, inviare dati, leggere file, interrogare DB….. La potenza di NodeJS e in generale di JS è quella di lavorare per eventi. Infatti l’asincronicità è ereditata da questo linguaggio: attraverso le callback è possibile iniziare a soddisfare una richiesta e nello stesso tempo restare pronto in ascolto per poter soddisfare contemporaneamente molte altre richieste.

Apache credo sia conosciuto da chiunque, si occupa di esporre pagine HTML, PHP e qualsiasi altra risorsa sul WEB. L’utilizzo di apache è vasto e non è solo un componente di questo stack, ma è il componente di quasi qualsiasi stack. Apache dà la possibilità ai sistemisti di infrapporre un ulteriore layer tra client e server, con la possibilità di gestire migliaia di opzioni. Quindi, non vedo perché apache non possa essere un componente presente nell’architettura di un’applicazione MEAN.

In conclusione

Ho provato in tutti i modi (non è vero, lo so) a nascondere il mio entusiasmo verso questo nuovo stack e le (più o meno) nuove tecnologie legate a questo. Il confronto è difficile, se non impossibile, perché l’idea che alimenta i due stack è diametralmente opposta. La moda ormai porta a evolvere e passare verso MEAN, e a mio parere anche la ragione potrebbe portare a seguire questa direzione. Non si può non ammettere che Angular sia un linguaggio più “moderno” di PHP e permetta allo sviluppatore di scrivere codice più leggibile.