Play Framework : pourquoi j'ai migré de V2 à V1

Introduction

Utilisateur mordu de Play Framework, il y a plusieurs mois, j'ai migré mon projet en cours de V2 à ..... V1 ! L'information a un peu circulé, j'ai pu en parler ici ou là, et on m'a souvent demandé de partager mes raisons, ce que je vais faire dans ce post. 

Avec le temps, j'ai un peu oublié toutes les raisons qui m'ont poussé à cette migration, je m'en excuse par avance, mais les principales sont là !

La découverte

Courant 2010, je découvre Play Framework 1.x (dans ses premières versions). Je fais quelques essais "Hello world !", c'est vraiment nouveau, ça semble cool, c'est magique !

A la base, Play est conçu par les développeurs pour les développeurs, avec une volonté de faire plus simple que les usines à gaz JEE ou Spring, avec lesquels, finalement, on assemble toujours à peu près les mêmes briques, et ça nous prend un temps fou.

Facile à télécharger et à installer, Play permet tout de suite de créer le squelette du projet ("play new myapp") et de lancer le serveur play ("play run") pour avoir déjà une page d'accueil. La suite est un régal notamment grâce à quelques points forts :

• La présence par défaut de toutes les briques nécessaires : connexion base de donnée, mapping, rendu HTML, modèle MVC, ...
• Une gestion des erreurs bien travaillée qui indique clairement dans la page HTML l'origine du problème
• Une recompilation à la volée et rapide qui permet de voir immédiatement le résultat d'une modification simplement en sauvegardant le fichier et rafraîchissant la page WEB
• Plein de modules disponibles pour étendre les fonctionnalités de Play, et notamment 2 modules essentiels : "secure" pour la sécurisation d'accès aux page, et "crud" pour avoir une génération automatique de pages d'administration des données
• Déploiement facile sous forme de WAR
• Un site très didactique et une document très bien faite; et pleine d'exemples de code
• etc .... (j'en oublie certainement qui sont devenus évident pour moi)

Bref, un gros coup de coeur que j'ai ainsi résumé à l'époque : simplicité, rapidité, productivité ! L'application est toujours utilisée et maintenue sous Play V 1.2.5.

Première véritable application

Eté 2010, je démarre un nouveau projet perso, application SaaS WEB, donc je pars sur Play. Et là, bonne surprise, le framework n'est pas cool que dans une phase de découverte "Hello world", il l'est également sur un véritable projet. La productivité est vraiment impressionnante, j'arrive à faire pas mal de choses (simples) en quelques heures.

Au final, je passe plus de temps sur la partie IHM et JavaScript, d'autant plus que Play me facilite la partie serveur.

Je déploie mon application en 1 clic sous forme de WAR sur une plateforme PaaS gratuite.

Nouveau projet

Début 2012, je décroche un contrat pour développer une application SaaS pour un client final. Play V2 est sorti depuis quelques temps, et on en parle beaucoup. Je sais qu'il n'y pas compatibilité entre les 2 versions, mais pour un nouveau projet, ça n'est pas gênant. Et je me dis que les gars qui avaient fait Play1 avait fait un truc tellement génial, que Play2 ne peut être que mieux, puisqu'ils auront tiré de l'expérience Play1 tout ce qui pourrait permettre de faire un truc encore mieux ! 

Je décide donc de partir sur Play2 en développant mes contrôleurs en Java, je n'ai pas la possibilité de me lancer dans Scala (pour l'instant). J'ai commencé par la V 2.0.1, puis 2.0.2 et enfin 2.0.3.

Les débuts se passent bien,  l'adaptation à la V2 est sans problème, je retrouve mes petits et mes habitudes : la structure MVC, le style de développement, les fichiers de configuration, de messages, etc ...

Et l'utilisation de Scala dans les templates de vues n'est pas un problème, malgré une légère complexité supplémentaire dans les déclarations et la syntaxe.

Le désenchantement

Mais petit à petit, divers problèmes sont apparus me faisant perdre de plus en plus de temps. Je vais en passer en revue quelques uns dans le désordre.

Mapping base de données

Le stockage de données ne se fait plus par Hibernate mais par Ebean. Ça n'est pas un problème, surtout que les entités sont annotés avec JPA. En fait, j'ai eu des difficultés avec des mapping un peu plus complexe, et j'ai surtout perdu du temps avec le système de scripts d'évolution du schéma de la base : ce système est puissant mais m'était totalement inconnu. Pour ce point, c'est plus mon manque de compétences qui m'a gêné mais la documentation du framework n'était pas au RDV, et la V2 étant relativement nouvelle, les forums donnaient plutôt des solutions pour la V1, d'où pas mal de confusion et de galères.

Et en fait, la V2 fonctionne par défaut avec Ebean, mais on peut faire de l'Hibernate. Et sans m'en rendre compte, et par manque de documentation, je me suis retrouvé à plusieurs reprises avec un mélange des deux apportant encore plus de difficultés !

Lenteurs

Dès le début, j'avais noté que le serveur V2 était plus long à se lancer. Mais là où ça devenait pénalisant, c'était pour la recompilation à la volée qui prenait beaucoup plus de temps qu'avec la V1 : un changement dans une vue et dans un contrôleur, sauvegarde des fichiers, rafraichissement de la page et ..... une attente bien longue ... Combien ? Je ne sais plus exactement, mais peut-être parfois près d'1 minute. OK, c'est moins long que la relance d'un serveur Spring ou JEE, mais par rapport à mes habitudes avec la V1 où une telle opération prenait environ 5", la productivité n'était plus du tout la même !

Documentation

Depuis la sortie de la V2, le site avait été refait, je le trouvais plutôt sympa. Mais à l'usage, surtout pour trouver de la documentation, ça n'est plus la même histoire ... OK, la V2 supporte Java et Scala pour les contrôleurs, donc la documentation à produire et maintenir est double, mais la V2 apportait pas mal de nouveautés qui étaient très peu documentées, souvent juste quelque lignes et un tout petit exemple de code. J'ai vraiment galéré sur certains points (cf Ebean précédemment), et les forums et mailing-list n'étaient pas d'un grand secours (ils le sont beaucoup plus maintenant, d'ailleurs il est plus difficile de trouver maintenant des infos sur la V1 ....).

Modules

Contrairement à la V1, la V2 est sortie avec peu de modules disponibles, sachant qu'il n'y a pas compatibilité entre les versions pour les modules. L'équipe de développement comptait peut-être sur la communauté déjà acquise à la cause Play ? Et notamment, pas de module "CRUD" sur lequel je comptais pour faire rapidement et simplement le back-office pour mon application. OK, c'est pas bien compliqué, mais les 2h prévues pour faire ça se sont transformées en quelques jours :-(

Compilation Eclipse

J'utilise Eclipse, je l'aime bien et j'assume ! ;-)

Tout comme pour la V1, une commande "play eclipsify" permet de préparer un projet à importer facilement dans Eclipse. La grande nouveauté dans la V2 est la compilation des template de vues qui sont écrites avec un mélange de Scala et d'HTML, puis compilées. L'appel à la vue depuis le contrôleur est donc typé, ce qui limite grandement les risques d'erreurs pour le passage de paramètres entre le contrôleur et la vue.

Dans le principe, c'est une bonne chose, même si avec la V1, j'ai rarement eu de gros problèmes à cause de ce passage de paramètres contrôleur-vue. Le problème dans mon cas était que lorsque je modifiais une vue dans Eclipse, la recompilation ne se faisait pas (ou pas bien) et je me retrouvais avec du rouge de partout, notamment dans le contrôleur puisque les appels n'étaient pas bons. Et pourtant, l'application fonctionnait bien puisque le serveur Play devait certainement recompiler l'ensemble. Et parfois, après certains rafraîchissements dans Eclipse, les erreurs de compilation disparaissaient.

Au début, je me suis dit que ça n'était pas gênant et que je pourrais faire avec, mais à la longue, c'était devenu très pénalisant !

Tests unitaires

Pour moi, ce fut le gros points noir au quotidien. Je suis un inconditionnel des tests unitaires et je développe en TDD le plus possible. Ce qui veut dire, pouvoir lancer toutes les 10" le test sur lequel je travaille actuellement (voir utiliser infinitest). 

Mais je n'ai jamais réussi à configurer correctement Eclipse pour pouvoir y lancer les tests unitaires. Des fois, ça a fonctionné, mais la plupart du temps, j'étais dans une situation où il m'était impossible de lancer une classe de test. La seule solution était de lancer les tests en console, mais la commande ne permet de lancer que l'ensemble des tests, donc un certain temps d'attente à chaque fois, et les éventuelles erreurs étaient noyées dans la masse d'informations tracées, et qui plus est, les erreurs n'étaient pas retranscrites clairement, à peine le nom du test en échec sans la raison et les valeurs concernées. Donc impossible de travailler en mode TDD !

La migration  (downgrade)

Je commençais donc à me rendre à l'évidence : pour moi, la V2 était beaucoup moins bien que la V1. Mais je n'arrivais pas à y croire. Je me suis accroché pendant pas mal de temps, j'ai fait des recherches sur internet, et lancé des appels sur des mailing-list ou sur Twitter. Cela ne m'a pas vraiment apporté de solutions. Par contre, je commençais à me rendre compte que je n'étais pas le seul déçu de la V2, ce qui n'était pas pour me rassurer.

Et un jour, me rendant à l'évidence des pertes de temps que j'accumulais, et de mon manque de productivité, j'ai décidé de repasser mon projet en cours sous la V1. Les 2 versions en sont pas compatibles, mais à ma grande surprise, la migration n'a été ni longue ni très compliquée (quelques jours de boulot, très vite rentabilisés !).

J'ai alors retrouvé la simplicité et l'efficacité de la V1, le plaisir de développer (que je commençais à perdre) et une réelle productivité : aujourd'hui mon projet est sous V 1.2.5 et je ne le regrette pas !

Conclusion

Mon impression est que l'équipe qui a sorti la V2 a fait des choix techniques pour apporter de la scalabilité à Play, et peut-être certaines innovations, mais au détriment de ce qui, à mes yeux, faisait la force de Play1 : simplicité, efficacité et productivité.

Je ne développe pas des applications visant des millions d'utilisateurs, avec des calculs nécessitant de répartir les actions sur des clusters de serveur via des "agents" (la fameuse scalabilité). Par contre, je veux aller vite sur les choses simples et mettre mes efforts sur les points à valeurs ajoutées (IHM et JS).

Aujourd'hui, lorsqu'on me demande quelle version de Play je conseille, je réponds ainsi :

• Tu veux découvrir un framework novateur et cool, et tu veux tester concrètement Scala, just for fun : prends la dernière version de Play V2
• Tu dois développer une grosse application, visant des millions d'utilisateurs, avec des traitements lourds, probablement à répartir sur plusieurs machines : regarde du côté de la V2, c'est certainement préférable
• Tu veux développer une application modeste ou "classique", la charge sera normale et pourra être supportée par un serveur sur le cloud, mais tu veux te faire plaisir, aller vite pour la partir serveur, aller très vite pour des pages d'administration (via CRUD) et te concentrer sur l'IHM : prends la dernière version V1 (1.2.5) et régale toi !