Spring Boot 2.3 est là

La dernière version de Spring boot est maintenant la version 2.3.

Pour rappel, Spring boot est un framework  qui simplifie le développement d’une application avec Spring. Il simplifie notamment la gestion des dépendances en s’assurant de la compatibilité entre les différentes librairies qui existent sur le marché. Il met également à disposition des développeurs des features productions ready.

Cette version 2.3 de Spring boot contient les mises à niveau classique des librairies :
– Spring Data Neumann : Spring JDBC 2.0 (avant 1.1), Spring Data MongoDB 3.0 (avant 2.2), Spring Data for Apache Cassandra 3.0 (avant 2.2), Spring Data Elasticsearch 4.0 (avant 3.2 before). Attention : Cette version contient une mise à jour des drivers de chaque système de persistance, donc, il y a potentiellement un breaking change par rapport à la version d’avant (Cassandra Driver 4.6, Couchbase client 3.0, Elastic search 7.6, Kafka 2.5, Micrometer 1.5.0, MongoDB 4.0).
– Spring HATEOAS 1.1
– Spring Integration 5.3 : implémentation des EIPs.
– Spring KAFKA 2.5
– Spring security 5.3
– Spring Session DragonFruit

Cette version supporte Java 14, en plus de la retro-compatibilité avec les versions 8 et 11.

Cette nouvelle version inclut également des nouveautés pour faciliter la construction d’une image docker à partir d’une application Spring boot via l’utilisation de buildbpacks.

Un mécanisme qui permet de s’assurer la terminaison de toutes les tâches en cours d’exécution a été mis en place avant l’arrêt de l’application Spring boot. Ce mécanisme est disponible sur tout les serveurs d’applications supportés par Spring boot.

Un endpoint dédié pour être utilisé par Kubernetes dans le cas d’une application déployé via K8S pour les liveness et readiness probe.

 

 

Les optionals dans Swift

La particularité de Swift par rapport aux autres langages modernes est qu’il n’est pas possible d’affecter une valeur null ou nil à un objet ou à un type primitif.

Le but d’Optional (C’est le cas également dans Java), c’est d’avoir un type qui peut retourner une valeur ou non.

Ce cas, on le retrouve typiquement pour les attributs d’un ViewController dans lequel un composant ne peut avoir une valeur qu’au moment où l’objet est instantié, donc qui peut être null jusqu’à la création de l’objet.

Par analogie, on peut considérer un type optional comme une boîte qui soit peut contenir une valeur soit rien (ou nil). Etant donné que c’est un type particulier, effectuer une opération entre un type optional et un vrai type n’est pas autorisé.

Mais d’abord comment définit-on un type optional dans Swift?

La syntaxe est assez simple car il suffit de rajouter un point d’interrogation à la fin de la déclaration de la variable. Ainsi, la variable suivante est un Optional de type String, var monStringOptional:String?

Maintenant qu’on a vue comment on crée la boîte, voyons comment on l’ouvre.

La syntaxe est simple car il suffit de rajouter un point d’exclamation à la fin de la variable au moment où on l’utilise. Exemple : monOptional!, mais ceci peut être dangereux car dans le cas où il n’y a rien dans la boîte, une erreur fatal sera levée.

Avant d’utiliser cette opérateur, on doit être sûr que l’optional contient une valeur.

L’alternative à l’opérateur point d’exclamation est l’utilisation d’un if let. If let permet de contrôler l’existence d’une valeur dans l’optional et de proposer un alternative dans le cas contraire.

La convention utilisée par la plupart des développeurs est d’utiliser le même nom de variable pour la variable wrappée dans un optional et la variable unwrappé. Ainsi on peut avoir quelquechose comme suit :

var foo:String?
if let foo = foo {
     dosomethingWith(foo)
}

Une autre notion qu’il est essentiel de connaître aussi pour pouvoir travailler avec les Optional est la notion de chaînage d’Optional. Un exemple vaut mieux qu’un long discours : myOptional?.type, le type de cette valeur est un optional du type type.

Une autre façon de déclarer un optional est d’utiliser l’opérateur point d’exclamation. Oui, l’opérateur point d’exclamation peut être utilisé pour ouvrir un Optional, mais également pour en créer un. A la différence qu’un Optional créé avec un point d’exclamation est implicitement unwrappé. A utiliser donc uniquement dans le cas où on est certain que l’Optional contient une valeur.

Une notion qui n’est pas tout à fait lié à un Optional, mais qui en utilise les concepts, c’est l’opérateur de downcasting as? et as!.

Si dans Java, lorsqu’on itère sur une liste d’objet d’un type parent contenant des objets de deux types filles différents, pour faire la distinction entre les deux classes filles on utilise l’opérateur instanceOf et on cas ensuite l’objet avec le type de la classe fille.

Dans Swift, le casting se fait via l’opérateur as?, celui-ci retournant un Optional, il faut faire un contrôle avec if let avant de pouvoir utiliser la valeur qui est retourné. L’opérateur as! est à utiliser si l’on est certain du type de la valeur qui est retourné.

L’optional n’est au final pas un concept si compliqué que ça. C’est juste une nouvelle notion à comprendre, et pour comprendre, il faut juste se familiariser avec.

La couche d’abstraction de cache fournit par Spring

Spring en lui même ne fournit pas de mécanisme de cache.

Par le biais des annotations @Cacheable, @CachePut, @Caching, @CachingConfig, @CacheEvict, Spring permet de s’abstraire de l’implémentation du cache utilisé. Cette abstraction est matérialisée par les interfaces Cache et CacheManager.

Pour activer l’abstraction de cache, il est impératif d’annoter un de vos classes de configuration avec @EnableCaching.

Si spring boot est utilisé l’annotation @EnableCaching peut être mis au niveau de l’application main.

Les résultats des méthodes annotés @Cacheable seront automatiquement mis en cache avec comme clé de cache le paramètre de la méthode (si la méthode prend plusieurs paramètres la règle est différente).
Il est cependant possible d’écrire un algorithme spécifique en implémentant la classe KeyGenerator. Il est egalement possible d’utiliser SpeL pour déterminer la valeur de la clé à utiliser.

@Cacheable peut définir les conditions pour lequel le retour de la methode sera mis en cache.

@CachePut permet de mettre à jour la valeur d’une donnée en cache. Le contenu de la méthode annotée @CachePut sera systématiquement exécuté.

@CacheEvict permet de supprimer un ou tout les éléments présents dans le cache. Il est possible d’indiquer si la suppression est à effectuer avant ou apres l’execution de la methode.

@Caching permet de combiner les annotations @Cacheable, @CachePut et @CacheEvict sur une seule méthode. Ceci permet d’appliquer des règles différentes en fonctions du cache utilisés, si plusieurs caches sont utilisées pour stocker les mêmes données.

@CacheConfig permet de définir une configuration commune à toutes les methodes d’une classe. Typiquement, cela peut etre le nom du generateur de cle, le nom du cache a utiliser.

Annotations personnalisés

Il est aussi possible de définir des annotations personnalisés en creant des annotations annotés avec les memes annotations que pour les methodes. Ces annotations pourront par la suite être réutilisés dans toutes votre application.

Solutions de caching en Java (JSR 107)

Pour rappel, la JSR 107 correspond à la spécification de l’API de caching en Java.

L’implémentation officielle de cette JSR est JCache.

Les solutions de caching actuelle implémentent tous cette API, notamment : EhCache, Hazelcast, Guava Cache, Caffeine, Gemfire cache,…

Ces implémentations fournissent un moyen de créer, d’accéder, de mettre à jour, et de supprimer les entrées d’un cache.

Pourquoi ou dans quel cas utiliser un cache?

Un cache est généralement utilisée pour améliorer la performance et la scalabilité d’une application.

L’idée du cache est de stocker temporairement une copie d’une donnée dont la récupération est soit coûteux, soit fréquent, ou dont la création prend beaucoup de temps.

Qu’est-ce qu’un caching?

Le caching, c’est donc la technique utilisée lors du développement d’une application permettant de stocker dans un système de persistence avec un délai de latence faible, ou une solution in-memory, une donnée dont la création est coûteuse et qui est susceptible d’être réutilisée par l’application plusieurs fois.

Les uses cases les plus courant sont :

  • Caching des réponses retournées lors de l’appel à un webservice
  • Caching du résultat d’un calcul coûteux
  • Caching de donnée
  • Caching de la réponse à retourner pour un servlet
  • Caching d’une graphe de domaine objet

Hibernate OGM, Jongo, Java MongoDb Driver, Morphia, Spring Data sont sur un bateau…

Hibernate OGM

Hibernate OGM offre l’avantage aux développeurs déjà familiers avec l’écosystème Hibernate l’adoption d’un nouveau framework.
On retrouvera les mêmes sémantiques que pour JPA, les concepts de JP-QL queries, de full text queries, etc.

En plus de MongoDB, Hibernate OGM supporte :

  • les systèmes de stockage à base de clé valeurs : InfiniSpan, EhCache
  • base de donnée basées sur les graphes : Neo4J
  • en cours : Redis, CouchDb, et Cassandra

L’avantage d’hibernate OGM, c’est qu’il est possible d’utiliser un unique framework pour pouvoir accéder à plusieurs types de bases de données.

Et comme pour hibernate ORM, il sera possible de ne pas choisir dès le début le système de stockage cible du système, la bascule d’un type de base à un autre sera simplifié par Hibernate OGM.

http://hibernate.org/ogm/

Jongo

Construire des requêtes pour Java comme sur un Mongo Shell.

Vous avez déjà un ensemble de script de requête que vous avez utilisé sur le shell de mongo, vous voulez continuez à utiliser vos objets modèles java annotés avec Jackson alors Jongo est fait pour vous.

La documentation est constituée d’une seule page, ce qui en fait un framework très facile à appréhender.

http://jongo.org

Java MongoDb Driver

C’est le driver officiel fournit par MongoDb sur laquelle se base tous les frameworks mentionnés dans cette article.

L’avantage à utiliser le driver MongoDb est que vous n’êtes pas contraint par une version spécifique qui serait liée à un framework.

L’inconvénient est l’obligation de réaliser des opérations au plus bas niveau.

Le driver comporte une version synchrone et une version asynchrone.

https://docs.mongodb.com/ecosystem/drivers/java/

Morphia

Dans la même veine que Hibernate OGM, Morphia est la solution proposée par MongoDb pour faire du mapping Objet vers base de donnée Mongo.

Les objets à persister sont annotés avec les mêmes annotations qui sont utilisées pour JPA ou JDO.

https://mongodb.github.io/morphia/

Kundera

Kundera est un concurrent à Hibernate OGM. JPA 2.1 compliant, il supporte en plus de MongoDb : Hbase, Apache Spark, Redis, Oracle Nosql, Kudu, ainsi que les bases de données relationnel.

Sans entrer dans les détails de ce framework, il n’est jamais prudent d’utiliser un outil capable de faire trop de choses à la fois.

https://github.com/impetus-opensource/Kundera/wiki/Kundera-with-MongoDB

Spring Data Mongodb

Dans la philosophie de Spring d’éliminer les codes boiler plate à travers un template, Spring data ne déroge pas à cette règle en proposant un MongoTemplate permettant de faire les différentes opérations CRUD sur une base de donnée MongoDB.

En plus du template, Spring data apporte des annotations permettant de faire du mapping Objet vers la base de données.

http://projects.spring.io/spring-data-mongodb/