Il web evolve. E' un fatto sotto gli occhi di chiunque naviga ed ha un minimo di cognizione sui siti dove capita: non stò parlando del fatidico "web 2.0", concezione più filsofica che pratica per indicare una trasformazione nell'idea di Internet, piuttosto mi riferisco a questioni più pratiche, rivolte agli sviluppatori di siti/applicazioni web.
Veniamo al dunque: la diffusione dei servizi cosidetti sociali ha portato alla nascita di numerosi framework e librerie per la generazione di interfacce sempre più flessibili e potenti, utilizzate dai più per rendere l'esperienza dei siti web sempre più simile (se non migliore) a quella di applicazioni native.
Da un certo punto di vista l'utilizzo estensivo di javascript sul lato client è visto come un miglioramento: le pagine web non sono più "stupide" raccolte di dati, ma sono interattive e permettono quindi una friuzione più completa del sito. Da un altro punto di vista le applicazioni web che sfruttano esclusivamente javascript per presentare contenuti (attenzione, parlo di "presentazione dei contenuti", non di "interazione" con gli stessi, sono due cose differenti almeno per me) è, semplicemente, disastrosa per vari motivi:
la modifica a runtime del DOM dell'html è difficile da rendere accessibile;
i motori di ricerca non riescono a indicizzare pagine create dinamicamente sul client;
di fatto si rende impossibile (con poche eccezioni) funzionalità quali bookmark e passaggio di link per l'identificazione delle risorse.
Quindi, qualcuno penserà, il cheng crede che javascript sia sbagliato, che era meglio quando il browser per qualsiasi azione faceva il reload completo della pagina, che si stava meglio quando si stava peggio...
Ovviamente no. No, sono convinto che queste tecnologie siano effettivamente utili, solo penso che si dovrebbe essere cauti nel progettare un'applicazione web "one-page": le funzionalità del client, a mio avviso, dovrebbero essere soprattutto "cosmetiche", piuttosto che implementare da zero l'interfaccia, ed il cambiamento dall'interazione su una risorsa ad un'altra (ie. in un blog passare dal leggere un post ad un altro) dovrebbe modificare l'url della pagina, per rendere l'utente coscente del fatto che andrà ad agire su una risorsa diversa.
Per quest'ultimo punto sono combattuto: il fatto che, per cambiare l'url della pagina, attualmente non esista altro modo se non il ricaricamento della stessa porta alla conclusione che non si può utilizzare una chiamata ajax per ottenere lo stesso effetto. Vero. Ma è anche vero che ci possono essere degli "hack" che vengono in aiuto: ad esempio google maps non richiede, ovviamente, di ricaricare la completa pagina quando ci si muove nella mappa e fornisce, nella pagina, un link che riconduce allo stato della mappa in quell'istante.
Ok, quindi tutto questo che cosa ha a che fare con la millantata "eresia" del web citata nel titolo? Ci arrivo: abbiamo quindi visto che javascript stà assumendo un'importanza che fino a una manciata di anni fa nessuno si sarebbe aspettato (linguaggio con una sintassi strana, implementazioni buggate e soprattutto diverse, lentezza.. insomma, ne aveva --ed ha attualmente-- tante di rogne). Ma è l'unico che permette di agire nel client sulla pagina visualizzata (nativamente, in alternativa si potrebbe usare actionscript o java, ma non mi adentrerò in queste tecnologie). Ora, un'applicazione web tipicamente è implementata con un'architettura 3 (o N, in alcuni casi)-tier: il livello dei dati, quello della logica di business e la presentazione. Spesso quest'architettura è più o meno malamente integrata con un'architettura MVC (Model View Controller),
altri hanno già scritto su come dovrebbe essere un'architettura 3-Tier/MVC (personalmente ho preso in considerazione solo il paragrafo sull'architettura, il resto ha delle svistea mio parere piuttosto clamorose).
Tipicamente l'applicazione ha un database sul quale vengono salvate le informazioni sugli utenti, dati eccetera. Il livello applicativo, la business logic, è implementata con diversi linguaggi: PHP, .NET, Java, Perl, Python, Ruby (e tanti altri). Infine la presentazione tipicamente avviene con sistemi di templating per HTML (cose tipo mischiare HTML e codice o emettere HTML dal codice non le prendo minimamente in considerazione, e se state pensando di fare un'applicazione web non dovreste farle neppure voi!).
Ok, tutto è molto bello. Cosa succede però se cominciamo a mettere nell'equazione anche le chiamate asincrose da html? I framework web "di vecchia scuola" (anche detti "page-centric", ie. Struts e Spring-MVC) sono praticamente tagliati fuori, a parte alcuni tentativi per permettere l'iterazione con delle action, in ogni caso stanno venendo sorpassati da framework che agiscono direttamente sul client, mentre al server è demandato solo lo scambio di dati (tipicamente in formato XML o json).
Sembra un'ottima idea: risolve il problema di interazione tra pagine generate sul server e "tocchi" di pagina, sempre generati sul server, e riduce la complessità del codice sul server (che non deve più generare HTML).
L'idea meravigliosa, però, è la causa dei già citati problemi delle applicazioni web "single-page". Quindi non se ne esce? Riusciranno i nostri programmatori-eroi a creare applicazioni web che siano facilmente ed efficacemente fruibili ai naviganti, accessibili alle persone diversamente abili ed indicizzabili dagli stupidi spider di google?
Certo, è possibile. E' ovviamente anche lievemente perverso, ma seguite questa storiella: tu (si, proprio tu) vuoi fare un'applicazione web che permetta di gestire la proprio collezione di sacchetti antigelo del freezer. Cominci a progettare, fai il tuo bel database (ce ne sarebbe da discutere anche sul database, ma rimando ad un prossimo post), crei la logica dell'applicazione, diciamo in java (ma fosse php sarebbe uguale, e comunque anche sulla logica approfondirò in un prossimo post) e poi, siccome ti senti molto cool, crei l'interfaccia grafica in una sola pagina, con tutte le interazioni ajax-based. Va tutto molto bene finchè non ti arrivano email di collezionisti di sacchetti di freezer inca*ati perchè non riescono a scambiarsi i link delle rispettive collezioni e ti accorgi anche che google non indicizza nulla delle collezioni presenti. Mh, qualcosa va storto.
Ora, permettetemi di presentarvi
REST (Representational State Transfer), che non un'architettura di un sistema, piuttosto è una metodologia. Secondo i precetti rest ogni "risorsa" di un sistema è identificata da un URL. Per ora ci basta questo piccolo concetto, per un'analisi un pò approfondita seguite la wikipedia (anche se anche lì le idee sono forse un pò confuse).
Utilizzando il precetto rest, decidi quindi di suddividere quelli che sono i tuoi dati in "risorse": una risorsa è l'utente, subordinata ad essa ci sono la sua (per semplicità assumeremo che un utente abbia solo una) collezione di sacchetti per freezer e ovviamente sotto la collezione ci sono i singoli sacchetti.ah, e ci sono anche gli amici dell'utente. Ti ritrovi quindi ad avere uno schema di url fatto circa cosi:
- utenti
- myfreezer.net/{user}/
- collezione
- myfreezer.net/{user}/collection/
- sacchetto
- myfreezer.net/{user}/collection/{id}/
- siccome il sito è social, la lista degli amici di un utente
- myfreezer.net/{user}/friends/
Molto bene. Ora ogni risorsa ha il suo bel URL, ma perchè il trucchetto funzioni c'e' ancora bisogno di un paio di passaggi: in primis nella home page di myfreezer.net sar` necessario inserire la lista degli utenti (o almeno gli ultimi iscritti). Fatto questo ti renderai conto che siamo, in qualche modo, tornati un pò indietro: il server dovrà generare una pagina html per ogni risorsa. Vero, ma questo tipo di risorse non prevede e non necessita di abbellimenti o interazioni particolari: l'html generato per le risorse dovrebbe essere il più possibile scarno. Una cosa importante: per poter far funzionare tutto, in ogni risorsa si deve inserire un link alla pagina "applicazione" (o un redirect): una cosa del tipo "myfreezer.net/ajax/index.html?resource=myfreezer.net/cheng/collection". L'applicazione javascript deve controllare che nella request string ci sia l'indicazione della "resource" e modificarsi di conseguenza: nell'url che ho messo di esempio dovrebbe modificare l'interfaccia in modo tale da farmi visualizzare la collezione di sacchetti da freezer dell'utente cheng.
Qual'è il passo che molti, secondo me, ancora non hanno capito? la differenziazione tra i dati che vogliamo rendere accessibili e l'applicazione javascript. Nell'applicazione web di esempio, alla fine abbiamo reso disponibile il servizio in 2 modalità: una "pura" html, rest, in cui la navigazione è guidata solo ed esclusivamente tramite link (e form, per la modifica/creazione delle risorse), mentre l'altra ha una sfavillante interfaccia ajax. Fare solo una o l'altra oggigiorno non è abbastanza, almeno questa è l'opinione del sottoscritto.
Scriverò prossimamente sulla mia visione sui linguaggio per la logica di business e persistenza dei dati, fino ad allora spero di avere almeno messo il famoso tarlo nell'orecchio a qualche programmatore web.
Alla prossima!
cheng
