Per ragioni che sarebbe troppo lungo spiegare in questa sede, stiamo abbandonando (almeno temporaneamente) il nostro abituale ambiente di lavoro basato su Python (Django, Pylons, etc.) per adottare Java (Eclipse e Netbeans, Tapestry, Spring, Hibernate, etc.). In questa fase di passaggio ci siamo trovati ad esaminare diversi framework, alcuni dei quali per lo sviluppo di applicazioni Desktop, come Netbeans platform e Swing Application Framework (JSR 296) ed altri destinati allo sviluppo web, come Spring e Tapestry.
Uno dei punti su cui siamo stati costretti a riflettere è stato questo: con l’avvento di Ajax, ha ancora senso usare dei web framework server-side?
La vista sul client e la vista sul server
Se ci pensate un attimo, non ha molto senso sviluppare un’applicazione Java che gira sul server e genera un’interfaccia utente HTML+CSS+Javascript che poi deve essere spedita al browser per la visualizzazione ogni volta che viene aggiornata. Ajax, infatti, viene usato proprio per mantenere l’elaborazione ed i dati il più possibile sul lato client del sistema, riducendo al minimo gli scambi tra client e server e tutte le relative inefficienze. I sistemi basati su Ajax hanno un’unica interfaccia utente per ogni task individualmente riconoscibile: una UI per inserire dati in un database, una UI per elencare quei dati in forma tabulare e via dicendo. Queste interfacce non vengono mai sostituite (“aggiornate”) fino a che non si passa ad un task diverso. L’unica cosa che viene scaricata dal server è l’insieme di dati su cui si deve operare. Questo rende l’interfaccia più reattiva e riduce il carico sulla rete e sul server, con sollievo di tutte le parti in causa.
In buona sostanza, con l’avvento di Ajax la V (la “Vista”) del modello MVC (Modello/Vista/Controllo o ModelView/Controller) è stata spostata dal server (classi Java e template HTML/CSS/JS) al browser (classi Javascript e Widgets HTML/CSS/JS).
A questo punto, la tentazione di mandare al diavolo i tradizionali framework server-side, come Zend, Swing o Django, è piuttosto forte. In linea di principio, infatti, si potrebbe creare una applicazione formata da un ricco client Ajax che ottiene i dati ed i servizi che le sono necessari da uno o più server usando degli appositi servizi (SOAP, XML-RPC e simili). Insomma, si potrebbe usare quella che viene definita una architettura RIA-SOA (Rich Internet Application – Service Oriented Architecture).
Ma, allora, perchè portarsi ancora appresso una palla al piede come Swing, Zend o Pylons quando si potrebbero sviluppare alcuni service SOAP ed una bella RIA Ajax?
Un vecchio problema
Questa è, in realtà, una domanda che si stanno ponendo molti sviluppatori web da almeno 4 o 5 anni. Se ne trovano molte tracce su internet in questi vecchi articoli:
“Web frameworks peaking toward obsolescence“
“Does the rise of Service Oriented UI (SOUI) means the death of server-assisted MVC?“
E, come potete vedere da questo link che segue, si tratta di un argomento che è ancora oggi in grado di suscitare violente discussioni:
“The Future of Web Frameworks at TSSJS“
In quest’ultimo articolo, Matt Raible sostiene addirittura che i web framework tradizionali corrano il rischio di essere abbandonati a sè stessi nel prossimo futuro:
“Interest in server-side frameworks will continue, but frameworks will become unmaintained”
Dal sogno alla realtà: i framework Ajax
In realtà, sono già stati sviluppati diversi framework che mettono in pratica proprio questi concetti e che permettono, in una misura più o meno marcata ed in modo più o meno riuscito, di scrivere un’intera applicazione sul solo lato client (sul browser), appoggiandosi al server solo per alcuni specifici servizi (implementati come web service SOAP o roba simile). Ne trovate alcuni esempi qui:
http://code.google.com/intl/it-IT/webtoolkit/
Perchè allora insistere su tecnologie ormai palesemente obsolete come i framework server-side?
Troppa roba sul client
La risposta alla domanda precedente dipende strettamente dalle preferenze personali e dal tipo di compito che si deve svolgere. Non è la stessa cosa sviluppare un desktop online come Glide (http://www.glidedigital.com/) od una applicazione finanziaria come il sistema di home banking di FINECO. Non è nemmeno la stessa cosa svolgere uno di questi compiti provenendo da anni di programmazione ASP (più o meno .NET) o da anni di programmazione Java. Ci sono abitudini diverse e modi di osservare/interpretare il mondo diversi che portano a risposte diverse.
Personalmente, mi sono dato questa risposta: secondo me, usando dei framework Ajax come Cappuccino e DWR si finisce per mettere troppa roba nel client, e questo non è detto che sia un bene.
Detto in altri termini, usando questo approcio c’è il rischio di spostare tutto o parte del “business layer” sul client, dentro il browser dell’utente. Il business layer è quella parte di codice che svolge effettivamente i calcoli significativi per l’applicazione e per il suo proprietario. Si trova tra il “presentation layer “(la “vista”, o “view”, rappresentata dalla pagina web) ed il “model layer” (la parte di codice che interagisce con il database ed il database stesso). Per sua natura, il business layer contiene dati ed algoritmi sensibili. Se questa parte di codice deve essere eseguita dal client (il browser dell’utente), deve essere inviata al client stesso via HTTP sotto forma di codice Javascript. Di conseguenza, questo codice può essere ottenuto da un malintenzionato, può essere studiato e modificato e può essere poi usato per attaccare il server.
Quasi tutti i framework Ajax, infatti, prevedono qualche forma di difesa da questo tipo di attacco (arrivando anche a forme piuttosto energiche di crittografia) e non mancano certo le “best practices” da seguire.
Per quando mi riguarda, tuttavia, credo che terrò dati e business logic sul server, al riparo da sguardi indiscreti.
Oltre a questo problema di sicurezza, c’è anche un problema di “peso”. Se il client deve eseguire una parte significativa del programma, è necessario inviare e caricare sul client una parte non piccola di codice, con tutti i ritardi che è facile prevedere. Questa latenza iniziale nell’esecuzione del codice rischia di vanificare i vantaggi di Ajax, riportando la situazione al punto in cui si doveva caricare la pagina web per aggiornare i risultati.
Windows in Javascript
Il problema più serio, tuttavia, mi sembra essere quello legato alla complessità di queste applicazioni. Con i moderni framework Ajax è effettivamente possibile scrivere dei veri desktop environment e dei veri sistemi operativi che girano all’interno del browser. Il già citato Glide ne è un esempio lampante e basta effettuare una ricerca Google con “online desktop” o “online operating system” per trovarne diversi altri, uno più bello dell’altro.
Non è però detto che scrivere un’applicazione di questa complessità con questi strumenti sia anche facile. Soprattutto, non è detto che il codice risultante sia manutenibile.
Scrivere un’applicazione complessa è già un casino quando si può fare uso di strumenti di ingegnerizzazione del codice come quelli messi a disposizione da C++, Python e Java. È già un casino quando si può fare uso di strumenti di gestione del processo produttivo come Maven, Junit, Coverity e Hudson. Riesco appena ad immaginare il casino che dev’essere sviluppare applicazioni complesse sul lato client in questo modo, dovendo anche fare i conti con la presenza della “sandbox” rappresentata dal browser (niente accesso al file system locale, concetto di sessione a dir poco convoluto, etc.).
Francamente, non credo che basti avere un linguaggio OOP-capable come le ultime versioni di Javascript per sentirsi al sicuro. La OOP si è già dimostrata insufficiente sul lato server, portando all’adozione della AOP (Aspect-Oriented Programming) e di diversi Design Pattern, come la Inversion of Control, per cui… Non credo nemmeno che basti una nutrita libreria di widget grafici e di moduli di codice per sentirsi al sicuro. Anche molti toolkit tradizionali hanno queste caratteristiche (vedi Qt o Netbeans platform, per esempio) ma non per questo sono facili da gestire senza altri strumenti.
Intendiamoci: Cappuccino e DWR mi piacciono da morire e sicuramente ci farò qualcosa in futuro, almeno per uso personale. Quello che mi trattiene dall’usare queste tecnologie “sul campo” è qualcosa di diverso, qualcosa legato alla possibilità di fornire al committente qualcosa di affidabile e di manutenibile, nei tempi e con i costi che devono essere rispettatti.
Real RIA
Nelle applicazioni che richiedono una interfaccia utente veramente ricca e reattiva, mi sembra più logico continuare ad usare delle vere RIA (Rich Internet Application), come quelle che è possibile sviluppare con Qt (C++ e Python), Netbeans Platform (java), Eclipse RCP (Java), wxWidgets (C++ e Python) e GTK (C++ e Python). In questo modo si ottiene un “thick client” robusto ed affidabile, senza dover fare i conti con le stranezze di una mezza dozzina di browser diversi e senza rischiare di esporre informazioni sensibili all’utente finale.
Questa è anche la ragione per cui non credo che i sistemi di “offline computing”, come Google Gears, Adobe AIR e simili, abbiano molto senso. Basta dare un’occhiata alla documentazione di molti di questi aggeggi per capire che per rendere fruibile offline un’applicazione nata per essere usata online si sarebbe costretti a riscriverne una parte significativa a mano. A quel punto, probabilmente è più razionale usare qualcosa di diverso (una RIA Java, ad esempio).
Il Re della Foresta
L’unica vera ragione di usare tecnologie Ajax in modo così estremo è la necessità di avere un’applicazione “no-install”, che faccia uso del solo browser web dell’utente per le proprie necessità. Al giorno d’oggi, infatti, il browser viene spesso visto come il vero Re della Foresta: l’unica applicazione che l’utente dovrebbe mai usare. Uno strumento unico con cui fare di tutto, dalla gestione della posta elettronica (webmail) alla gestione di progetti complessi e gruppi di lavoro (groupware).
Francamente, però, questa fissazione per le applicazioni browser-based è del tutto priva di fondamenta razionali.
Evitare all’utente i problemi ed i “thrill” legati all’installazione di un programma ha senso solo quando l’utente è veramente un “utonto” e/o quando l’applicazione è talmente superflua da non meritare nemmeno questo piccolo sacrificio (giochi online e cose simili). Non ha nessun senso pretendere di gestire applicazioni finanziarie in questo modo (non sto parlando dell’home banking).
Quando l’applicazione ha una sua dignità e l’utente non è un completo idiota, è di gran lunga meglio usare lo strumento giusto per il compito da svolgere, sia esso una RIA Java o un’applicazione net-enabled in C++. Al giorno d’oggi ci sono reti talmente veloci ed installer talmente raffinati che scaricare ed installare un’applicazione dedicata è veramente un gioco da ragazzi.
Conclusioni
In conclusione, credo che continuerò ad usare Ajax solo per gestire dati tabulari, come ho sempre fatto. Queste tecnologie client-side non mi piacevano molto ai tempi di IE5, e delle prime avvisagle di XmlHttpRequest, e continuano a piacermi poco anche adesso.
Voi che ne pensate? Potete dire la vostra usando i commenti qui sotto.
Alessandro Bottoni
