La semaine dernière j’ai publié un billet décrivant l’utilisation de Scala pour simplifier le développement d’une application PrimeFaces + Cassandra.
Cette semaine, nous allons reprendre ce même exemple, mais en utilisant Groovy.
Le but de ces articles est d’étudier l’utilisation de chaque langage dans un cas concret, relativement simple, afin de voir si l’utilisation d’un langage alternatif nous permet de gagner en concision et en clareté du code.
Préparation du jeu de test
L’application étant la même que la semaine dernière, vous pouvez réutiliser le même jeu de test si vous l’avez gardé.
Sinon, je reprends ici le texte de la semaine dernière : l’application de test est un simple tableau JSF, affichant des données provenant d’une Column Family Cassandra.
Pour avoir cette Column Family fonctionnelle :
- Clonez notre repository Tatami : https://github.com/ippontech/tatami
- Dans une console, lancez Cassandra : “mvn cassandra:run”
- Dans une autre console, lancez Jetty : “mvn jetty:run”
- Vous pouvez maintenant utiliser Tatami en vous connectant sur http://127.0.0.1:8080 : créez quelques utilisateurs depuis la première page. Puisque nous n’avons pas configuré de serveur SMTP, vous verrez dans les logs de Tatami le mail envoyé, avec le mot de passe généré. Vous pourrez alors vous logger dans l’application pour indiquer votre nom et votre prénom.
- Eteignez votre serveur Jetty, car notre application Groovy va utiliser le même port 8080
Mise en route de l’application : Maven, le retour
Il est rare de voir des gens heureux de configurer un projet Maven : c’est parce qu’ils n’ont pas fait de SBT avant… Contrairement à l’application SBT de la semaine dernière, nous pouvons configurer notre application entièrement avec Maven :
- C’est nettement plus simple
- On a accès à tous les plugin Maven existants, et en particulier à l’excellent Maven Jetty Plugin : finie la vieille version de Jetty que nous devions utiliser sur l’application Scala, enfin un serveur d’application récent!
Nous allons en profiter pour faire du CDI et donc supprimer le singleton que nous avions codé en Scala.
Pour pouvoir construire notre projet :
- Clonez notre repository https://github.com/ippontech/primefaces-groovy-cassandra
- Lancez le projet avec Maven : “mvn jetty:run”
Utilisation de Groovy avec PrimeFaces
L’utilisation de Groovy est encore plus simple que celle de Scala. Voici le Bean “User” en Groovy :
Mise à part la syntaxe, qui est plus proche de Java et donc qui me parait plus naturelle, on remarque qu’il n’est plus besoin d’utiliser les annotations Scala @BeanProperty, que je finissais par trouver assez énervantes à écrire.Le résultat est certainement le code le plus simple et le plus concis que l’on pourrait écrire pour cette classe.
Concernant notre Controller, il se trouve modifié par l’utilisation de CDI (ce qui pour moi le rend plus propre que d’avoir un singleton codé en dur) mais reste assez similaire au code Scala :
Pour information, l’injection de dépendances ce déroulant après la construction de la classe, il n’était pas possible de faire comme en Scala et initiatiliser une variable “users” à la construction. Il aurait également été possible de l’initialiser via une méthode annotée @PostConstruct (qui est appelée après l’injection de dépendances), mais dans notre cas cela complexifiait le code sans rien apporter de plus.
Utilisation de Groovy avec Cassandra
Notre Repository Groovy est un peu plus conçis que sa version Scala, et sans doute plus lisible :
Plusieurs points sont intéressants sur ce code :
- Grâce à CDI et à l’annotation @ApplicationScoped nous avons évité de faire un Singleton
- Comme en Scala, nous n’avons pas à définir le type exact des objets lors de leur déclaration (en particulier la variable “rows” que nous avions vu en Scala)
- L’un des gros gains de Groovy dans cet exemple est qu’il permet d’utiliser directement des collections Java, ce qui nous fait gagner ici en concision (et simplifie aussi un peu le Controller que nous avons vu plus haut)
- Nous avons une structure très similaire à Scala pour parcourir nos résultats, et créer la liste finale
Une note sur les performances
Quelles sont les performances de notre application Groovy par rapport à sa version Scala ? On voit partout sur Internet que Scala étant un langage statiquement typé, ses performances sont bien meilleures – ceci étant généralement agrémenté d’un algorithme (type suite de Fibonacci) qui est très éloigné de notre réalité métier.
D’une part, cet aspect “compilation” sera réglé en Groovy 2.0, où il vous suffira de rajouter une annotation @CompileStatic pour avoir également une compilation statique en Groovy.
D’autre part, j’ai fait un test JMeter simple (disponible dans Github dans le répertoire src/test/jmeter) :
- L’application “Scala” a du mal à dépasser les 800 requêtes/seconde
- L’application “Groovy” fait une pointe à 5 000 requêtes/seconde
Attention ! Il ne faut pas du tout en déduire que Groovy est plus performant que Scala, mais que sur application “normale” (un CRUD, et non un algorithme particulier), l’ensemble des frameworks et outils utilisés est plus important que le langage : grâce à l’utilisation de Maven, nous avons en effet pu utiliser une version de Jetty plus récente, ce qui a certainement fait toute la différence.
Et au passage, vous aurez remarqué qu’une application JSF et CDI peut tenir 5000 requêtes/seconde…
En conclusion
Dans les deux cas, nous avons pu développer notre application JSF/Cassandra sans grande difficulté, avec un code plus conçis qu’en Java “classique”.
Le code Groovy est très proche du code Scala, et fonctionne de manière identique, tout en permettant de gagner en concision et en lisibilité. Le principal gain de Groovy, cependant, vient du fait qu’il ne change pas les outils habituellement utilisés, et permet en particulier de continuer à utiliser Maven.
