Univers Devoxx
Devoxx en France, c’est plus de 2000 développeurs et plus de 200 speakers qui viennent apprendre et échanger autours de nombreuses technologies, outils et pratiques. C’est donc beaucoup de monde qui se regroupe pour assister à des conférences, des ateliers et des quick talks pendant trois jours. Cela fourmille donc de gens intéressants et intéressés.
Rencontre avec les exposants de Devoxx
La Devoxx France c’est d’abord les conférences et hands-on lab mais c’est aussi ses exposants qui viennent présenter leurs outils et services. C’est donc l’occasion d’en apprendre un peu plus sur un outil, de rencontrer les développeurs des solutions que l’on utilise, d’en découvrir de nouvelles et de se tenir informer de l’évolution du marché.
Elasticsearch
J’ai pu discuter avec l’équipe Elasticsearch, présente le mercredi. Pour rappel Elasticsearch est un index de recherche disposant d’une interface REST. Mais Elasticsearch n’est pas le seul produit qu’ils proposent. Kibana, logstash et beats font aussi parti des outils proposés.
Logstash est un outil de parsing de logs. Il permet de récupérer des logs applicatifs ou d’outils pour les parser, les enrichir et les envoyer vers une base de stockage, Elasticsearch par exemple.
Kibana vient ensuite requêter Elasticsearch pour créer des dashboards et des graphs permettant de visualiser ces logs, ou tout autre donnée présente dans Elasticsearch.
A la place de logstash nous utilisons les Beats qui sont des agents spécialisés et ultra-légers pour récupérer des informations (logs ou autres). En effet logstash est un peu gourmand en ressources, au contraire des Beats. Ces agents spécialisés (ils sont liés à un outil, Apache par exemple) récupèrent les logs de vos outils pour les envoyer vers Elasticsearch ou logstash (pour les enrichir). Les Beats viennent aussi avec leur dashbord kibana, ce qui est très pratique lors de la première mise en place d’une stack elastic.
Les conférences Devoxx
L’event sourcing possible avec CQRS
Event Sourcing
Greg Young popularise l’event sourcing. L’idée part du constat que nous stockons dans les bases de données, l’état courant de l’application. Ceci présente plusieurs problèmes dont deux principaux :
- l’évolution des demandes métiers amène à revoir souvent le modèle de représentation de cet état
- lors de la modification de l’état, nous perdons des informations importantes : quel est ce changement, qui l’a demandé, quel était l’état avant le changement.
L’event sourcing propose donc de ne plus stocker un état mais plutôt d’enregistrer les événements qui surviennent au sein du système. En stockant les événements, il n’y a plus de modification du modèle de données, seulement de nouveaux événements. Il devient également possible de récupérer une donnée à n’importe quel moment dans le temps en rejouant les événements jusqu’à cette date.
Pour récupérer l’état actuel d’une donnée, il faut récupérer tous les événements ayant eu lieu sur cette donnée puis les rejouer dans l’ordre : c’est le replay. Lorsque nous rejouons tous nos événements dans notre système, nous créons ce qu’on appelle une projection. Une projection est une représentation particulière de l’ensemble des événements ayant eu lieu dans le système, c’est la représentation d’un état. Il est possible de créer différentes projections pour différents usages. Nous éliminons alors le problème de la représentation unique de l’état dans les systèmes classiques. Le modèle de données n’est souvent pas adapté à la représentation que nous souhaitons avoir. Une projection étant créée à partir de l’ensemble des événements, en créer plusieurs est facile.
Nous modifions donc notre système en créant des événements mais nous récupérons les informations de celui-ci via les projections.
CQRS
Cette séparation des parties command et query d’une application est un pattern d’architecture appelé CQRS (Command Query responsability ségrégation). CQRS n’est pas apparue avec l’event sourcing, seulement, la complexité apportée par l’event sourcing peut être gérée avec CQRS. Le pattern CQRS prend ses fondations dans un constat simple : dans la plupart des systèmes il y a beaucoup plus d’écritures que de lectures. Ces lectures ont également des formes plus variées. CQRS propose alors de séparer complètement votre application en deux : Une partie lecture et une partie écriture. Cette séparation ira jusqu’à la base de données. Les commandes écriront donc sur un support différent de ceux auprès desquels la partie query ira chercher ses informations.
Bien sûr, comme tout outil CQRS et EventSourcing sont des outils et non des Silver Bullets !
Durant Devoxx, l’atelier CQRS/ES nous a permis de mettre cela en pratique. Partant d’une base de code existante, nous avons ajouté nos propres gestions et création d’événements ainsi que des projections spécifiques.
La présentation est disponible ici : https://www.youtube.com/watch?v=S1V4t7SXXCU L’exercice est disponible ici : https://github.com/DevLyon/mixter
Javaslang
Javaslang (renommé vavr depuis) est une librairie pour Java. Son objectif est de rendre plus facile la programmation fonctionnelle en Java et d’aller plus loin que Java 8. L’occasion de voir comment l’utiliser !
La présentation est disponible ici : https://www.youtube.com/watch?v=IIWWvvZn9SA
JOOQ
En Java, pour accéder à une base de données, deux solutions sont très utilisées : les ORM (Hibernate, Eclipse link, ..) et des requêtes SQL via JDBC. Cependant, ces deux techniques ont des inconvénients. Les ORM sont très bien adaptés pour faire du CRUD (Create, Read, Update, Delete) simple mais ne sont pas à l’aise avec les requêtes complexes. De l’autre coté, l’utilisation du SQL via JDBC permet d’écrire toutes les requêtes SQL imaginables mais la maintenance en est douloureuse. Au renommage d’une table on doit repasser sur toutes les requêtes. Les requêtes SQL ne sont pas type safe. JOOQ pour Java Object Oriented Query propose une librairie et des outils pour générer un DSL de votre base de données qui pourra être utilisé pour créer des requêtes. Les requêtes vers votre base de données deviennent donc type safe et la maintenance est facilité.
Voici un exemple d’écriture de requête :
create.selectFrom(BOOK)
.where(BOOK.PUBLISHED_IN.eq(2011))
.orderBy(BOOK.TITLE);
La présentation réalisé à Devoxx est disponible ici : https://www.youtube.com/watch?v=Gev7iQ5_VCA
Auteur : Maxime G. Développeur Java Angular chez NOVENCIA Group
