Devoxx France 2016 : Backend

Cet article présente les différentes conférences Backend vues lors du Devoxx France 2016 :

Le design d’API REST, un débat sans fin

Orateur Guillaume Laforge, vu par Valentin GOT

A quoi devrait ressembler une bonne API REST ? C’est la question à laquelle tente de répondre Guillaume Laforge tout du long de cette conférence. Il nous offre ses conseils et différentes options possibles sur quelques-uns de ces éternels débat de la conception d’APIs REST.

Tout d’abord, il commence la présentation par quelques bonnes pratiques basiques du design d’API REST, comme l’utilisation du pluriel et non du singulier (http://api.co/cars/1234) ou de privilégier les noms plutôt que les verbes (uniquement pour des actions, comme la connexion).

Ensuite, il propose différentes solutions concernant le nommage des URLs, qui sont respectivement l’UpperCamelCase, le lowerCamelCase, le snake_case ou encore le dashed-snake-case. Pour vous aider à choisir, après un rapide vote à mains levées, ce sont le lowerCamelCase et le dashed-snake-case qui l’emportent haut la main. Il enchaine ensuite sur les bons statuts HTTP à utiliser, évitons le 200 OK en toutes circonstances !

Pour finir, il nous montre comment rester RESTful dans ces cas assez spécifiques et récurrents que sont le caching, la pagination, le filtrage, le tri ou encore la recherche, et termine par les différentes manières de gérer le versionnage d’une API.

 

Comme il le dit lui-même et comme l’annonce très bien le titre de cette conférence, la création d’API REST est, et restera toujours, un long débat sans fin. Chacun adopte ce qu’il pense être sa bonne pratique, et au final, tout ce qui compte c’est l’homogénéité au sein même d’un projet. Néanmoins, une présentation très intéressante, dynamique et participative qui permet de (re)découvrir certains bon concepts et parce qu’il est toujours bon de réviser un peu.

Les slides / La vidéo

 

Gradle: Harder, Better, Stronger, Faster

Orateur Andres Almiray, vu par Aurélien BAUDET

Andres Almiray compare Gradle avec Maven et tente de prouver que Gradle est bien meilleur que Maven.

Il commence par nous montrer que la syntaxe de Gradle est beaucoup plus légère. Le XML de Maven ajoute beaucoup de bruit et noie la partie utile (code utile en bleu) :

Gradle est fait pour builder un projet indépendamment du langage contrairement à Maven qui n’est pensé que pour Java. De plus, à l’origine, Maven n’était pas fait pour du multi-projet : cette possibilité a été introduite via héritage d’un POM parent ce qui a des limitations. Gradle est quant à lui pensé pour traiter efficacement le multi-projet.

Gradle est également moins verbeux que Maven. L’exécution du build n’affiche que les tâches exécutées et le résultat. Pas de logs inutiles lorsque tout se passe bien. La vision est claire sur le résultat du build :

Le daemon évite les phases d’initialisation de l’outil à chaque build et augmente donc les temps d’exécution. De plus, Gradle met en cache les entrées/sorties de chaque tâche. Ceci permet de ne réexécuter que les tâches qui ne sont pas à jour.

Une fois l’éloge de Gradle faite, Andres Almiray nous démontre tout ça en comparant sur un projet Java qui va générer une application exécutable et qui génèrera également un installateur. La démonstration prouve que la configuration Gradle est beaucoup moins verbeuse que Maven et montre une meilleure efficacité du build.
Gradle ne proposant pas pour le moment d’équivalent des archetype Maven pour utiliser un template de projet, Andres nous présente donc rapidement Lazybones pour combler ce manque et également Sdkman pour simplifier l’installation de notre environnement de développement (les deux sont valables pour Maven aussi).

 

J’ai trouvé cette conférence intéressante pour comprendre les apports de Gradle qui semble prometteur. Cependant le choix de l’exemple n’est pas le meilleur à mon avis. En effet, choisir de comparer Maven et Gradle sur la création d’un JAR exécutable avec installateur n’est pas représentatif des projets réalisés tous les jours. De plus, on compare surtout les plugins utilisés plus que les outils de build. Son exemple montre qu’il faut 3 plugins Maven là où Gradle fournit un plugin tout en un. On compare donc l’approche entre créer 3 plugins chargés chacun d’une seule responsabilité et de leur composition (ce qui certes peut être complexe) versus un plugin qui fait tout et qui sera plus difficilement réutilisable dans un autre contexte (on risque d’avoir plusieurs plugins similaires à terme). En résumé Andres compare réutilisation et composition versus duplication. J’aurais préféré voir les avantages de Gradle concernant la réutilisation et la factorisation de la configuration au sein d’une organisation.

Les slides / La vidéo

 

OutOfMemoryException : Quel est le coût des objets en Java ?

Orateur Jean-Philippe Bempel, vu par Nicolas Roussel

L’équipe de Jean-Philippe Bempel a observé que la majorité de l’espace occupé dans la Heap concerne les structures et non les données en elles-mêmes. Fort de ce constat, celui-ci nous explique assez longuement comment calculer la taille d’un objet Java en s’attardant sur les paddings et l’option CompressedOops de la JVM. Une fois les tailles des classes Object et String explicitées, Jean-Philippe se concentre sur les structures en visitant tour à tour les tableaux, les LinkedLists, les ArrayLists, les HashMaps, les TreeMaps, et enfin les ConcurrentHashMaps. Le tableau suivant résume le surcoût des structures pour 100 éléments (on voit au passage que passer en Java 8 permet d’économiser de la mémoire si vous utilisez des ConcurrentHashMap).

Une fois ces bases rappelées, Jean-Philippe nous propose quelques outils qui peuvent être utilisés pour réaliser un diagnostic suite à une erreur « Out of memory ». Le premier d’entre eux, l’histogramme de classe, permet de connaitre la mémoire utilisée par chaque classe et ainsi savoir vers où concentrer ses recherches. Pour l’utiliser, rien de plus simple : jmap -histo . Notons au passage qu’il est possible, grâce à l’option -XX+PrintClassHistogramBeforeFullGC de la JVM, d’inclure l’histogramme de classes dans les logs du garbage collector juste avant un Full GC…
Ce qui semble en effet assez pratique et donne ce type de résultat (issu d’un projet Spring) :

Le Heap Dump, davantage connu, permet quant à lui de faire un « dump de la Heap »… Ca ne s’invente pas ! Pour exploiter le résultat, visualVM et YourKit semblent tout indiqués : privilégiez-les à Eclipse MAT qui est beaucoup trop gourmand. Gardez en tête qu’il vous faudra autant de mémoire que la taille du Heap Dump, donc que cette analyse n’est pas anodine.

 

En conclusion : les outils permettant de faire des diagnostics de mémoire de la JVM existent et il ne faut pas hésiter à les utiliser en cas de soucis. On aurait aimé voir abordés d’autres problématiques que celles liées aux structures, mais le propos de Jean-Philippe était dans l’ensemble vraiment intéressant et pertinent. Enfin, pour éviter que ces OutOfMemoryException liées aux structures ne se produisent, voici quelques petits conseils :

  • Pensez à utiliser le pattern « Poids-mouche » quand c’est pertinent
  • Oubliez les LinkedList au profit des ArrayList
  • Au cas par cas, il peut être intéressant de remplacer les HashMap par des
  • OpenAdressingHashMap, dont on trouve des implémentations assez facilement

Les slides / La vidéo

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

19 − quatre =