Sortie de la version 1.0 du framework Grails

L’information est tombée ce matin, Grails (qu’on présentera laconiquement comme un pendant de Rails dans le monde Java) vient de sortir en version 1.0.

Passé l’effet d’annonce il est temps de goûter aux senteurs issues de ces deux années de distillation, de constater les réussites concrètes mais aussi d’envisager les promesses du framework ainsi que son avenir.

Un Rails pour la JVM

Sans rentrer dans les détails d’une présentation exhaustive, Grails est un framework de développement d’applications Web basé sur le langage dynamique Groovy et sur des frameworks Java bien connus (Hibernate, Spring…). Rappelons à cet effet que Groovy est un langage dynamique pour notre bonne vielle JVM.

L’outils Grails met à la portée de l’univers Java des patterns popularisés par Rails, notamment le « convention over configuration » et des raccourcis sur toute la pile applicative pour des opérations courantes comme le CRUD, avec l’objectif revendiqué de simplification et de productivité des développements d’application web.


Sortie officielle de la version 1.0

La sortie de la version 1.0 récompense plus de deux années de développements et de confrontation aux utilisateurs et à la réalité des systèmes d’information.

Nous ne paraphraserons pas l’annonce officielle ni le changelog. Les éléments remarquables par rapports aux précédentes versions étant pour nous une documentation de référence de qualité et une robustesse accrue.


Les points forts du framework

Grails et Groovy fonctionnent sur une JVM. En cela, les développements autour de Grails bénéficient de vos investissements Java passés et à venir.

Les investissements « run »

Une application Grails est un « war » qui se déploie et s’exploite dans un serveur d’application quel qu’il soit, la persistence des données se réalise dans une bases de données relationnelle quelle qu’elle soit.

Les investissements « build »

Groovy et Grails se basant sur la JVM, les développeurs Java se sentiront presque comme chez eux dès les premiers abords, la courbe d’apprentissage de Groovy en connaissant Java s’avérant modeste. Plus important : vos développements Java sont réutilisables !

Vous avez un mapping Hibernate compliqué de votre coeur métier : réutilisez-le en l’état dans votre application Grails (puis profiter de la surcouche d’Hibernate fournie par GORM).
Vous avez des services métier Java riches issus de centaines de jours.hommes, réutilisez les et injectez les avec Spring !

Pour les plus prudents qu’une nouvelle pile applicative effraie, le pattern « Grails pour l’IHM et coeur en Java » a aussi fait ses preuves.

Un framework vivant et supporté

La communauté Grails est une des plus active du monde Java, pour preuve les statistiques de la mailing-list hébergée par codehaus (qui héberge aussi d’autres frameworks réputés).

Le support commercial cher à nos DSI (qui offre à mon sens un faux sentiment de sécurité aux vues de la qualité générale des applications avec et sans support…) est depuis peu assuré par la société G2One, fondée par les leaders des projets Groovy et Grails. On peut maintenant parler de Grails et porter une cravate, qu’on se le dise !

Les opportunités de mise en oeuvre

Les opportunités d’utilisation de Grails pour vos développements web sont multiples.

La plus évidente au bout d’une heure d’utilisation c’est le prototypage. Dans ce cadre d’utilisation, la génération automatique de contrôleur/vues et les méthodes dynamiques de GORM, permettent de monter une application Java fonctionnelle en quelques minutes. A cet égard, on citera l’exemple des méthodes dynamiques de type Person.findByName utilisables dès qu’un objet Person avec une propriété Name (en Groovy ou en Java), est connu de GORM.

L’autre utilisation que nous avons mise en oeuvre plusieurs fois avec succès est celle de développements d’une nouvelle application, avec des temps de cycle rapides, le métier imposant des délais de livraison très courts. A l’objectif de productivité de vos développements d’application web s’ajoute la possibilité de  » cristallisation  » de cette nouvelle application, lors du passage de la frontière entre innovation métier et rationalisation SI. Ces développements basés sur la JVM sont pérennes, vous pourrez à tout moment débrancher (ou pas) une partie de la pile Grails vers vos standards et pratiques Java, par exemple lors d’un passage de relai à vos départements Bengalore(TM).

A ces deux cas d’utilisation majeurs de prototypage et de nouveaux développements rapides, s’ajoutent des utilisations de niche au ROI extrêmement élevés, par exemple :

  • Exposer un legacy de base relationnelle en REST de manière expressive et synthétique.
  • Offrir une interface Web au goût du jour 2.0 sur un existant, le cas de consolidation de données et de statistiques pour du pilotage étant le plus emblématique

L’avenir du framework

L’utilisation du framework va très probablement se généraliser dans les mois à venir. Toutefois l’architecture à base de plugin laisse entrevoir des architectures plus riches que le MVC des premières versions de Grails :

  • Les plugins qu’on qualifiera de  » Java EE  » tels que le plugin JMS ou le plugin Mail sont le pendant de GORM pour simplifier l’utilisation de l’infrastructure Java EE dans la construction d’application d’entreprise.
  • Les plugins d’IHM comme le plugin GWT, le plugin Wicket ou encore le plugin Flex font poindre à l’horizon des applications d’un nouveau genre, exposant facilement un coeur métier Java ou Groovy, aux dernières technologies d’IHM.

Mots-clés: ,

6 commentaires pour “Sortie de la version 1.0 du framework Grails”

  1. Excellent Article Ismael !

    Seul bémol à Grails pour le moment, au build : le test…

  2. David,

    peux-tu nous décrire un peu plus tes retours négatifs sur les tests avec Grails ?

  3. Autre utilisation d’une architecture ‘Grails IHM + coeur Java’ possible grâce à l’intégration fine Grails/Spring : l’exposition Web d’EJBs legacy.

    Voir notamment static.springframework.or…

  4. Ismael,

    Beaucoup de code de Grails est généré dynamiquement, au runtime. Du coup, pour tester unitairement une classe, il faut déployer toute l’application. Ca prend du temps et rend l’exécution et l’écriture de test unitaire long. J’y vois un frein au TDD par exemple.

  5. Ce sont des tests d’intégration dès lors qu’ils utilisent l’environnement entier et donc le déploiement de l’application. Mais avec des techniques de mocking, on peut facilement créer des tests unitaires rapides à executer.

  6. [...] Sortie de la version 1.0 du framework Grails [...]

Laissez un commentaire