HTML5 storage: rendere i dati persistenti lato client

In questo articolo vedremo quali funzionalità offre HTML5 per permettere lo storage di dati lato Client. Vi sono diverse  ragioni per utilizzare uno storage lato client: la prima è che così facendo possiamo permettere ad un utente di continuare ad usare una Web App anche quando è offline, sincronizzandola poi quando egli ritornerà connesso, la seconda è che così possiamo migliorare le performance della Web App, conservando quelle informazioni che sono per lo più statiche all’interno del Client, evitando quindi inutili download.

La persistenza dei dati è stato il tallone di Achille delle Web Application rispetto alle Applicazioni Desktop native, in quanto queste ultime possono utilizzare le funzionalità offerte dal S.O.. Il S.O. offre un livello di astrazione per le applicazioni che devono accedere al File System locale di ogni macchina, consentendo una più facile gestione dei dati. I dati possono essere archiviati nei più disparati formati: in file .INI o .properties (utili soprattutto per programmi Java), in file XML  o in database SQL.

Nel tempo sono stati utilizzati vari meccanismi per consentire di conservare dati lato Client per una Web Application; uno di questi è l’uso dei Cookies. Questi permettono di conservare delle coppie Chiave/Valore che sono persistenti sul Client per tutta la durata della Sessione di una Web Application e anche oltre. Presentano però almeno due grossi svantaggi:

• devono essere scambiati tra Client e Server (vengono inclusi in ogni richiesta HTTP);
• sono limitiati a 4 KB di dati.

Nel 2007 Google lancia un plugin Open Source per i browser (preinstallato su Chrome) dal nome Gears, che forniva (il progetto è stato deprecato) una API per un database interno SQL basato su SQLLite; dopo aver chiesto consenso all’utente, Gears poteva archiviare un quantitativo illimitato di dati per un singolo dominio in tabelle SQL. Anche Adobe introdusse una feature in Flash 6 che consentisse l’archiviazioni di dati lato Client chiamata Local Shared Object o brevemente LSO. Questa tecnologia permetteva di archiviare fino a 100KB di dati per singolo dominio.

Esistono poi varie implementazioni di framework Javascript che hanno cercato di introdurre delle API per lo storage. Una delle più famose implementazioni fu quella introdotta nel Framework Dojo, tramite il set di API note col nome di dojox.storage che forniva una API unificata per interagire con tecnologie quali Gears, LSO  e altri prototipi pre-HTML5.

In HTML5 abbiamo invece una serie di tecnologie ed API che ci permettono di archiviare i dati lato Client:

• Web Storage: fornisce una semplice interfaccia per memorizzare dati secondo un mapping chiave-valore; ad esempio posso salvare una username con localstorage[“name”] = username; sfortunatamente è possibile salvare solo dati in formato Stringa, di conseguenza bisogna serializzare e deserializzare eventualmente gli altri tipi di dati. Otteniamo ciò utilizzando i metodi JSON quali stringify() e parse();
• Web SQL Database: fornisce tutte le funzionalità di un database relazionale SQL; possiamo dunque utilizzare le tipiche operazioni CRUD in standard SQL;
• Indexed Database: è un qualcosa che si pone tra il Web Storage e il Web SQL Database: è essenzialmente un mapping chiave-valore ma viene supportata l’indicizzazione come avviene per i database relazionali. La ricerca di un particolare campo è molto più veloce perchè non bisogna iterare lungo tutti gli oggetti presenti nello store (come avviene per il Web Storage);
• File API: è una API che serve per leggere il contenuto dei file in JavaScript. Dato un insieme di file che l’utente ha aggiunto tramite un input type di tipo “file” (tramite dunque un upload), è possibile leggere il contenuto dei file e se è una immagine è possibile anche mostrarla.

Analizzeremo in una serie successiva di articoli ognuna di queste API.