tag-150-150-grails 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.

11 réflexions sur « Grails en quelques mots »

  1. Très bon article. (Il faut vraiment que j’essaie pour de vrai, grails, rrrr….)
    Le retour au http. J’aime beaucoup cette idée de revenir à l’essence du protocole, de ne plus cacher la mécanique mais au contraire en prendre son partie.
    Mais en fait, depuis l’arrivée d’Ajax, les frameworks « à composant » ne devraient plus être si différents des frameworks request/response. En effet, tu peux décomposer ta page en composants – tel tag select qui lance une action quand on le modifie, tel bouton qui ouvre un div avec unen sélection de données, tel tableau qui est affiche une liste …. Ce sont des composants aussi. Une page est une composition de bouts de codes Il n’y a pas d’objets rattachés en session sur le serveur… La différence est qu’il n’y a pas d’objet en session.
    Avant, avec des pages à la Struts, tu savais que tu devais recréer toute ta page (et encore, sitemesh ou les tiles aidaient bien). Maintenant, avec ajax on peut définir un fragment de page comme utilisable en soit (le tableau sait quelle liste afficher, le formulaire sait quel objet stocker), ou comme faisant partie d’un tout – c’est aussi programmer par composants. Est-ce que Grails sait faire ça? Est-ce que le templating des pages permet de décomposer franchement sa page en tags, en composants (il y a une possibilité de créer des tags en grails je crois?)
    Sinon, côté java, il y a jax-rs qui est aussi très puissant et simple – et qui revient au http. Mais moins de possibilité pour faire du html derrière. Avec Jersey, il est possible d’appeler une jsp qui va te permettre de construire une page mais c’est pas super sexy.

  2. Merci pour ce post très interessant ! de même que celui sur Play! mais du coup je m’interroge, ayant testé les deux vous conseillez quoi pour lancer un nouveau projet ?

    Merci encore !

  3. @Gabriel oui tu as raison, cela me donne l’envie de creuser l’idée « avec ou sans état » et peut-être d’expliquer un peu mieux mon sentiment.

    @Mikael je conseille de tester les deux. L’avantage de Play! c’est du Java. Je préfère Groovy et Grails à titre personnel mais j’aime beaucoup les idées de Play! Il faut qu’ils viennent au Paris JUG pour en parler.

  4. Bonjour,
    Merci pour ce post super vraiment mega très intéressant 🙂
    On sens au travers de ces quelques lignes l’oeil du développeur qui brille.
    Pour moi cette fois c’est décidé je vais me mettre sérieusement à Grail. Concernant le choix entre Play! et Grail, corrigez moi si je me trompe, mais il me semble que Play! est encore un peux jeune et que par conséquent Grail est plus abouti et que la communauté est plus importante.
    Bonne journée

  5. Bonjour Nicolas,

    Et play! qu’en penses tu ? as tu fais des tests avec ?
    J’ai pu assister à la présentation chez Zenexity et ca m’a l’air prometteur et surtout encore plus accessible que Grails.

    J’ai cependant du mal à me construire le tableau comparatif des deux frameworks.

    Bonne journée.

  6. Comment évolue Grails quand les APIs de la plate-forme Java EE évoluent?
    Quel interop/utilisation de JAX-WS et JAX-RS par exemple?
    Même question pour JPA. Maintenant que JPA 2.0 propose une API de critères, est-ce qu’il va y avoir un alignement dessus ou une divergeance?

  7. Bon, c’est décidé, je test Grails ASAP.

    Tiens puisque ça parle de REST, et avant que je creuse le sujet : pour envoyer une réponse en JSON (sérialiser des entités) depuis des contrôleurs Grails, vous utilisez quelle techno ?

    Idéalement, je cherche un truc qui me permette de sérialiser mes POJO en JSON sans le moindre effort… J’ai commencé à utiliser GSon, c’est vraiment bien, mais je me demande s’il y a des technos déjà intégrées à Grails 🙂 .

    Je sens que je vais me réaliser un petit combo « backend CRUD en Grails + services REST en Gson » et « client Android avec Guice/Gson »… Du top moumoute en perspective! Articles à venir 🙂 .

  8. Article intéressant.
    J’utilise beaucoup GWT sur mes derniers projets, avec la version 2.0 j’ai beaucoup de mal à voir un adversaire à GWT pour le développement d’application web (RIA). Par contre je mettrai GRails dans un panier différent pour la création de site internet car avec GWT on est presque à des applications Swing/Java Web Start version HTML/JS.
    Je me demandais si par rapport à la conclusion de ton article, tu plaçais GWT dans les frameworks que nous, développeurs, nous devrions « oublier » en faveur de Grails ou pas.

    Cordialement,

Les commentaires sont fermés.