Grails en quelques mots

Je travaille depuis quelques mois avec le framework Web Grails. Cela fait quelques semaines que je m’en sers presque 8 heures par jour. Je vous propose un petit tour du propriétaire.

Grails est un framework Web basé sur le langage Groovy clairement orienté productivité. J’ai ramené 4 livres de Devoxx sur Groovy et Grails, et le meilleur ouvrage pour rentrer dedans reste « Grails in Action » de Glen Smith et Peter Ledbrook. 470 pages plus tard vous serez en mesure de construire une application industrielle, et il vous manquera un peu de détails sur Groovy, facilement couvert par exemple avec « Groovy Recipes » de Scott Davis.

Grails s’installe en 5 minutes, se découvre en 30 minutes et se maîtrise en une semaine. Je me dis que si mon aventure de Startup ne marche pas, je pourrai toujours écrire un livre sur le sujet en Français. C’est vous dire si j’ai envie de vous en parler.

Introduction à Grails
Grails m’est tombé dessus car j’avais besoin d’une solution pour démarrer rapidement, valider rapidement (et éventuellement me planter rapidement). Je me surprends à tester des bouts de code, à écrire des choses comme « Books.findByAuthor(‘Guillaume Laforge’) » et à voir que Grails génère le code de ce finder pour moi… Envie d’Ajax ? je transforme mes tags form en remoteForm et ça marche. Envie de faire un formulaire avec 4 écrans ? Spring Webflow est intégré, le flow est écrit en Groovy, rien de plus simple… Et c’est comme cela depuis 3 semaines… Je n’arrête pas de m’étonner de la maturité et de la puissance de ce framework Web.

Avec ou sans état ?
Grails comme Play! se classe dans la catégorie des frameworks Webs sans état. Il y a bien entendu une session, des scopes pour vous aider à travailler. Mais là où Wicket et JSF sont orientés composants, Grails est clairement orienté Web / HTTP. Il n’y a pas la notion d’Application et il n’y a pas la notion de composants comme en Wicket ou JSF2 par exemple. Nous pouvons donc dire que Grails est adapté pour la réalisation de projets plutôt Web, et il n’est pas forcément le plus adapté pour réaliser une application riche. Il y a pourtant des applications basées sur du Flex pour la couche de présentation qui travaillent avec une partie serveur en Grails pour les services. Cette alchimie fonctionne donc aussi.

Fan des conventions au lieu de la configuration
Grails tire ses origines du framework Rails du monde Ruby. Mais il utilise le langage Groovy qui tourne sur la JVM. Ses cousins ? JRuby on Rails, Clojure, le framework Lift du monde Scala, et Play! du monde Java. C’est un framework Web clairement orienté productivité et simplicité. Pour moi, il fait parti des frameworks webs de 4ème génération. Il y a d’abord eu les JSPs, les Servlets et les Applets. Puis ensuite Struts avec les premiers frameworks MVC de type 2. Ensuite l’apparition des RIAs (Rich Internet Applications) avec GWT, JSF, Wicket. Et donc maintenant je crois dur comme fer à ces nouveaux frameworks Webs, qui reviennent sur les bases du protocole HTTP pour offrir des performances et de la simplicité.

Grails est sorti en 2006. Il y a des sites en production comme Businessworld, Sky.com ou encore Escapeer. La page Testimonials donne une idée de quelques projets réalisés avec Grails et Groovy.

Groovy est le point fort de Grails. Je vous parlais de trouver des livres quelques lignes plus hauts. Vous pouvez aussi écrire des bouts de code comme par exemple:

Book.findAllByDatePublishedGreaterThanAndTitleLike(myDate,"Grails par le Touilleur Express")

Grails sera capable de générer le code Hibernate, Spring et Groovy afin de trouver tous les livres dont la date de publication est postérieure à une date, et dont le titre ressemble à ce que je précise… Lorsque je vous dis que vous allez gagner du temps, vous commencez à me croire ?

Grails utilise des standards
Grails utilise Groovy, et ensuite le couple Hibernate/Spring de base. Il est assez facile d’ajouter de nouvelles librairies grâce à des plugins. Dans mon projet par exemple j’utilise Drools. Je n’ai eu besoin que de 10 minutes pour créer un controleur simple et une règle Drools pour tester une idée.

Les idées de Grails
Ce qui suit est tiré du livre « Grails in Action ». Il y a 7 idées clés à comprendre pour adopter Grails:
– Convention au lieu de la Configuration
– Philosophie Agile
– Des fondations solides
– Scaffolding et moteur de template
– Intégration avec Java
– Une communauté et des plugins
– La Productivité améliore la qualité et réduit le risque d’erreur

Concernant l’aspect convention au lieu de configuration, cela revient à vous dire que pour gagner du temps, il faut suivre ce que dis le framework. J’ai juste un mot à dire aux gens qui font du Maven2, mais qui ne veulent pas ranger leurs fichiers dans src/main/java, qui désactivent les tests, qui veulent lancer des scripts Ant avec Maven : arrêtez Maven.
Vous n’avez rien compris à sa philosophie, vous pleurez car « Maveneu il rameuu » alors que si vous aviez pris le soin de lire l’excellent livre « Apache Maven », vous ne seriez pas comme un gosse avec le pantalon mouillé. Si vous commencez à bidouiller l’outil, c’est que vous n’avez pas lu la documentation, que vous n’avez pas écouté ce que vous disent les développeurs. A ce titre, je trouve que les livres que j’ai lu m’ont énormément aidés par rapport à la doc de Grails, qui ne distille pas assez la philosophie, à mon sens. Donc si vous voulez me suivre : achetez des livres sur Grails.

Grails est simple : une entité Survey est toujours stockée dans le répertoire domain. Cela permet à Grails de gérer l’object via Hibernate pour vous. Un controlleur est nommé SurveyController, et il est placé lui-aussi dans un endroit attendu par Grails. Si vous ajouter une méthode « completeSurvey », celle-ci est alors accessible automatiquement via une url comme « /survey/completeSurvey ». Si vous créez une nouvelle entité « Answer », Grails se charge de créer la table en base de données. Vous n’avez pas généré de fichiers pour tout ce qui est CRUD ? Grails le fait tout seul. Pour l’affichage des pages, il suffit de créez un fichier « /views/survey/completeSurvey.gsp » et il sera alors automatiquement chargé…

C’est bien de la Convention par dessus la Configuration et surtout pas de la Convention « au lieu de » la Configuration. Si vous voulez utiliser vos fichiers de mapping Hibernate : oui c’est possible. Mais par défaut : vous n’en n’avez pas besoin. Tout ce qu’il est possible de faire de manière répétitive et générique, c’est offert. Et comme vous aurez besoin de mettre le nez dedans, vous pouvez aussi le faire.

J’en suis à 16 classes pour mon domaine, à 2700 lignes de codes, 19 contrôleurs, et en 3 semaines j’ai déjà une application qui tourne… Je vous assure que je vous montrerai tout cela dans une vidéo très bientôt.

Grails est adapté au développement Agile. En fait je pense même que l’on peut dire que c’est un framework Web Agile. Les tests unitaires comme les tests fonctionnels sont faciles à écrire. Le fait de pouvoir créer un War, c’est aussi très pratique. Je vous explique cela : j’ai installé un Tomcat sur une machine, avec une base MySQL. Sur mon Mac, en ligne de commande il suffit que je tappe « grails war production » pour que cela me construise un fichier WAR, qu’il me suffit de déployer ensuite sur Tomcat pour la version en production. A aucuns moments je n’ai eu besoin de mettre le nez dans un quelconque fichier web.xml…
Au quotidien je ne construis pas de WAR. Je tappe simplement « grails run-app » et un serveur Jetty démarre, intégré à Grails. Lorsque je code, je n’arrête presque pas le serveur. En fait, lorsque vous changez un bout de page GSP, celle-ci se rafraîchit tout en gardant votre session. Si vous ajoutez une nouvelle méthode dans votre contrôleur, l’url est disponible et vous pouvez continuer à coder. Il n’y a qu’en cas de plantages que je relance parfois le serveur, lorsque ma session est pourrie. Je trouve que la remontée d’erreur pourrait encore faire des progrès par rapport à Play! mais c’est déjà pas mal.

Grails est basé sur des fondations solides. Spring et Hibernate. Spring 3 depuis la toute dernière version 1.2.RC2 que je teste en ce moment. En fait vous ne voyez pas Hibernate et Spring, mais vous savez que vous pouvez aller voir si nécessaire. Le moteur de scheduling ? C’est Quartz. Le moteur de recherche ? Lucene et Compass pour les entités. Le moteur de construction ? SiteMesh… Bref il n’y a pas d’innovations. Nous parlons bien de techniques que vous connaissez déjà. Imaginez simplement ceci : écrire moins de code, travailler plus vite.

Le moteur de scaffolding et de templating. J’adore Spring MVC. Je m’en suis servi l’été dernier pour mon projet sur Google App Engine (http://touilleur.appspot.com), projet que je ne finirai pas faute de temps. Grails est assez radical par rapport à Spring MVC. Là où vous auriez quelques beans annotés, des fichiers de configuration, un peu d’Hibernate et une configuration avec la base, Grails fait la même chose en quelques minutes.

grails create-app myapp
...
...
grails run-app

Ouvrez votre navigateur : http://localhost:8080/myapp, c’est prêt. Ensuite si vous voulez ajouter un nouveau contrôler :

grails create-controller MonControleur

C’est tout !

Lorsque vous créez une nouvelle entité, un nouvel objet du domaine, il est facile aussi pour Grails de vous générez automatiquement tout ce qui est CRUD. C’est ce que l’on appelle le scaffolding. Ce n’est pas destiné à remplacer votre application. En fait voici comment je travaille : je génère d’abord mes entités avec des idées à tester. Ensuite je crée un controleur pour cette entité en mode « scaffold ». Cela me permet de tester mon objet, de valider les relations one-to-one, one-to-many, many-to-many et de m’assurer que tout marche. Enfin, je refais un vrai contrôleur pour mon application finale, et je ne touche pas à ce que Grails m’a généré. Je recopie quelques petits bouts de code pour gagner du temps, mais c’est là que je code vraiment mon application. Cela me fait gagner un temps fou.

L’intégration avec Java est là pour rassurer les bons pères de famille. Il y a un répertoire Java. Vous pouvez y placer ce que vous voulez. Pour peu qu’une librairie de votre ERP soit en Java, et qu’il soit nécessaire d’écrire un peu de code orienté Service, Grails vous aménage un espace dédié pour le faire, et se débrouille pour injecter vos services Java dans les contrôleurs Grails… C’est très pratique. Je m’en suis servi pour une partie avec du Drools, que j’ai migré vers du Groovy car finalement, c’est plus simple.

Grails a une communauté. C’est bête, mais lorsque le lundi matin vous êtes seul dans votre bureau de 7m2, croyez-moi vous êtes super content de voir qu’il y a pleins de gens qui se servent de Grails sur Internet. Google est ton ami. La documentation est bonne. Le produit vit, et la liste de diffusion users est très active. J’ai appris beaucoup en lisant les échanges ces dernières semaines. Enfin côté livre je vous le disais tout à l’heure, il y a de très bons livres en Anglais. Si j’avais le temps et le courage, je me lancerai bien dans l’écriture d’un livre en Français. Mais je suis trop bavard… Pas possible pour moi.

Enfin pour terminer, le 7e point noté par les auteurs de Grails in Action, c’est l’aspect de productivité et la possibilité de valider ou non ses idées très rapidement. Pour notre projet qui sera en ligne l’été prochain, je me remercie chaque jour d’avoir pris Grails pour gagner du temps, faire des démonstrations qui marchent chaque semaine, jeter sans souci du code écrit en 3 jours au lieu de 2 semaines, bref je peux dormir tranquillement la nuit. Est-ce que tu comprends que je peux virer des idées foireuses car elles ne m’ont coutés que 2 jours au lieu de 2 semaines ? Un vrai projet de Startup c’est beaucoup d’essais. Personne ne vous dira si ce que vous faîtes c’est bien ou pas. Il faut avoir cette possibilité de changer de cap très rapidement, encore une fois dans le cadre d’une Startup pour moi.

Conclusion
Pour terminer, je vous laisse ici ce soir. Je vous montrerai un peu de Grails, du vrai code, pas un « Hello World », plutôt une application écrite en quelques heures, afin de vous faire comprendre ce qui a retenu mon attention.

Je pense aussi que nous, développeurs Javas, devons nous remettre en question d’urgence. En voyant des projets sur PHP ou Ruby on Rails, j’ai un peu la gueule de bois avec mon Java. Je pense que pour le développement d’applications Webs, il faut revoir notre manière de penser, notre manière de travailler. J’ai même du mal à croire au succès de Struts hier, de Wicket/Tapestry/JSF en ce moment… Comment pouvons-nous rouler des mécaniques alors que d’autres langages sont bien meilleurs pour faire du développement webs ? Que d’autres frameworks sont bien mieux pensés et bien moins prétentieux que ce que nous vendons depuis 3-4 ans à nos clients ? Comment avons-nous pu vendre des développements avec du Struts, des JSPs à des clients finaux ? Comment ?

Imaginez-vous entrain d’expliquer aux clients que les développeurs sur certains projets doivent construire un WAR, arrêter et relancer leur serveur d’application avant de voir leur résultat… alors que c’est inutile avec Grails (et d’autres)…

Et encore, je ne vous ai même pas encore dit que j’étais aussi tombé amoureux de Groovy…

J’en garde pour la prochaine fois.

Articles similaires:

Quelques livres pour apprendre Scala Devoxx 2010 dans quelques jours Quelques conférences pour cet automne JavaOne 2010 et quelques infos