Play 2.0 annoncé à Devoxx 2011

Guillaume Bort et Sadek Drobi ont annoncé mercredi 16 novembre deux nouvelles importantes lors de la conférence Devoxx 2011. Tout d’abord Play! 2.0 est disponible en bêta pour tester et découvrir le framework. En quelques heures, il y a eu plus de 4000 téléchargements (voir le twitt de Sébastien Creme). Ensuite, Play Framework devient officiellement la stack web de l’ensemble des solutions de Typesafe, la société créé par Martin Odersky, fondateur de Scala. Enfin une dernière nouvelle, Guillaume Bort rejoint aussi le Advisory Board de Typesafe aux côtés de James Gosling ou Doug Lea. Sympa non ?

Mais revenons à la présentation et à ce que j’en ai pensé. Je vous promets de rester objectif et de ne pas m’emballer (enfin pas trop).

Sadek Drobi est le CTO de Zenexity. Guillaume Bort est le co-fondateur de la société Zenexity. C’est aussi et l’auteur original de Play! Framework. Comme le dit Sadek, Play! est né tout d’abord d’un besoin interne, pour les clients de Zenexity. Un framework web simple, productif et complet pour construire des applications complètes dès le départ. Le framework est ensuite passé Open-Source, mais dès le départ ses racines sont construites sur des projets « de la vraie vie » comme disent les gens sérieux.

(Sadek with its hat and Guillaume)

Il y a deux ans Play! Framework était présenté dans une BOF. 2 ans plus tard, il a droit à 3 sessions et 1 B.O.F à Devoxx. Je regarde l’agenda mais je ne pense pas que d’autres frameworks Web ont eu autant d’exposition. Cela fait grincer des dents les copains, mais montre bien l’intérêt de la communauté pour l’outil.

Pourquoi Play 2.0 ?

A l’écoute des demandes d’amélioration depuis le début, Play 1.x est devenu en 2 ans un framework complet et populaire. L’ajout de fonctionnalités cependant ne doit pas se faire comme une course à l’armement. Il y a déjà beaucoup de choses un peu magique dans Play 1.x. Depuis 2008 l’architecture Web évolue aussi, avec petit à petit une prise de conscience sur ce que constitue une vraie architecture web par le monde de l’entreprise.

Play 2.0 vient aussi d’un changement de paradigme dans le Web. Nous sentons que les architectures évoluent en ce moment, et que cela aura un impact pour l’entreprise dans quelques années. Sadek et Guillaume expliquent que les premiers frameworks webs, et donc les premières architectures webs, étaient basé(e)s sur du contenu statique.Une bonne page générée par un script Perl, du PHP ou autre, cela fonctionne. Et cela fonctionne très bien lorsque votre besoin est statique.

Les architectures webs ont ensuite évolué vers le dynamisme. Par exemple le rafraichissement partiel d’une page web via Ajax a donné naissance à de nouveaux services comme GMail. D’une page statique, le rafraichissement partiel a apporté tout un lot de frameworks orientés composants, massivement statefull car représentatif de ce que voit l’utilisateur.

Aujourd’hui la demande est d’avoir des architectures d’intégration. Sur de nombreux produits, l’intégration de différents services Webs (API Twitter, OAuth2, Open-ID, Paypal, Github API, Google API…) créé le métier de l’application. Peut-être que demain un bon développeur Web ne sera finalement qu’un très bon intégrateur de différents services webs.

Techniquement, l’architecture des Servlets montre ses limites. On espère que Java EE 7 sera en mesure de proposer une alternative à l’approche assez simple des servlets (avec ou sans session). De la mémoire, des threads ou des cycles CPU… souvent il est difficile de configurer finement les services dans une application selon le métier ou l’usage. La page d’accueil prendra autant de mémoire que la page de tableau de bord de votre application… Les frameworks Webs ont été pensé comme étant le point central de l’architecture, alors que ce qui vous attend demain place plutôt le client au centre de l’architecture.

Le serveur devrait s’écrire avec un petit s et le Client avec un grand C.

Le volume des données, les cycles d’échange entre le Client et le serveur évoluent énormément. La gestion du code concurrent est un nouveau challenge, que Play 1.x ne peut résoudre correctement. Play 2.0 est né avant tout de l’observation de l’environnement, et des changements dans notre monde.

Sadek explique aussi que le le choix d’un datastore doit faire l’objet d’une vraie réflexion. Pourquoi prendre systématiquement une base relationnelle et utiliser un ORM ? Dans le monde Java, j’ai l’impression que nous sommes parfois victime d’un biais cognitif appelé « conditionnement mental« . Si vous n’avez pas entendu parler de l’expérience des singes et des bananes, prenez le temps de lire l’article sur Wikipedia.

Cela répond à certains problèmes. Pas à tous les problèmes. Regardez votre application et dites moi honnêtement si par exemple, le relationnel est bien utilisé dans votre base ou non ? Première réflexion donc : pour un framework Web sur la JVM, l’approche base de données relationnelle ne doit pas être systématique. Sinon elle ne peut prendre en compte facilement les modèles non-relationnels.

Côté client, nous avons aussi accès à de nouvelles technologies afin de faciliter l’écriture d’une application web, comme Sass, CoffeeScript, Less ou jQuery par exemple.

Il y a aussi des changements dans le volume et la gestion des flux de données. Côté serveur, l’écriture du code dans le controller doit permettre demain de s’adapter à différents Clients. Le navigateur web certes, mais aussi les flux de données via les APIs Web comme Twitter, RSS, FlickR, etc.

Le point de départ de Play 2.0 finalement c’est cette volonté de pouvoir s’adapter à de futurs usages et de proposer une architecture en rupture avec les usages actuels. Ce qui me fait penser que Play 2.0 ne sera pas adapté à l’ensemble des problèmes et des besoins actuels.

Lorsque l’on doit présenter Play en quelques minutes, les premières caractéristiques sont ce que Sadek appelle « Fast turnaround ». Vous écrivez votre code dans un éditeur, vous basculez dans votre navigateur, vous rechargez la page et cela fonctionne : code compilé, session conservée, donc productivité augmentée. Play 2.0 conserve ce côté productif avec Java et Scala. Guillaume voulait aussi conserver l’idée d’un framework fullstack : compilation, déploiement, tests, emails, services webs, cron-job. Bref un vrai framework Web. Enfin les principes venus de Django ou Rails, qui ont fait aussi que Playa été adopté par des non-javaistes, reste dans Play 2.0.

Il sera possible d’avoir des méthodes non static dans le Controller pour la partie Java au fait.

Démonstration

Guillaume a ensuite fait une démonstration de Play 2.0. Pour commencer, dans Play 2.0 il y a 2 langages qui ont été retiré : le tooling Python et le langage Groovy pour les templates. Le coeur de Play 2.0 est en Scala, comme les templates pour la vue. La partie controller/model est en Java ou Scala, selon ce que vous souhaitez faire. Java est proposé avec Avajé EBean un ORM léger et du côté Scala, le moteur d’accès à un datastore est Anorm (inventé par Sadek). A noter que du côté Scala vous pouvez utiliser d’autres moteurs comme ScalaQuery car il n’y a rien d’imposé.

L’ensemble du coeur de Play est basé sur l’outil SBT. SBT c’est Simple Build Tool. Un bon article sur le blog de Xebia de Romain Maton vous explique que SBT offre de base tout ce qui est compilation, tests, gestion des dépendances avec Apache Ivy ou Maven, packaging, gestion de la documentation etc. Play ajout ses propres commandes SBT, qui d’ailleurs sont faciles à étendre. Les commandes Python sont remplacés par la puissance de SBT. Vous pouvez aussi utiliser SBT et faire tourner par exemple une fonction de votre controller dans la console SBT, ce qui aura pour effet d’afficher le HTML généré… Bref si vous aimez SBT, vous ne serez pas dépaysé. Au passage on a aussi via SBT la génération du projet au format Eclipse ou IDEA IntelliJ.

Pour la partie template, pourquoi passer de Groovy à Scala ? Tout d’abord il y aura un support de l’ancien format des templates, mais ce ne sera plus géré comme le coeur de Play 2.0. L’un des committers de Play 1.x travaille sur ce sujet. Ensuite ce qui change vraiment c’est le typage fort des templates. Vos vues doivent maintenant déclarer les paramètres utilisés. Guillaume Laforge a parlé de la possibilité de renforcer le typage dans Groovy, ce qui est intéressant.

Pour écrire ces templates vous n’avez pas à devenir une brute en Scala. Loin de là. Vous apprendrez en fait à faire un peu de Scala petit à petit, ce qui vous donnera l’envie j’en suis certain de regarder ensuite le langage.

Par exemple voici un bout de code que j’ai écrit. Il permet d’itérer une liste de noms et de regrouper par lettre l’ensemble des contacts. Tous les A… tous les B… le tout avec très peu de code :

Play 2.0 en détail

Sadek explique ensuite le changement majeur dans le coeur du framework Play. Pour reprendre par exemple l’image d’un navigateur web qui envoie vers le serveur un fichier, les solutions actuelles en Java basées sur InputStream sont dépassées. Et ensuite, elles sont bien trop basses pour être adaptées à ce que le Web peut réellement faire. La méthode read() d’InputStream lit octet après octet et peut se mettre à bloquer lorsque d’autres données ne sont pas disponibles. Sadek, qui est aussi un développeur qui vient du monde Haskell, explique alors qu’ils ont adapté le principe « Enumerator and iteratee » dans Play en utilisant Scala

Play 2.0 innove en appliquant un principe d’inversion de contrôle sur la gestion de l’échange entre le client et le serveur. Ce qui suit se passe dans le coeur de Play, une fois la connexion du client acceptée. Pas entre le navigateur et le serveur. Sadek appelle cela la programmation réactive et j’ai trouvé cela vraiment passionnant. Ce principe fonctionne sur le pattern suivant : un Enumerator se contente d’envoyer des données à un Iteratee. L’Iteratee exécute une fonction et devient capable de signaler à l’Enumerator lorqu’il a terminé de traiter les données. Dit autrement, c’est assez bien expliqué dans un livre sur Haskell, lisez « Continuation passing style« .

Pourquoi tout ceci est intéressant ? Ces idées permettent d’avoir un serveur complètement sans état, avec une approche très fonctionnelle dans son traitement. Si vous avez fait un peu de programmation fonctionnel, j’imagine que vous comprenez où le coeur de Play 2.0 s’est placé. Pour orchestrer cela, Sadek et Guillaume ont implémenté le tout avec Akka. Oui monsieur, tout simplement.

Akka est un moteur d’acteur qui permet d’écrire du code concurrentiel vraiment facilement. Dès que vous voulez faire de l’asynchrone et du code scalable, c’est une solution très simple et intéressante.

Voici un exemple tiré de Play 2.0. La fonction search reçoit un mot clé à chercher. Pendant qu’une autre partie de votre application effectue la recherche, Play va libérer la Thread du client qui a demandé la recherche. Sur le principe de l’Iteratee, lorsque le résultat sera disponible, la page « results » est envoyée au client dans une autre Thread. Le double point d’exclamation (bang-bang) veut dire : envoie « keywords » à l’acteur searchInternet.

def search(keywords: String) = Action {
	 AsyncResult { 
		(searchInternet !! keywords).map{
			found => Ok(html.results(found))
		}
	}
}

Sadek et Guillaume ont ensuite parlé de la gestion des données : base de données ou bases no-sql comme MongoDB. Play 2.0 n’essaye pas d’abstraire le modèle de vos données, surtout dans la version Scala. Si vous voulez utiliser Neo4J ou PostgreSQL, finalement vous serez assez prêt du métal comme on dit.

Pourquoi avoir abandonné Hibernate 3 ? La difficulté a été en fait de mettre en place ce système purement fonctionnel et asynchrone, et le fait qu’Hibernate est efficace avec une Session. L’usage d’Hibernate dans Play 1.x était déjà un peu différents des usages classiques. Et finalement, Play 2.0 n’utilise pas ce que peut faire Hibernate. Donc après plusieurs essais, Guillaume s’est intéressé à EBean. Moins puissant mais plus adapté aux besoins de Play 2.0.

Guillaume a aussi montré que Play 2.0 est livré de base avec le support de technologies comme Less, CoffeScript ou SASS. Si vous faites une erreur dans un script CoffeeScript, Play peut vous reporter l’erreur avec la même interface que celle utilisée pour le contenu web ou le code. J’en ai un peu discuté avec Mathilde Lemée qui me disait que sans cela, CoffeeScript était assez pénible à utiliser. J’espère que le nouveau moteur de reporting d’erreur l’intéressera aussi.

Enfin, et là pour l’instant on est encore un peu dans les trucs croustillants, Play 2.0 est déjà disponible sur des plateformes comme Heroku. Malheureusement en raison de l’enregistrement des CastCodeurs, nous avons loupé la killer-demo de James Ward… Il parait que la salle était assez bluffée.

Grâce à Akka il sera aussi facile de distribuer les traitements de votre application web, via de la configuration. Je ne sais pas si vous réalisez très bien. Vous voyez le code avec la fonction de recherche que je vous ai montré ? Et bien imaginez que demain, via un fichier de configuration, il sera possible de dire que l’Actor « searchInternet » est constitué par un cluster de 10 machines. Akka se chargera de distribuer le boulot et de vous redonner le résultat. Donc je ne sais pas si vous voyez (deuxieme fois) mais cela permettra d’avoir un code métier facilement testable avec disons 2 ou 3 threads, mais capable d’être déployé sur un méga cluster de cowboyz. Vous voyez ? (troisième fois)

Le coeur du framework est assez léger. Guillaume montre qu’un test sur un MacBook Pro i7 avec 8 core encaisse 40 000 requêtes par seconde. Et l’empreinte mémoire après le test de charge n’est que de 2MB… Ce serait intéressant de reparler du challenge USI, des choix de JBoss Netty par les gagnants, coeur de Play depuis 2 ans…

Le typage fort

Play 2.0 apporte aussi un typage fort, qui peut être inhabituel lorsque l’on est habitué à une approche type script. Les templates HTML sont compilés vers du Scala, puis du bytecode. Honnêtement même sur mon MacBook Pro c’est poussif par rapport à la version de Play 1.x. Le coeur est basé sur Scala 2.9.1.

Le fichier « routes » qui permet de définir le binding entre les requêtes et les actions de vos controllers est aussi compilé. Ce système est en fait très pratique. Si par exemple vous changez le nom d’une action, alors Play 2.0 vous signale immédiatement ce souci. En fait, il devient impossible de créer un lien cassé dans votre application web. Typage fort, compilation, tout ça.

Guillaume a enfin montré 3 applications, écrites à chaque fois en Java et en Scala pour montrer les différentes approches. De base, vous avez une application type CRUD avec pagination, interface sympathique etc. Pour le HelloWorld je suis content car Guillaume a prit une idée discutée ensemble en septembre. Je lui disais qu’à chaque fois, les frameworks Webs font un HelloWorld naze et un exemple de réservation de chambres d’hôtel spécial DSK. Et c’est has-been. Autant que le PetStore.
Du coup, dans Play 2.0 l’application HelloWorld est un poil plus avancé. Elle montre différents cas d’usage très courant. Bref contrairement à un site de vente d’animaux par Internet (quel blague quand même) les exemples dans Play 2.0 sont réalistes.

Ce qui va fâcher certains

Là cher lecteur, je sors les lunettes et je prends un air sérieux. Il va y avoir de tels changements qu’il ne me semble pas envisageable de migrer une application Play 1.x vers Play 2.0. Première chose : toutes les pages en Groovy ne marchent pas pour l’instant. Deuxième chose : le code de la partie Controller est différent. Bref pas de migration path automatique ou de rétro-compatibilité.

Première information très importante : Play 1.x va continuer à être maintenu, avec la possibilité d’avoir du support de sociétés comme Lunatech ou Zenexity. Il y a de nombreux clients en production avec du Play 1.x. Il n’est donc pas question d’arrêter Play 1.x.

Deuxième chose, si vous regardez Play 2.0 vous comprenez que c’est un nouveau framework, un cousin de Play 1.x plutôt qu’une évolution. Il est adapté à de nouveaux usages et à une nouvelle approche.

C’est pourquoi on a presque envie de l’appeler Play² (prononcez [plèy square kioubeu]

Articles similaires:

Play 2.0 announced at Devoxx 2011 Devoxx 2011 Devoxx 2011 : de la couleur du papier à des informations croustillantes Devoxx 2011 : Android