A quand de vraies architectures Stateless ?

HTML vient avec son lot de nouveautés mais une d’entre elle me fascine : le Local Storage ou la capacité qu’aura une application d’interagir avec le navigateur pour stocker sur le poste client de la donnée…

Dès lors et à l’instar d’un Gears, il sera alors possible d’interagir avec une base de données inclue dans le navigateur via des APIs fournies par le navigateur.

var database = openDatabase("Database Name", "Database Version");

database.executeSql("SELECT * FROM test", function(result1) {

   // do something with the results
   ...
   });
});

De prime abord, on se dit que ces évolutions sont là pour nous permettre de créer des applications Web pouvant fonctionner dans des contextes offlines. Mais parallèlement, le « Web Everywhere » se développe et, même en vacances, vos mails, vos feeds vous suivent et arrivent directement sur votre iPhone ou votre Android (la preuve, certains d’entre vous risquent de me lire les pieds dans le sable). Bref, on est tout le temps et « de partout » connecté – on peut d’ailleurs se demander si un prochain enjeu ne sera pas d’apprendre à se débrancher occasionnellement, mais c’est un autre débat – et le besoin d’application Web offline me parait de moins en moins évident. En revanche, ces technologies nous permettrons de créer des applications résiliente aux pertes de connexion, sur le modèle « flaky connection mode » de Gmail.

En complément, l’émergence de solutions comme Flex, GWT ou même simplement le renouveau de la technologie JavaScript a déplacé les problématiques de génération des IHM du serveur vers le client soulageant du même coup nos serveurs de cette « tâche ». Ces évolutions d’HTML5 s’inscrivent dans cette logique et permettront peut-être de réaliser de véritables architectures stateless.

Dans nos systèmes, on oublie souvent que nos architectures ne sont que trés rarement « stateless » du fait d’une session HTTP qui conserve des données, un état propre à un utilisateur ou à un contexte de navigation et qui est réutilisée entre deux requêtes HTTP sans besoin d’être persistée. Cette utilisation de la session peut devenir problématique dès que l’on regarde un peu les architectures physiques et les problématiques de « load balancing ». Peu d’architecture dans nos systèmes savent gérer une répartition de charge sans affinité de session : N requêtes issues d’un même utilisateur devront être redirigées vers le même conteneur de servlet. Et puis vient la nécessaire continuité de service : nous ne voulons pas (à bon ou mauvais escient) que notre utilisateur soit déconnecté en cas de problème. Alors, on rajoute quelque fois la réplication de sessions entre les différents noeuds du cluster…

Les plus malins (et c’est l’approche choisie par le Cloud) stockent les états dans des caches en backend, typiquement un memcached qui permet de stocker de façon performante ces informations et de les partager entre tous les serveurs. A titre d’exemple, GAE vous permet après configuration du appengine.xml d’utiliser les sessions mais ne vous garantit pas que deux requêtes issues du même utilisateur seront servies par le même serveur et l’implémentation de la session par GAE se fait au travers du App Engine DataStore et memcached.

Ainsi, la partie serveur d’application de votre backend devient réellement stateless tout en garantissant le fail-over et la continuité de service.

Mais revenons à HTML5 et au Local Storage. Et si cette API nous permettait de casser ces règles ? Imaginez un parc de navigateurs, tous équipés de ces mêmes APIs permettant de stocker de l’information (modulo peut-être les problématiques de sécurité de la donnée) directement sur le poste client. Pourquoi s’en priver ? Pourquoi ne pas soulager ou à défaut revoir l’utilisation des serveurs et des conteneurs Web en repoussant les données de session (celles qui concerne l’état de la navigation en cours) sur le poste client ?

Personnellement, je trouve cette option intéressante. Et vous ?