Choisir Grails pour faire du web: Au menu ou à la carte ?

Mars 2006. La comète Grails fait son entrée dans la galaxie Java en sortant sa première version publique. Inspiré par le succès du framework Ruby on Rails, Grails propose alors d'en adapter la recette à la sauce Java. Sa promesse ? Fournir une solution simple, rapide et élégante pour développer des applications Web J2EE pour l'entreprise.

Mars 2007. A quelques jours du premier anniversaire du framework, force est de constater que l'engouement autour de Grails reste intact. Chez OCTO comme chez nos clients, de premières références significatives voient le jour en production. On commence à y croire : Avec Grails, ca va vite.

Grails venant enrichir une panoplie de solutions déjà à notre disposition pour nos développements Web, des questions se posent : Choisir Grails, pourquoi pas, mais dans quels cas ? Est-il adapté aux contraintes d'un SI d'entreprise ?

Dans quels contextes et de quelle manière Grails peut-il faire la différence ?

L'approche " Grails Intégrale " pour démarrer rapidement des applications Web

Grails nous propose une solution packagée pour mettre en oeuvre une application Web. De l'IHM à la donnée, Grails permet à n'importe quel développeur Java peu expérimenté de délivrer rapidement ses premiers écrans Web. Pour cela le framework s'appuie sur plusieurs concepts clés d'amélioration de la productivité ; on retiendra notamment le fameux paradigme " convention over configuration " qui permet de minimiser le " code technique " au profit du " code métier ". Il en résulte une réduction du ticket d'entrée généralement constaté au démarrage d'applications JEE.

Avec Grails on peut donc développer rapidement des prototypes Web. C'est bien... mais avouons que depuis longtemps des technologies comme PHP répondent très bien au besoin. Enfin, jusqu'au jour où la petite application veut devenir grande. Car si aujourd'hui je veux minimiser les contraintes pour sortir rapidement un prototype isolé, demain je le voudrais maintenable et exploitable par des tiers, interopérable et respectant les contraintes d'architecture du SI. D'ici là, on cherchera à minimiser la période et les coûts de transition.

C'est ici que Grails prend toute son ampleur. Sa force ? Résister aux deux temps qui composent la vie d'une application : L'innovation et la rationalisation. En choisissant Grails pour mes prototypes, je suis rassuré. Je sais que contrairement à Struts, il me fournira d'abord toute la souplesse et la légèreté dont j'ai besoin pour affiner ma compréhension du métier au fil du projet sans avoir la sensation de courir un 100 mètres dans un champ d'argile. Au final, peut-être que cette approche légère suffira alors pour répondre parfaitement à mon besoin. Mais je sais aussi qu'à tout moment je serai capable de faire évoluer couche par couche mon application vers une architecture JEE plus classique. Le framework encapsulant des composants et patterns JEE standards (Hibernate, Spring, JUnit, Sitemesh...), une simple adaptation du code suffit. Nul besoin de réécriture complète et de transition couteuse. Chez OCTO, on parle alors de " cristallisation " ou de " refroidissement " des couches de l'application.

Les motivations de cette cristallisation peuvent être de plusieurs natures. Liées à des contraintes externes au projet telles que la volonté de standardisation des technologies et des architectures applicatives au sein d'un SI, le besoin d'intégration avec une application existante ou encore la volonté des équipes de TMA de rester sur du 100% Java. Mais aussi liées à des besoins propres au projet tels que l'apparition de besoins techniques très spécifiques, sortant du cadre du " tout Grails ", ou encore par l'agrandissement de l'équipe projet. Car il faut avouer qu'à ce jour si l'approche " Grails Intégrale " convient parfaitement aux petites équipes (moins de 4 développeurs) et aux petits projets, il deviendra délicat de se passer d'un socle Java outillé lorsque le projet prendra de l'ampleur. Malgré de premiers plugins, le faible support de Grails par les IDE Java tels Eclipse ou IntelliJ IDEA est à l'heure actuelle pénalisant en termes de refactoring et de contrôle de validité du code. Du coté de la communauté Grails, semble-t-il que ce point ait été fixé comme l'une des priorités d'amélioration à court terme ; des travaux sont en cours, à suivre...

Dans le cadre du lancement d'un prototype ou d'un petit projet Web, Grails propose une solution complète, " out of the box " et productive. Il permet de réduire les contraintes et le coût d'entrée dans un premier temps, et d'évoluer par la suite facilement vers une application d'entreprise. Grails encapsulant Java, il est immédiatement accessible aux développeurs et ne nécessite pas de compétence particulières.

L'approche " Grails IHM " pour booster la couche IHM des applications Java JEE

Nous avons vu que la modularité de Grails lui permet d'accompagner le cycle de vie d'une application, depuis son démarrage en " Grails Intégrale ", jusqu'à sa transformation en une application mixée Grails/Java. Est-il pertinent d'utiliser cette modularité pour envisager une utilisation de Grails " à la carte " pour prendre en charge uniquement la couche IHM d'une application bâtie sur un modèle Java JEE classique ?

Grails peut être utilisé uniquement comme un framework d'interfaces WEB au même titre qu'un Struts, qu'un JSF ou qu'un GWT. Dans ce contexte là, seules les couches vue/contrôleur de la bête seront sollicitées, le reste de l'application s'appuyant sur un développement Java classique. A quoi bon ? "Yet Another Web Framework" diraient nos amis d'outre-Atlantique... Certes. Mais quel framework !

De manière générale, la productivité de développement d'un écran est élevée ; la communication entre les couches se fait trivialement, " convention over configuration " toujours, le système de " reloading " à chaud permet d'aller très vite dans le processus de développement, la gestion des " taglibs " est excellente et favorise la production de code propre et réutilisable. Au delà de cette productivité, le positionnement de Grails vis-à-vis des frameworks concurrents peut être rassurant pour beaucoup. Contrairement à GWT qui introduit un nouveau paradigme maison pour gagner en productivité, Grails conserve un modèle et des concepts bien familiers. Après quelques minutes d'utilisation on comprend rapidement que du simple CRUD jusqu'aux écrans de navigation complexes et sécurisés, Grails ne sera jamais limitant. Au contraire, sa productivité prendra tout son sens avec l'arrivée d'écrans complexes.

Ajax bien sur... Grails propose une encapsulation native de certaines fonctionnalités des frameworks Prototype, Dojo et Yahoo!UI. Recharger dynamiquement le contenu d'une page devient alors aussi facile que de saisir une taglib dans une page JSP. Cependant, ne nous voilons pas la face, l'application s'étoffant il devient difficile de se passer de l'utilisation de JavaScript et de ne pas sortir du cadre Ajax de base proposé par Grails. Malgré tout, cela se fait très bien et encouragé par le confort général de développement lié à l'utilisation de Grails on se surprend à faire du client Riche ; les écrans sont sexys et gagnent en expérience utilisateur.

Dans le cadre de développement d'une application d'entreprise d'envergure sur un socle JAVA, l'utilisation partielle de Grails pour la couche IHM peut s'avérer pertinente. On appréciera sa productivité et son confort général d'utilisation. Sa modularité en fait également une très bonne solution pour venir se brancher à un legacy et lui donner la vue...