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 ?

6 commentaires sur “A quand de vraies architectures Stateless ?”

  • Au delà de trouver cette option intéressante, c'est surtout môsieur Fidling en personne qui le préconise depuis bientôt 10 ans (http://opikanoba.org/tr/fielding/rest/#sec_5_1_3) Il aura juste fallu du temps pour que les navigateurs supportent suffisamment de fonctionnalités pour nous permettent de respecter cette contrainte architecturale sans ... contrainte technique :)
  • Effectivement et je n'avais sincèrement pas fait le rapprochement. Reste que dans une architecture REST, le client n'est pas forcément le navigateur et que dans le cas du navigateur, je n'ai pas forcément une architecture REST. en fait nos archis sont aujourd'hui (et en général) stateless sur la partie service. c'est moins vrai sur la partie présentation qui demande de conserver un état propre au client. Il est vrai également que l'on croise qq archi où la partie présentation (en JS et donc sur le navigatuer) interagit avec un backend REST (un vrai, bien stateless comme il faut) :-).
  • Ce genre d'architecture devient possible avec des archis RIA. Maintenant, on va enfin pouvoir faire du RIA en javscript! Bon, c'est peut-être un peu tard et un peu compliqué mais bien sympa quand même. Normalement quand des frameworks qui génèrent du côté client (wicket, gwt) vont saisir cette opportunité, ça va tuer
  • j'auto-mets un bémol au propos ci-dessus : wicket est designé pour être stateful, ça ne sera pas facile de le rendre stateless
  • Passionnant ton article, un plaisir. Claire, court, 2 ou 3 idées qui s'enchainent parfaitement, et une idée pleine de promesse à la fin. Perfection Game 10/10 Le meilleur que j'ai lu chez vous depuis quelques temps. Pour le contenu tu n'es pas en reste. je rejoins ton idée sur la gestion de serveur sans état. J'ai eu l'occasion de réaliser des métrologies sur la plateforme Microsoft avec des phases de tir à charge maximale allant jusqu'à 100 000 utilisateurs en 4 h , et des affinités de sessions coté "Load Balancing" malgré le discours du prestataire. Mais pour ce qui de la sauvegarde coté client, des petits éditeurs s'intéressent de plus en plus à cette formule, je confirme ;-). J'aurai du plus souvent t'inviter à boire le café !
  • Il y a longtemps que long peu intérargir avec des éléments locaux au travers des applets ou des ActiveX. La sécurité sera t elle à la hauteur ?
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha