Être productif

avec JHipster

Devoxx France 2017

Julien Dubois
Créateur de JHipster
Directeur de l’innovation, Ippon
Technologies

@juliendubois
@java_hipster
Quelques mots sur Ippon Technologies

300 consultants: France, USA, Australie

Spécialisés en Java, Cloud, Big Data…
On recrute! Rejoignez-nous sur le stand “JHipster”, à
côté du buffet :-)
Spring Framework
Spring Boot
JHipster
Introduction à JHipster

Générateur d’applications Spring Boot +

Angular(JS)

Totalement Open Source

+ de 300 contributeurs

6,500 étoiles GitHub

1/2 million d’installations

+ de 150 sociétés officiellement utilisatrices

Technologies côté serveur
Technologies côté client
 Partie 1

Installation

Génération d’une application

 Installation

Utilisation de Yarn

Alternatives: JHipster Devbox, Docker

> yarn global add generator-jhipster

 oh-my-zsh

oh-my-zsh est un framework pour gérer sa

configuration ZSH

JHipster possède son propre plugin pour oh-my-

zsh
Nous conseillons également les plugins: git, docker et docker-
compose

> jh
 Création d’une application

Répondez aux questions pour générer une

application suivant vos besoins

Certaines questions dépendent des réponses

précédentes

JHipster fournit de la validation et des aides pour

éviter les erreurs
> mkdir monapplication && cd monapplication

> yo jhipster
 Configuration de l’IDE

Support des IDEs majeurs

IDEA, Eclipse, Netbeans

Visual Studio Code

> idea pom.xml

 Fichiers générés

Une application Spring Boot

Une application Angular(JS)

Un changelog Liquibase

Des fichiers de configuration

Les écrans générés: la sécurité
Ecrans classiques pour une application sécurisée
Login, logout, mot de passe oublié…

Gestion de compte utilisateur

Gestion des utilisateurs

Ces écrans sont utiles pour la plupart des applications

Les pages doivent être modifiées en fonction des besoins

Les permissions des utilisateurs seront modifiées ou étendues

Ils fournissent aussi des exemples d’écrans

Plus complexes que des “CRUD”

Formulaires, directives, validation…

Les écrans générés: administration

Ecrans d’administration
Monitoring

Santé

Configuration Spring Boot

Gestion des logs

Très utiles en production

Seront optionnels dans une prochaine version

Utilisation de Maven/Gradle

Wrappers pour Maven et pour Gradle

Pas d’installation nécessaire, toute l’équipe a la même version

Tâches classiques: clean, compile, run, test…

Profils spécifiques: “dev” et “prod”

> ./mvnw clean test

Docker et Docker Compose
JHipster génère une configuration complète pour
Docker et Docker Compose
Création d’une image Docker pour l’application

Lancement des services: MySQL, Elasticsearch, Kafka…

Sonar

Particulièrement utile pour le développement et les

microservices

> docker-compose -f src/main/docker/mysql.yml up -d

Support des bases SQL

Utilisation de bases différentes en

développement et en production

H2 disponible avec persistance sur disque ou en

mémoire

Bases de données supportées: MySQL, MariaDB,

PostgreSQL, Oracle, SQL Server

Spring Data JPA

HikariCP
 Liquibase

Gère les évolutions de la base de données

Très utile pour travailler en équipe

Après un “git pull”, votre base de données est prête!

Les tables, les relations et les données sont

toutes créées par JHipster lors de la génération,
et ces évolutions sont appliquées au démarrage
de l'application
Le cache de 2nd niveau Hibernate
3 options de cache pour Hibernate
Pas de cache

Ehcache

Cache par défaut pour les monoliths

Contribution de l’équipe Ehcache: passage à la version 3 et configuration Java

Hazelcast

Cache par défaut pour les microservices

Clustering automatique du cache en cas d’ajout de nouvelles instances de

l’application

Monitoring automatique
Attention! La configuration par défaut doit être optimisée en fonction des
besoins et du matériel disponible
 Spring Cache

Spring Cache est configuré de la même manière

que le cache de 2nd niveau Hibernate
Permet de le remplacer dans des cas métiers précis
 Hazelcast

Hazelcast permet d’avoir un cache distribué

Les nouvelles instances d’un service rejoignent un cache
distribué global

Essentiel pour pouvoir monter en charge

C’est pour cela que c’est la solution par défaut pour les
microservices

Cette solution utilise le JHipster Registry pour

que les instances se connaissent
Fonctionne pour les microservices et les monoliths
 MongoDB

Alternative aux bases SQL

Plus rapide à démarrer, très simple à utiliser dans

le cloud

Spring Data MongoDB

Les changelogs sont gérés par Mongobee

 Cassandra

Une autre alternative aux bases SQL

Implémentation spécifique JHipster, utilisant

directement le driver DataStax

Le support Cassandra dans Spring Boot provient

de JHipster!
 Elasticsearch

Option supplémentaire, en complément des

autres options
Très populaire!

Utilise Spring Data Elasticsearch

Génère le code côté serveur ET côté client

Utilise par défaut un Elasticsearch embarqué

pendant le développement, une image Docker
est également proposée
 Kafka

Autre option supplémentaire

Pour gérer des flux importants de données

Certains projets l’utilisent pour gérer les flux et le fail-over

dans leur architecture microservices

Utilise Spring Cloud Stream

L’intégration actuelle est encore basique

 La sécurité
Utilise Spring Security

Sécurité par session

Stateful

Authentification “par formulaire” classique de Spring Security

Améliorations importantes de JHipster dans la gestion du “remember me”

JWT
Stateless

Option de plus en plus populaire

Parfait pour les microservices

OAuth2
Nécessite une persistance spécifique (fonctionne uniquement avec bases de données SQL
et MongoDB)

En beta : utilisation de JHipster UAA

 Internationalisation

30 langues sont supportées par défaut

Simple à étendre si nécessaire

Côté client, géré par Angular Translate

(AngularJS 1) ou une directive spécifique (Angular
2+)

Côté serveur, le système standard de Java

 Swagger

Documentation automatique de toutes les APIs

REST

Swagger UI permet de tester et exécuter

facilement les APIs

Parfait pour les développeurs Angular(JS) qui ne

veulent pas lire le code Spring!

Architecture microservices: Agrégation des APIs

dans une gateway
 WebSockets

Option complémentaire

Utilise Spring WebSockets

Simple à intégrer

Difficile à monter en charge sur plusieurs noeuds

Ecran par défaut permettant de suivre les

utilisateurs en temps réel
Mettre à jour une application

Les mises à jour peuvent être faites manuellement

ou automatiquement

La mise à jour “automatique” utilise des branches

Git pour tenter un merge entre le code modifié par
les développeurs, et la nouvelle version du code
Utilisations des outils standards Git pour gérer les conflits

> yo jhipster:upgrade
 Partie 2

Tester l’application générée

Tests avec JUnit et Spring

JHipster propose un support de JUnit et des

tests d’intégration avec Spring
Les tests d’intégration restent rapides, car le contexte Spring
et la base de données sont ré-utilisés entre chaque test

Mockito est utilisé pour simuler les dépendances

L’annotation @WithMockUser de Spring Security est très utile

Nous utilisons l’injection par constructeur pour simplifier les

tests

Le sous-générateur d’entités génère des tests

spécifiques à chaque opération CRUD
Tests unitaires avec Karma.js

Les tests unitaires sont générés pour l’application

principale et les entités
Des mocks sont utilisés pour simuler les appels au serveur
Tests de performance avec Gatling

Option pour réaliser des tests de performance

Des scénarios de test sont générés avec chaque entité

Utilisent les 4 méthodes CRUD générées

Doivent être modifiés en fonction des besoins métier

Astuce (bis) : n’oubliez pas la pagination!

Les tests peuvent être lancés directement depuis Maven

Les simulations sont développées avec un DSL Scala

Facile à prendre en main

La compilation Scala reste lente au démarrage

 Cucumber

Autre option possible

Les tests comportementaux (“BDD”) sont de plus

en plus populaires

Cette intégration reste basique pour l’instant

Il manque des tests CRUD pour les entités générées

On recherche des volontaires!

 Protractor

3ème option possible pour les tests

Solution officielle et complète pour tester une

application Angular(JS) de “bout en bout”
Nécessite un serveur Java fonctionnel

Utilise Chrome par défaut

pas nécessairement disponible avec les installations Linux par défaut

mais pose moins de soucis que Firefox!

Etude de la qualité du code avec Sonar

Sonar permet d’avoir un audit complet de la qualité de

l’application
Java et JavaScript pour les applications avec AngularJS 1

Java uniquement pour les applications Angular 2+

JHipster fournit une configuration Docker Compose

permettant d’avoir facilement un serveur Sonar et de
tester son code

> docker-compose -f src/main/docker/sonar.yml up -d

> ./mvnw clean test sonar:sonar
Intégration continue / déploiement continu

Nouveau sous-générateur “ci-cd”

Permet de générer une configuration pour les 4

principaux serveurs d’intégration continue
Travis, Jenkins, GitLab, CircleCI

Propose ensuite un déploiement automatique sur

Heroku
> yo jhipster:ci-cd
 Partie 3

Travailler avec une application

générée
Un environnement de travail performant

Le “developer experience” (DX) est

particulièrement important pour JHipster
Un très gros travail est fait pour proposer un environnement de
travail productif et agréable

Le rechargement à chaud doit fonctionner partout

Les IDEs doivent être configurés

automatiquement

Tous les services tiers utilisés ont une

configuration Docker Compose prête à l’emploi
 Spring Boot devtools
Rechargement à chaud de l’application Java
Le classloader de l’application est rechargé

La JVM continue de fonctionner

Très rapide: entre 2 et 4 secondes, en fonction du

setup

JHipster gérant les changelogs Liquibase, la base de

données est également mise à jour à chaud

Astuce : avec un IDE configuré pour compiler

automatiquement le code source, tout est mis à jour
automatiquement!
 Spring Data JPA

Génère des requêtes SQL directement depuis

des noms de méthodes Java
List<Product> findByOrderByName()

List<Item> findByUser(User user)

List<Customer> findByLastName(String lastName)

Astuce : tapez le nom de la méthode voulue

dans le contrôleur REST qui l’utilise, et demandez
ensuite à votre IDE de générer la méthode
Méthodes “fluent” dans les entités

Les entités JPA peuvent avoir des méthodes

“fluent”
Validé par l’équipe Hibernate, suite à une discussion initiée
par l’équipe JHipster!

Permet d’enchaîner les méthodes sur les entités

Post post = new Post()

.title("Fluent methods are cool!")
.createdOn(LocalDate.now())
.addPostComment(postComment);
 Liquibase

Les changelogs sont générés par JHipster, et peuvent aussi

être codés manuellement

Ils peuvent aussi être générés par la tâche Maven

“liquibase:diff”
Modifier le code JPA

Compiler l’application

Lancer “./mvnw liquibase:diff”

Un nouveau changelog sera généré

Le rajouter dans le changelog principal “master.xml”

Les changelogs sont appliqués au démarrage de l’application

(fonctionnent également lors du hot reload de Spring Boot)
 Profils
JHipster propose deux profils disponibles à la fois au
runtime (profils Spring) et au moment du build (profils
Maven/Gradle)
Profil “dev” pour le développement : focus sur une excellente “Developer
Experience”

Profil “prod” pour la production : focus sur la performance

D’autres profils sont disponibles dans des situations

spécifiques
“swagger” pour utiliser (ou pas) Swagger

“no-liquibase” pour que l’application Spring ne lance pas Liquibase

“ide” utilisé avec Maven pour aider à la configuration des IDEs (en
particulier avec MapStruct)
Configuration spécifique JHipster
JHipster génère une application Spring Boot
Toutes les configurations Spring Boot “standards” sont donc
supportées

JHipster rajoute son propre préfixe “jhipster” avec

sa configuration spécifique
Type-safe, documentée, et configurable de la même manière que
les configurations “standards”

JHipster génère également une configuration vierge

avec le préfixe “application”
Tout est prêt pour ajouter une configuration spécifique à
l’application en cours, en suivant les mêmes principes
Exemple: mettre en place HTTP/2

Dans les fichiers de configuration “application-

*.yml”
Configurer Spring Boot pour prendre en charge le SSL

Configurer JHipster pour utiliser HTTP/2

server:
port: 8443
ssl:
key-store: keystore.p12
key-store-password: <your-password>
keyStoreType: PKCS12
keyAlias: tmp2

jhipster:
http:
version: V_2_0
AngularJS 1.x - Gulp & BrowserSync
Gulp permet de lancer de nombreuses tâches liées au
JavaScript: la minification, l’injection des dépendances, les
tests…

Une de ses utilisations principales avec JHipster est le

lancement de BrowserSync

BrowserSync propose deux fonctionnalités majeures

Synchronisation des clicks, scrolls et inputs dans les différents navigateurs:
parfait pour tester son application sur plusieurs écrans!

Rechargement à chaud des navigateurs quand le code est modifié: parfait pour
le développement productif!

Astuce : en combinant BrowserSync, Spring Boot devtools et

Liquibase, un environnement de développement JHipster
propose le “hot reload” de l’ensemble de l’application!
 Angular + BrowserSync

Avec Angular, JHipster propose un fonctionnement

similaire

Webpack est utilisé pour toutes les tâches du front-

end: compiler le code TypeScript, lancer les tests, etc.

Webpack permet également de lancer BrowserSync

et d’avoir les mêmes fonctionnalités qu’avec
AngularJS 1

Astuce : pour débugger le code Angular (compilé

depuis le TypeScript), nous conseillons Augury, un
plugin Chrome/Firefox
 AngularJS 1 + Bower

Bower permet d’installer des librairies JavaScript/

CSS

Ces librairies sont automatiquement injectées

dans le fichier index.html

> bower install bootstrap-material-design#0.3.0 —save

 Angular + Yarn

Avec Angular, JHipster migre de Bower vers Yarn

Plus sécurisé et plus performant que Bower

Permet des builds vraiment reproductibles

Utilise un cache

> yarn install

Développer avec AngularJS 1.x
JHipster suit le guide de style de John Papa
Guide de style officiel, validé par l’équipe AngularJS

Contient de nombreuses règles et bonnes pratiques, clairement

expliquées

Propose un chemin de migration vers Angular 2

JHipster utilise également quelques librairies tierces

UI Router pour le routage

Bootstrap

De nouvelles librairies peuvent facilement être

installées grâce à Bower
Développer avec Angular 2+

JHipster supporte Angular 2 depuis la sortie de

JHipster 4 en Février 2017
Dans notre branche de développement nous sommes déjà sur
Angular 4, qui sera disponible lors de notre prochaine release

Cette option est encore en BETA mais de

nombreuses personnes l’utilisent déjà
Notre build de “prod” doit encore être amélioré

Nous souffrons (comme tout le monde) de librairies tierces qui

ne sont pas encore toutes au niveau
Personnalisation de Bootstrap

JHipster utilise les classes standard de Bootstrap

Il est très simple d’installer un thème spécifique

Ces classes peuvent être personnalisées normalement

JHipster propose en option le support de Sass, pour plus de

simplicité

Avec Angular, JHipster a dû passer à Bootstrap 4,

qui est encore en version Alpha
cf. slide précédent sur les librairies tierces qui ne sont pas à
jour
 Partie 4

Générer des entités

 Création d’une entité
Le sous-générateur d’entité est notre option la plus
populaire

Génère une entité avec support CRUD complet

Changelog Liquibase

Spring Data JPA

Spring MVC REST

Angular(JS)

i18n

tests

Astuce : utilisez Git pour sauvegarder votre travail avant/

après une génération!
 Création des champs

Les champs sont créés les uns après les autres

De nombreux types de données sont disponibles

Ces types dépendent de la base de données utilisée

La validation est disponible

Angular(JS) côté client

Bean Validation côté Spring MVC REST et Hibernate

Contraintes dans la base de données

Gestion des relations entre les entités

Les relations ne sont disponibles que pour les

bases SQL

Tous les types de relations JPA sont présents

one-to-one, many-to-one, one-to-many, many-to-many

Les relations sont bi-directionnelles par défaut,

mais peuvent aussi être uni-directionnelles

On peut réaliser plusieurs relations entre deux

entités données
 L’entity “User”
“User” est une entité spécifique, générée avec
l’application d’origine
Utilisée par Spring Security

Peut être étendue

Peut être utilisée dans des relations many-to-one,

many-to-many (côté non propriétaire) et one-to-one

Astuce : certaines personnes utilisent une relation

one-to-one vers une entité spécifique
“CustomUser” qu’ils maîtrisent, afin de ne pas
toucher à l’entité “User” d'origine
 Utilisation des DTOs

DTOs = Data Transfer Objects

Utiles dès que l’on a un métier plus compliqué

que du CRUD
Ajout de logique métier

Séparation de la vue et de la couche de persistance

Résout les problèmes de lazy-loading

JHipster utilise MapStruct pour gérer le mapping

des DTOs et des entités
Utilisation d’une couche de service

Très utile pour les applications métier, où un CRUD

n’est pas suffisant
Comme pour les DTOs

Habituellement la couche service et les DTOs sont deux options

utilisées conjointement, mais cela n’est pas une obligation

Les Beans de service sont des Beans Spring: la

sécurité, les transactions, le monitoring sont
disponibles

Option pour utiliser juste une implémentation, ou

une interface + une implémentation
 Options de pagination
3 options de pagination sont disponibles
“Pager” simple (uniquement pour AngularJS 1.x)

liens de pagination

scroll infini

Dépend de vos besoins business et de votre base de

données (Cassandra ne peut pas gérer de liens de
pagination)

Nécessaire quand vous avez beaucoup de données (donc

tout le temps, hormis pour des tables de références)
Attention! Une erreur classique lorsque l’on fait des tests de performance
avec Gatling, est d’avoir oublié de mettre en place la pagination
 Re-générer une entité

Une entité peut être re-générée

Il suffit de relancer une génération avec le même nom d’entité

Les champs et les relations peuvent alors être ajoutés et/ou

supprimés

Astuce : les utilisateurs avancés modifient

directement les fichiers `.jhipster/*.json`
Ce sont les fichiers internes de configuration

En réalité, ils contiennent juste les réponses sauvegardées au

format JSON
 Partie 5

Outillage et projets tiers

JHipster Domain Language

Rend facile la génération de modèles d’entités

complexes
Supporte toutes les options du sous-générateur d’entités
Types de champs

Validation

Relations

DTOs

Services

Enumérations

…
 JDL Studio

Application Web Open Source

Disponible librement sur https://jhipster.github.io/jdl-studio/

Auto-complétion et validation du JDL

Vue graphique

Import/export de modèles
 JHipster IDE

Support du JDL dans

les IDEs
Fonctionne avec Eclipse,
IDEA, Visual Studio Code

Permet de travailler
directement sur le fichier sans
devoir le télécharger
 Modules
Les modules permettent à chacun de bénéficier de la
puissance de JHipster sans dépendre du projet
Les modules sont indépendants de JHipster

Ce sont des générateurs Yeoman qui utilisent l’API de JHipster

Ils peuvent être privés et avec des licenses propriétaires

Si vous souhaitez que votre module soit public, vous

pouvez le publier sur notre marketplace
Disponible sur https://jhipster.github.io/modules/marketplace

32 modules disponibles à l’heure actuelle

La marketplace est entièrement libre et gratuite, comme toujours avec

JHipster!
 Partie 6

Passer en production
Construire une application pour la production

JHipster utilise le plugin Spring Boot pour

générer une application de production
WAR “exécutable” (option chaudement recommandée) ou
deployable dans un serveur d’applications

Avec des options de production côté Java: filtre GZip, cache…

Et un front minifié

> ./mvnw clean package -Pprod

> docker-compose -f src/main/docker/mysql.yml up -d
> cd target
> ./monapplication-0.0.1-SNAPSHOT.war
 Monitoring disponible

Les endpoints “standards” de Spring Boot sont disponibles

Avec une interface graphique!

Dropwizard Metrics est configuré

Métriques JVM et HTTP

Métriques des Beans Spring

Métriques ehcache

Les logs peuvent être envoyés vers ELK

Plus d’informations sur la “JHipster Console” dans la partie microservices

Prochaine version : un monitoring unifié sera bientôt

disponible dans le JHipster Registry!
Création d’une image Docker
Une configuration Docker complète est générée dans
le répertoire src/main/docker
Un DockerFile

Une configuration Docker Compose comprenant l’application et

l’ensemble de ses dépendances

Le daemon Docker doit être lancé lors de la

construction de l’image

> ./mvnw package -Pprod docker:build

> docker-compose -f src/main/docker/app.yml up -d
Le sous-générateur “docker-compose”

Fonctionne pour les monoliths et les

microservices

Permet des configurations plus avancées que les

fichiers Docker Compose générés par défaut
Configuration du JHipster Registry et de la JHipster Console

Surtout intéressant pour les microservices, en développement

comme en production
Docker Compose et Docker Swarm

La configuration Docker Compose permet de déployer les

applications sur un cluster Docker Swarm
Avoir un cluster Docker Swarm en production n’est pas facile :-)

Permet d’avoir la même configuration en développement et en production

Les applications peuvent ensuite avoir de nouvelles instances

créées suivant les besoins
Fonctionne sans problème pour les microservices

Une gateway ou un load balancer sont disponibles pour éviter les conflits de ports

Le cache de 2nd niveau Hibernate doit pouvoir être distribué (Hazelcast) ou être
désactivé

> docker-compose scale myapplication-app=3

 Support de Rancher

Prochaine version : le sous générateur “rancher-

compose” est en cours de validation
Nous recommandons vivement l’utilisation de Rancher avec
Docker

Ce sous-générateur permettra de générer le fichier “Rancher

Compose” spécifique à Rancher

> mkdir rancher && cd rancher

> yo jhipster:rancher-compose
 Support de Kubernetes

Kubernetes est l’orchestrateur de containers

Docker le plus populaire
Support dans JHipster initialement développé par Ray Tsang,
de Google

> mkdir kubernetes && cd kubernetes

> yo jhipster:kubernetes
 Support de Cloud Foundry

Sous-générateur spécifique Cloud Foundry

Le JHipster Registry permet de remplacer les services Eureka et
Spring Cloud Config fournis par défaut par Pivotal

Utilise la ligne de commande “cf” pour déployer

l’application, la lier à une base de données, etc.
Ne supporte que les services disponibles dans votre marketplace

> yo jhipster:cloud-foundry
 Support de Heroku

Sous-générateur spécifique pour Heroku

Développé et maintenu par Joe Kutner, de Heroku

Utilise la ligne de commande “heroku” pour

déployer l’application, la lier à une base de
données, etc.

> yo jhipster:heroku
Autres plateformes de déploiement

AWS

BoxFuse

Serveurs d’applications Java EE

WAR exécutable
 Partie 7

Architecture microservices
Architecture microservices
JHipster propose une architecture microservices complète

Une ou plusieurs Gateways qui fournissent l’accès à

l’architecture
Basée(s) sur Netflix Zuul

Ajoute la sécurité, la qualité de service, la documentation d’APIs…

Le JHipster Registry fournit un dictionnaire de services, un

serveur de configuration Spring
Et bientôt bien plus encore!

Des microservices scalables, monitorés, sécurisés

Monitoring avec la JHipster Console (basée sur ELK) ou

Prometheus
 Les Gateways
Une Gateway est une application JHipster normale
Possède toutes les fonctionnalités d’une application JHipster

Recommandation : une gateway doit rester “légère”, ne pas la surcharger

avec trop de services…

Donne accès à l’ensemble des microservices

Utilise Netflix Zuul pour le routage, le load balancing, le failover

Ajoute une couche de sécurité avec JWT (ou OAuth2)

Fournit de la qualité de service avec un filtre de “rate limiting”

Propose une documentation Swagger agrégée de l’ensemble des services

Astuce : vous pouvez avoir plusieurs Gateways, spécialisées

en fonction des besoins métier
 Les microservices
Les microservices sont des applications JHipster
normales, sans front-end Angular(JS)

Toutes les options habituelles sont disponibles: base de

données, Elasticsearch, etc.

Le JDL Studio peut être utilisé pour générer des entités

CRUD

La principale limitation concerne l’impossibilité d’utiliser

les Websockets
Sera résolu avec Zuul 2

On peut utiliser un Kafka en interne, puis des Websockets sur une

gateway
 Le JHipster Registry
Le JHipster Registry est une application Open Source
(Apache 2) spécifiquement développée pour les
architectures microservices avec JHipster
Utilise Netflix Eureka comme registre de services

Utilise Spring Cloud Config pour configurer les applications Spring

Boot

Très utile pour envoyer des “secrets” (le mot de passe de la base de données)

Peut reconfigurer des microservices

Peut stocker sa configuration sur le système de fichiers, ou dans Git

Possède une interface Web complète (développée avec JHipster!)

Est disponible sous forme d’image Docker

Le JHipster Registry dans le futur

Une partie de l’effort de développement actuel

se porte sur le JHipster Registry

Il va agréger les pages d’administration des

applications
Serveur centralisé pour les métriques, la santé des
applications, la gestion des logs et de la configuration Spring
Boot

Les pages “admin” des monoliths et gateways deviendront

optionnelles
 HashiCorp Consul
Alternative au JHipster Registry pour le registre de
services
Focus sur la consistance (Eureka a un focus sur la disponibilité)

Plus efficace que Eureka sur de nombreux points

L’enregistrement et le désenregistrement de services est bien plus
rapide

Prend moins de RAM

Propose un serveur DNS

A sa propre UI

Mais il ne fait “que” registre de services et n’est pas

facile à étendre ou modifier
 JHipster Console
Application de monitoring basée sur la stack ELK
(Elasticsearch Logstash Kibana)

Spécialement configurée pour les applications JHipster

Reçoit directement les événements des applications via une socket, dans
le bon format

Possède des dashboards pré-définis pour JHipster

Très simple à installer via le sous-générateur Docker

Compose

Disponible sous forme d’image Docker via Docker Hub

Nouvelle version disponible! Avec Elasticsearch 5 et

Zipkin pour tracer les requêtes
Génération d’entités avec des microservices

Les entités peuvent être générées dans les applications

microservices, comme dans n’importe quelle autre
application JHipster
Uniquement le code “back-end” est généré, il n’y a pas de code Angular(JS)

Toutes les options habituelles sont disponibles

Le JDL Studio peut être utilisé comme d’habitude

Pour les gateways, les entités peuvent être générées depuis

des microservices existants
Le code Angular(JS) est généré sur la Gateway, et se connecte via un proxy
Netflix Zuul au service back-end situé dans un microservice

Une Gateway va agréger les front-ends des entités provenant de plusieurs

microservices, ainsi que provenant de la Gateway elle-même
 Cache Hazelcast distribué

Hazelcast est le cache de 2nd niveau Hibernate par

défaut pour les microservices
Il est aussi utilisable via l’abstraction Spring Cache

Grâce au JHipster Registry, des instances différentes

d’un même microservice sont capables de se rejoindre
pour réaliser un cache distribué commun

Ce cache distribué fonctionne automatiquement avec

Docker Compose, lorsque l’on “scale” un microservice

> docker-compose scale myapplication-app=3

La sécurité pour les microservices
Par défaut, les architectures microservices sont sécurisées
via JWT
Le token est généré par la gateway

Tous les microservices acceptent ce token, car ils partagent la même clef
secrète

La clef secrète est diffusée par le JHipster Registry

Cette configuration par défaut peut être durcie

Utilisation d’un meilleur algorithme de cryptage

Utilisation d’un système de clef publique/clef privée

En beta, il est aussi possible d’utiliser OAuth2

En utilisant le JHipster UAA server
Déployer avec Docker Swarm

Même système qu’en local, mais sur un vrai

cluster!

La principale différence est que l’on peut

vraiment faire monter en charge les microservices
C’est ici que le cache distribué et JWT deviennent importants

> docker-compose up -d
> docker-compose scale myapplication-app=3
 Déployer avec Kubernetes

Similaire à Docker Swarm, mais avec Kubernetes

Fonctionne sur Google Cloud Platform

> kubectl apply -f monapplication

> kubectl scale —replicas=3 jhipster/monapplication
 Partie 8

Trouver de l’aide
 Où trouver de l’aide?

Règle #1 : tout est public

Règle #2 : nous avons des règles de contribution,

merci de les suivre!

Pour une question: utilisez StackOverflow avec le

tag “jhipster”

Pour une remontée de bug ou une demande de

nouvelle fonctionnalité: GitHub
 Plus d’informations

Conférences et nouvelles
Twitter @java_hipster

Section news sur https://jhipster.github.io/

Paris JHipster User Group

https://www.meetup.com/fr-FR/JHipster-User-Group/

Videos & tutoriels

http://jhipster.github.io/video-tutorial/
Questions Un oubli ?
Manque de temps ?

/
Posez vos questions sur Twitter !

@juliendubois

Réponses @java_hipster