Grails – Play, quel framework choisir ?

Grails et Play sont d’excellents framework RAD Open Source basés sur la JVM permettant la production de sites Web. Hibernate étant au coeur de ces framework, nous allons voir ce qui les différencie.

Pourquoi Grails et Play ?

Effectivement, d’autres framework existent (JRuby on Rails, Lift, Spring ROO…). J’ai voulu me focaliser sur ces deux là, car, de prime abord, il pourrait être difficile de les discerner car ils sont dans la même mouvance des framework MVC actuels.

Cet article n’a pas pour but d’être un comparatif exhaustif, mais il offre un décryptage des deux frameworks.

Les débuts

La première version officielle de Grails (à l’époque Groovy on Rails) date de 2006, et puise ses origines de Ruby on Rails. SpringSource rachète en 2008 G2One, la société en charge du framework, et assure maintenant sa maintenance.

Zenexity, avec l’appui de Guillaume Bort livre une première version de Play, deux ans plus tard en ayant acquis précédemment de l’expérience sur des projets Grails.

La philosophie

Ces deux frameworks prônent, entre autre, l’efficacité des développements (contrairement aux briques JEE) mais avec une approche différente :

• Grails est plutôt conventionnel, en réutilisant les composants classiques (dont ceux de Spring) et s’intègre parfaitement dans le monde JEE.
• Play est iconoclaste, et n’a pas hésité à ne pas réutiliser certaines briques JEE depuis longtemps utilisées, comme par exemple les servlets. De plus, son aspect fullstack est plus poussé ce qui le rend plus autonome et prêt à l’emploi.

Entrons maintenant dans le vif du sujet.

Compilation

Premier point étonnant avec Play pour les habitués de JEE : le framework ne génère pas de fichiers .class, mais les compile directement en bytecode à l’exécution (via la technologie utilisée par Eclipse).

La prise en compte à chaud des modifications sur le code

Grails et Play permettent plus ou moins bien de prendre en compte sans rechargement du serveur des modifications faites sur les fichiers du projet.

Play va, à chaque requête, parcourir tous les fichiers Java concernés, et les recompiler si nécessaire.

Grails vérifie toutes les 3 secondes (une durée configurable) les modifications faites sur les fichiers. Les modifications faites sur les objets du domaine redémarrent en partie le serveur.

Les modes d’exécution

Les deux frameworks ont par défaut les modes DEV / TEST / PROD, qui correspondent aux environnements de développement, de recette et de production.

Une configuration particulière va pouvoir être appliquée à chacun de ces modes (en particulier, la configuration de connexion à la base de données suivant les environnements).

Play se comporte différemment au niveau du mode de compilation, notamment sur les modes DEV et PROD. En mode PROD, la fonctionnalité de hot deploy va être désactivée, et une compilation complète (source Java et template) se fait au démarrage du serveur Web embarqué, bloquant le démarrage de celui-ci si la compilation n’est pas possible.

Stateless

Play est un framework stateless, il n’y a pas d’objet en mémoire (à part la configuration, les routes…), ce qui facilite la mise en cluster. En conséquence, l’utilisation d’une session est faite à travers un cookie (limité en taille et à des String).

Groovy / Scala

La rapidité de développement avec un framework RAD tient en partie au langage sur lequel ce framework se base.

Grails embarque le langage Groovy, orienté objet et typage statique et dynamique. Il amène le support des closures, la faible verbosité, la facilitation de manipulations des collections, et la compatibilité avec le langage Java.

Au démarrage, Play fonctionne uniquement avec Java. Il faut attendre la version 1.1 du framework qui assure le support du langage Scala. Il d’agit à la fois un langage orienté objet et fonctionnel, tout en étant typé statiquement. Plutôt difficile à maîtriser, néanmoins il reste possible d’exécuter du code écrit en Scala à partir de Java.

Les performances

Play a pris le parti de la performance dès le début de sa conception en proposant :

• sa propre API pour gérer les requêtes HTTP (les servlets étant considérées comme inadaptées au Web actuel),
• un serveur HTTP (JBoss Netty depuis la version 1.1) léger, qui est capable de gérer des centaines de requêtes par seconde, et permet également de gérer les requêtes en long polling,
• une architecture permettant de gérer les requêtes de manière asynchrone (non-bloquant).

Configuration

Grails utilise Groovy aussi pour les fichiers de configuration ce qui :

• apporte plus de souplesse dans l’écriture des fichiers de configuration (manipulation directe d’objets),
• réduit la verbosité des fichiers,
• conserve l’homogénéité (pas de XML, pas de JSON…).

La communauté

Modules

• 74 modules pour Play,
• 586 modules pour Grails.

Les modules de Grails et Play permettent d’étendre techniquement les frameworks. Grails a l’avantage d’offrir des plugins plus riches en termes de fonctionnalités (notamment, des fonctionnalités améliorant l’interface utilisateur).

Google Groups

• environ 24 000 posts pour Play / des tag stackOverFlow,
• environ 120 000 posts pour Grails avec des forums par langue (Anglais / Chinois / Espagnol / Polonais / Allemand / Portugais-Brésilien).

Grails bénéficie pour sa part d’une communauté beaucoup plus large, et tire parti de la communauté Spring et de son côté international.

En conclusion

Là où Grails est dans la continuité de la logique JEE, dans le sens « empilement des couches », Play va dans le sens inverse en y gagnant de la performance, mais en se coupant de la compatibilité avec d’autres frameworks.

Je reproche à Play un coté « patchwork » parce qu’il mélange en son sein différentes technologies et langages. Grails, quant à lui, est plus élégant par l’utilisation uniforme de Groovy au sein du framework (contrôleur / vue / configuration…) .

« Alors que choisir ? »

De mon point de vue, Grails et Play sont pertinents sur des environnements différents.

Play se positionne mieux sur :

• Un site Web de startup (projet from scratch) ;
• Un site Web à haute performance ;
• Un projet amateur (sans connotation péjorative) grâce à l’aspect full-stack.

En revanche, Grails est plus crédible sur des projets nécessitant une intégration au SI de l’entreprise, grâce à sa multitude de modules.