oct.
2010
Play Framework : symphonie technologique ou solo de pipeau ?
J'ai assisté avec grand intérêt à la présentation de Play! Framework par Guillaume Bort, concepteur du framework, et Nicolas Martignole, auteur du Touilleur-Express. La conférence était sympa et assez rafraîchissante, merci donc à Nicolas et Guillaume.
Pour ceux qui ont raté l'événement, je crois que vous les reverrez rapidement dans la plupart des conférences en France et chez nos voisins.
Présenté comme un framework hyper-productif, Play! propose un modèle de développement tout-en-un à la Grails : les couches DAO, service, et présentation sont préconfigurées. Même le compilateur est fourni : il suffit d'écrire le code, et Play! le compile et le charge à la volée (grâce au compilateur Eclipse intégré).
La démonstration effectuée lors de la conférence est assez bluffante, il faut avouer : une ligne de commande à la Spring Roo permet de créer un nouveau projet, de le configurer, et de le lancer localement ; ensuite, quelques classes représentant le modèle métier sont codées, ainsi qu'un contrôleur gérant l'affichage et les opérations CRUD. Le tout, dans un simple bloc-notes, Play! se chargeant de compiler/débugger/charger le code. Temps total de mise en oeuvre : 10 minutes, c'est bien sympa pour du prototypage dynamique.
Guillaume insiste sur plusieurs points d'architecture :
- Play! ne s'appuie pas sur l'API Servlet, il intègre son propre serveur HTTP.
- Play! promeut l'approche REST et se revendique stateless. Pas de session côté serveur !
- Retour aux racines du web : afin de rester le plus proche possible du web pur et dur, Play! ne fournit que les contrôleurs et ne se préoccupe absolument pas du rendu graphique ; c'est donc au programmeur d'utiliser les bonnes vieilles technologies du web que sont HTML, CSS et Javascript. Pour le binding des données et le templating, c'est Groovy qui est utilisé (à la Grails).
Bon, pourquoi pas, ça a l'air "light" en effet. Mais...
Mais...
Après ce "Mais..." très cliffhanger-esque, une petite pause pour placer un disclaimer :
Disclaimer, donc : je n'ai pas encore utilisé Play!, mais j'ai lu la documentation et assisté à des présentations. Les réflexions suivantes sont uniquement basées sur des impressions personnelles et la comparaison avec d'autres technologies. Je peux donc me tromper lourdement, me fourvoyer, me placer la phalange dans l'orbite, mais seuls ceux qui ne s'expriment pas ne disent jamais de bêtises :)
Mais... mais en creusant un peu, certains points me font froncer les sourcils.
- Pas d'API Servlet ? Pourquoi tourner le dos à une API certes vieillissante mais qui reste malgré tout standard, robuste et universellement supportée ? Quel est le gain réel, sachant que dans la plupart des frameworks modernes, la seule adhérence à cette spécification est un simple filtre à déclarer (Spring MVC, Wicket, Stripes...) ? Sans l'API Servlet, comment bénéficier déclarativement de la sécurité et de l'import de ressources JNDI ?
- L'approche REST est séduisante mais se heurte à de nombreuses limitations. Par exemple, il m'est déjà arrivé de devoir abandonner GET au profit de POST, pour récupérer une ressource sécurisé : le token de sécurité ne tenait pas dans l'URL. Une approche full-REST ne me paraît donc pas forcément adéquate dans des cas non triviaux.
- Pas de session ? Guillaume explique que les données simples peuvent être stockées côté client sous forme de cookies ; les serveurs peuvent alors êtr eréellement stateless et scaler linéairement. Mais un cookie ne peut contenir que 3ko d'informations, ce qui est ridicule pour toute application d'entreprise. Guillaume admet que dans ce cas, il faut alors mettre en place un cache distribué. Ah, il y a donc bien une session côté serveur alors ? Sauf que, au lieu de laisser l'API Servlet gérer ça de manière transparente, c'est au développeur de réinventer la roue et de se préoccuper de la gestion des données, du clustering du cache, etc. Merci le framework.
- Quant à la partie graphique, ma perplexité atteint des sommets. S'il est aussi important que cela de laisser le développeur maîtriser son code HTML (et je ne peux qu'approuver), pourquoi avoir choisi un système de tags Groovy, qui destructurent le code, plutôt qu'une approche tout-HTML à la Wicket ? Les Groovlets ne permettent pas de prévisualiser les pages, ni de travailler de manière transparente avec une équipe de designers (et pour ceux qui douteraient ce l'existence de telles équipes, oui, j'ai déjà travaillé dans cette configuration chez un client).
- Enfin, le fait de pouvoir éditer le code à la volée ne me paraît pas un avantage. Les intervenants étaient visiblement très enthousiastes de pouvoir coder dans Notepad plutôt que dans un IDE digne de ce nom ; de mon point de vue, c'est une hérésie. Sur nos machines de développement, des IDEs sont installés ; et sur toute autre machine (serveur de production, machine d'un utilisateur...), il me paraît dangereux de pouvoir éditer le code à la volée. On a vu suffisamment de projets PHP pérécliter à cause de modifications sauvages... De plus, je détecte ici un cas aigü de schizophrénie : les mêmes qui crachaient sur les JSPs reviennent maintenant nous vanter les mérites de fichiers de script à base de tags et éditables à la volée...
Bref, on l'aura compris, l'architecture même de Play! me rend sceptique.
Mais encore...
Il y a certes de bonnes idées, et la démonstration faite au JUG était impressionnante en termes de rapidité de mise en oeuvre... pour une application triviale. Je me demande ce que cette technologie vaut dans un environnement réaliste avec gestion de la sécurité, de l'I18N, l'intégration avec d'autres systèmes préexistants (LDAP ?), la nécessité de tuner finement des caches de données...
De plus, si l'on considère que le coût de démarrage d'une application (mise en place de l'infrastructure, etc.) est négligeable par rapport à son coût de développement, qui lui-même ne représente qu'un fragment du TCO, je me demande si Play! adresse les bonnes problématiques.
Enfin, je crains qu'un certain effet d'enfermement et de sur-spécialisation ne se fasse sentir sur les développeurs : en utilisant des stacks techniques pré-intégrées, ne font-ils pas l'impasse sur la montée en compétence sur frameworks qui la composent ? Je rappelle qu'aujourd'hui, un développeur Java non-junior sans connaissances minimales sur Spring et Hibernate est virtuellement inemployable.
Je répète ici mon disclaimer : je n'ai pas encore utilisé Play!.
Je pose juste les questions qui me brûlent les lèvres, et les interrogations qui me malaxent la cervelle.
On me dira sûrement que de nombreux projets utilisent déjà ce framework avec succès ; peut-être, mais les EJB 2.x aussi ont eu leur heure de gloire.
On me dira que je suis rétrograde et réfractaire au changement ; sans doute, mais que j'ai vu de nombreux projet "révolutionnaires" se casser la figure et sombrer dans l'oubli, alors je reste prudent.
On me dira que je parle d'un produit sans avoir testé. C'est vrai, mais cela n'empêche pas de poser un regard critique sur son architecture.
Mais pourquoi pas en fait
J'essaierai Play! si j'en trouve le temps, car j'aime bien garder un oeil sur les technologies émergentes. On ne sait jamais. Et il y a sûrement plein de use-cases où ce framework peut se révéler intéressant, je pense à du prototypage notamment (je sais, je sais, on fait aussi des applications "sérieuses" avec).
En attendant, si vous pouvez éclairer ma lanterne sur les points que j'ai cités, dans un dialogue calme et constructif, je suis preneur - le débat est toujours souhaitable !
Commentaires
Hi hi hi, ça fait bien longtemps que je rigole sur ces questions même si comme toi je n'ai jamais utilisé le framework. Mais il n'est pas nécessaire d'utiliser un framework pour comprendre les fonctionnalités mises en avant et les comparer à tes attentes venant de ton expérience. De ce côté-là, soit Play! ne répond pas bien à ces questions, soit Play! a tout simplement une approche biaisée dans son architecture. Je vote pour la deuxième solution au moins pour le coup du stateless qui est pourtant le premier truc mis en avant.
"Han, il a craché dans la soupe!!!" "Mais pourquoi pas, si ca lui donne du gout!"
Tu peux utiliser POST avec Play!
Je partage mon étonnement de ne pas utiliser l'API Servlet, mais alors pourquoi ne pas la proposer en option et ainsi pouvoir utiliser simplement, Spring Security, l'exposition des services etc...
Mais pour l'avoir utilisé, je peux affirmer du gain de productivité... Je n'ai jamais eu un rendu concret aussi rapidement!
Salut Olivier,
Effectivement tu poses beaucoup de questions qui n'ont pas été abordées dans la présentation au Paris JUG, et je comprends tes doutes.
Pour répondre à certaines de tes questions, voici comment je peux répondre de part mon utilisation de Play!
- Pourquoi pas de Servlet ? Question très importante. Guillaume a répondu ici : http://iam.guillaume.bort.fr/post/5...
- Pas de session : Play! intrègre une gestion de cache native. Il n'y a pas besoin de redévelopper un cache. De plus si tu as une gestion de cache déjà existante avec Ehcache par exemple, il suffit de déclarer dans le fichier de conf de Play! où se situe ton fichier de conf Ehcache, et ton application utilise ton cache de manière transparente, sans changer une ligne de code.
- L’édition de code à la volée ne fonctionne qu'en mode DEV. Dans le fichier de conf de Play! tu dois passer en prod PROD et ceci interdit notamment la compilation à la volée.
Bon, j'espère n'avoir dit aucune bêtise, dans ce cas que l'on n'hésite pas à me corriger ! Je laisse les experts Play! te répondre sur la partie tags notamment.
Ciao !
La RFC du HTTP ne pose aucune limite sur la longueur des URI, et on peut mettre les en-têtes qu'on veut dans un GET, y compris les tokens de sécurité si on ne veut pas les mettre dans le path.
Sinon, 1274 mots sur un outil que tu n'as jamais essayé, ça fait un joli solo de pipeau :)
Merci de vos commentaires, c'est intéressant.
Encore une fois, j'assume le fait de n'avoir pas encore utilisé le produit, mais cela ne m'empêche pas d'avoir un avis argumenté.
Par contre, si j'apprécie le débat contradictoire, j'aime bien savoir à qui je m'adresse. "Visiteur" aurait pu s'identifier... "C'est fou le nombre d'étourdis qu'il y a parmi les gens courageux" :)
Pour répondre à une autre question que tu as posée, le i18n est supporté. Et de manière assez élégante :
dans les pages, tu utilises le tag "&{'cle'}", et le texte est rendu en version intenationalisée à partir des classiques fichiers properties.
Pour changer la langue d'un utilisateur (et les rendus correspondants), il suffit d'appeler la méthode statique (comme très souvent en Play) "Lang.change("en");"
Le java, c'est comme les jupes ca suit la mode.
Une année, c'est la mode des jupes longues : on met en avant les interfaces riches et le respect des standards. En ce moment, c'est la mode des jupes courtes : architecture légère, ultra-productive, rien en session et surtout plus de tags malheureux !
HTML 5 avec le web storage permet de passer outre la limitation des cookies (supporté dans tous les navigateurs récents .. même IE 8)
Par contre les données ne sont pas transférées automatiquement au serveur (en gros il faut l'envoyer à la main en javascript ;) )
Merci pour cet article, si Play commence à avoir des "détracteurs" c'est que sa popularité croît ;)
Pour ma part je me suis pas mal amusé avec ce framework, et j'en pense beaucoup de bien.
Florian a bien répondu je pense à pas mal des interrogations soulevées dans ce post (commentaire #3)
Pour ce qui est du déploiement à chaud du code, en mode dev c'est vraiment un gain de temps incroyable. Ok on peut arriver à la même chose avec des appli standards, des servlet et un tomcat avec des outils comme JRebel, mais là c'est "out of the box" et ça marche du tonnerre.
Sinon pour les pages à la jsp plutôt qu'un wicket-like, là c'est une question de goût, mais le système de template de play! est quand même beaucoup plus sympa et puissant que jsp,
et pour avoir fait pas mal de wicket (que j'aime beaucoup par ailleurs) je ne suis pas que qu'il soit plus simple de maintenir des pages avec ce dernier (et puis avec wicket on écrit tout en double, html+java).
Et l’intérêt par rapport à un système de balises custom à la jsf c'est qu'avec du vrai html on s'interface plus facilement avec des librairies comme JQuery, et c'est comme ça que play est pensé. Les composants graphiques sont à construire avec des standards du web, non en java .
Un dernier mot sur le stockage de la session, je pense que play trouve toute sa puissance avec html5 et le localstorage. Là aussi en s'appuyant sur des (futurs) standards du web on arrive à quelque chose de puissant.
salut,
Oui merci pour cette article. Tant mieux si Play agace. Je dois dire que je ne vois pas complètement l'avantage sur un jax-rs (voire un spring3) bien configuré. Au moins on n'a pas la couche jsp/groovy.
Pour dire vrai, je pense que ce qu'on reproche à Play! souvent c'est ce qu'il cultive. Les méthodes statiques, le rest, l'intégration profonde avec le compilo, l'utilisation de Mina (et maintenant Netty) au lieu des servlets...
Autant de choix qui sont fait pour moi et ça m'agace un peu
Maintenant... Play! justement est un framework fullstack. Il a les défauts de ses qualités.
Il est productif et facile à prendre en main? Mais comment on fait si on veut yahooUI à la place de JQuery? Ou si on veut maintenir et faire évoluer la base de frameworks. Comment va vieillir une application Play ?
Play est orienté rest? C'est un choix (que je partage++). Pour une application Web ce choix est parfaitement compréhensible (voire presque obligatoire). Pour une appli de gestion qui va devoir gérer de la synchro sur une grosse grappe d'objets... Mouais c'est surement faisable mais est-ce facile et simple, je veux dire ici et maintenant?
Quand on aura un beau framework javascript/rest qui gérera les merge et les update en une ligne de code (voire en zéro).... Pouruqoi pas.
Mais pourquoi ne pas simplement utiliser un framework Stateful qui te fera tout le boulot? Si tu n'as pas spécialement besoin d'une scalabilité phénoménale, une approche non-rest se défend très bien.
Play! est un sacré marteau, mais est-ce que tout est un clou?
Ceci dit, il faut aussi être très très clair, Play! est un foutu morceau de belle techno, on a la chance que les créateurs parlent la langue de Molière, on a la chance d'avoir des gens qui ne vont pas dans le même sens que tout le monde, et qui font vraiment des choses, avec leurs petites mains. Donc, un grand bravo! (un bravo un peu jaloux :) .. well done guys)
@Gabriel :" comment on fait si on veut yahooUI à la place de JQuery?"
Aucun problème pour ça, tout est fait pour qu'il n'y ait pas d'adhérence à un framework JS.
"Pour une application Web ce choix est parfaitement compréhensible (voire presque obligatoire). Pour une appli de gestion... c'est surement faisable mais est-ce facile et simple"
C'est vrai tu as raison mais c'est clairement l'orientation de Play, faire du pur Web. Pour des appli très orientées manipulation de données métier complexes il ya tout un tas d'autres frameworks (statefull justement) bien rodés...
"Play! est un sacré marteau, mais est-ce que tout est un clou?"
C'est clair on est d'accord, c'est un peu le problème, on peut critiquer play pour ne pas répondre de manière pertinente à tous les besoins, mais ce n'est pas son but finalement.
En tout cas je suis bien d accord pour dire que c'est une belle techno, et je prend beaucoup de plaisir à développer avec cet outil.
Sinon pour répondre aux interrogations d'Olvier, l'intégration du i18N, et de la sécurité se fait sans problème (voir http://coffeebean.loicdescotte.com/... )
Pour LDAP, il y a aussi un module (et il y en a plein d'autres, oAuth par exemple).
Des interrogations qui ont raison d'être soulevées, surtout si on n'a jamais utilisé Play! S'interroger là dessus prouve qu'on ne fait pas un choix sur des tendances, mais sur des bonnes raisons. Merci Olivier d'être notre garde fou ;)
@"Visiteur"
La RFC n'indique pas de limite, ça ne veut pas dire qu'il n'y en a pas dans la réalité! IE, Opera, Firefox ont tous des limites et elles sont toutes différentes!
Certes, c'est bien de reconnaître ne pas maîtriser le sujet dont on parle, mais c'est encore mieux d'attendre de le maîtriser pour en parler.
Certes, c'est agréable de savoir le prénom de la personne à qui on répond, mais encore faudrait-il lui répondre quelque chose.
Et certes c'est bien de lire du Desproges, mais quand on prétend faire une telle analyse technique, il faudrait peut-être aussi lire quelques docs et RFCs.
Pour répondre à la question que tu te poses, je suis un simple promeneur, tombé sur ce billet par hasard. Je ne suis aucunement lié à Play!, que je n'ai jamais essayé et qui m'intéresse moins que ma première chaussette. Ma démarche est positive puisque je veux simplement te signaler que la RFC répond à des questions que tu devrais te poser, et que aurais mieux utilisé ton temps en testant l'outil dont tu parles, plutôt qu'en pondant ce billet :)
pour Visiteur ( aka Robert)
Même si la RFC permet une longueur illimité aux URI, les implémentations dans les navigateurs et serveurs peuvent varier ( d'ailleur dans la configuration du serveur web de Lotus Domino il est possible de changer cette longueur et la taille des requêtes post)
Pour l'article de Guillaume sur le choix de ne pas avoir de servlet, la phrase " Everyone agree on the fact that it is the worse HTTP API ever conceived. " mérite plus d'explications ..
Pour la nécessité de maitriser le code html : +1, c'est un vrai problème.
Ensuite, pour avoir essayé play, rien que le fait d'avoir en 10mn des tests u, des tests selenium, du reload à chaud, son code source ou l'on voit l'erreur, un framework js fournit, une appli petshop like qui montre des exemples .. eh ben ça fait plaisir !!
PS : je retourne à mon JSF :(
Nicolas a raison concernant la RFC et les défauts d'implémentation possibles dans les différents navigateurs. Mais il faut toujours s'attacher à corriger le bon outil, plutôt que propager les mauvaises conceptions à l'environnement. C'est vrai que lire que "REST n'est pas approprié en dehors des cas triviaux" simplement parce que un navigateur était buggé, ou le token inutilement long (> 2ko ?), ça peut faire douter de l'expertise de l'auteur sur le sujet.
Pour avoir à m'en servir suite à un choix sur le projet, la réponse à la question c'est: solo de pipeau.
Approches dogmatiques quand ça les arrange.
Bricolage dans l'implémentation et le suivi.
Suppression de fonctionnalité d'une version à l'autre.
Choix discutables des modules.
Alors certes on crée l'application avec une commande.
Super. A condition de ne pas avoir à tester cette application, à la complexifier un peu ou à la faire vivre.
C'est vrai que pour le passage de la version 1 à la 2, certaines modifications étaient discutables, mais rien de vraiment méchant si on s'y met un peu. Pour avoir développé une application en V1.2.5 utilisée potentiellement par 600 personnes environ, oui la productivité, la stabilité et la sécurité sont au rendez-vous. L'application tourne comme une horloge suisse depuis 2 ans.