Il y a quelques semaines, j’ai rejoint l’équipe capitalisation d’Ippon. Dans ce cadre, je travaille sur une application ayant pour vocation de structurer un embryon de dictionnaire interne (a.k.a. Lexickr). Mon parti pris, pour cette application, est de sortir des sentiers battus, profiter de l’occasion pour tester certaines approches et technologies. L’objet de cet article est de vous exposer les grandes lignes qui sous-tendent son architecture et vous inviter à suivre mon cheminement dans mes prochains posts.
Qu’est-ce qu’une application Web aujourd’hui ?
Si votre problématique est de construire aujourd’hui une application web pérenne, comment vous y prendriez vous ? Quelles sont les contraintes que vous souhaiteriez dépasser ? Pour vous, quelles sont les applications qui tirent le web vers le haut ? Vos sources d’inspiration ? L’architecture idéale, c’est quoi ?
Autant de questions que je me suis posé pour poser les premières briques l’architecture de Lexickr. Malheureusement il n’existe pas de réponse toute faite à ces questions existentielles en dehors du très classique “ben, ça dépend”. Toutefois, étant bluffé par les innovations des grands fournisseurs de services web, ces dernières constitueront ma principale source d’inspiration. Comment font Google, Twitter et autres pour construire leurs applications ?
Ce qui est encourageant, c’est que quasiment toutes leurs recettes sont disponibles :
- Tiens, j’ai la nouvelle architecture de Twitter, t’en veux?
- La base de données de Facebook, Ok.
- La façon dont l’innovation est menée chez Google c’est par là, puis là et surtout là.
- Quoi, l’infrastructure d’Amazon!
Mais ces infos restent une matière première qu’il faut maintenant mettre en musique. Au travers du projet Lexickr, je vais proposer une partition en sachant que d’autres choix que ceux que je vais faire existent et sont tout aussi valables. Les objectifs de mon application en terme d’architecture sont donc de :
- découpler au maximum client et serveur
- développer un client AJAX sur une base HTML5 / full Javascript en utilisant, entre autres, les capacités de stockage du navigateur
- mettre en place une architecture REST/HATEOAS (Hypermedia As The Engine Of Application State) selon les principes de Webber et consorts
- déployer l’application sur la plateforme App Engine et profiter de son Datastore
- garantir la crawlabilité de l’application avec un système de templates utilisable à la fois côté client et serveur
- offrir une recherche full text sur les données de l’application
- mettre en place les nouveaux protocoles de sécurité du web dans les échanges avec le client et avec les applications tierces (OpenID et OAuth)
- mettre en place des facilités pour intégrer le service dans d’autres applications (e.g. l’intranet Ippon)
- interopérer avec quelques services de fournisseurs externes
Le fil rouge de ma réflexion tient à une intuition apparue depuis le talk plein de fantaisie de Fowler et Webber au QCon 2008 : “le Web est l’infrastructure”. Si je m’essaye à une rapide chronologie de l’architecture des applications d’entreprise, je dirai que le passage du mainframe aux architectures distribuées est survenu en même temps que le Web. Les applications d’entreprises se sont structurées autour des principes de l’architecture distribuée et plus spécifiquement celui des serveurs Java EE. A l’époque, le Web ne s’envisageait que comme un point d’entrée/sortie de l’application. Considérer le Web comme l’infrastructure d’une application d’entreprise c’est inverser cet état d’esprit. Cette nouvelle façon de concevoir les applications bouscule les schemas établis des développeurs Java en amenant les principes, les technologies et les contraintes du Web comme la colonne vertebrale de ces nouveaux développements et en transformant Java EE en boîte à outils de haut niveau.
Les développements pilotés par la simplicité
Cette reflexion est décrite sous des abords similaires dans le dernier post du touilleur-express. Article, références et commentaires très intéressants que je vous encourage à lire. Je rejoins donc complètement sa vision de l’architecture Web. Une idée forte qui émerge à mon sens de l’interview de Donald Ferguson, cité en référence, est la complexité du SI comme frein à l’innovation. Vouloir instaurer une culture de l’innovation sans considérer la complexité de son système d’information est un non sens (mesurable par la difficulté que peut rencontrer une équipe à le corriger ou à le faire évoluer). Pourtant, la capacité à innover d’une équipe est un avantage commercial/concurrentiel pour toute entreprise, si les capacités d’innovation sont mobilisées dans la gestion de la complexité alors elles sont réduites à néant (voir les liens précédents sur l’innovation chez Google). Ok, allons donc vers plus de simplicité !
Revenons à nos moutons. Lexickr vise à mettre en oeuvre le niveau 3 du modèle de maturité de Richardson (Fowler inside) en suivant au mieux les principes de l’HATEOAS (Hypermedia As The Engine Of Application State). J’essaierai dans mon prochain post d’expliciter comment, selon ces principes, HTTP n’est plus uniquement un protocole de transport mais également un protocole applicatif et le Web un gigantesque framework. Je me documente, expérimente plus avant et reviens donc vers vous tout prochainement.
Je terminerai avec une citation de William Gibson (via Tim O’Reilly (via Ryan Barrett)) que je voulais absolument caser quelque part façon Nicolas Hulot :
“Le futur est déjà là — il n’est juste pas très uniformément réparti”
à bientôt donc 😉
