Le document présente JHipster, un générateur d'applications open source qui facilite le développement d'applications utilisant Spring Boot et Angular avec des outils tels que Docker et Maven. Il aborde aussi les fonctionnalités comme la génération de code, la gestion des entités, les tests automatisés et l'intégration CI/CD, tout en soulignant l'importance de l'expérience développeur. En outre, le document évoque le soutien aux bases de données diverses, l'architecture microservices, et le support des tests de performance.

1. Être productif
avec JHipster
Devoxx France 2017

2. Julien Dubois
Créateur de JHipster
Directeur de l’innovation, Ippon
Technologies
@juliendubois
@java_hipster

3. 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 :-)

4. Spring Framework

5. Spring Boot

6. JHipster

7. 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
Introduction à JHipster

8. Technologies côté serveur

9. Technologies côté client

10. Installation
Génération d’une application
Partie 1

11. Utilisation de Yarn
Alternatives: JHipster Devbox, Docker
Installation
> yarn global add generator-jhipster

12. 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
oh-my-zsh
> jh

13. 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

14. Support des IDEs majeurs
IDEA, Eclipse, Netbeans
Visual Studio Code
Configuration de l’IDE
> idea pom.xml

15. Une application Spring Boot
Une application Angular(JS)
Un changelog Liquibase
Des fichiers de configuration
Fichiers générés

16. 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: la sécurité

17. Ecrans d’administration
Monitoring
Santé
Configuration Spring Boot
Gestion des logs
Très utiles en production
Seront optionnels dans une prochaine version
Les écrans générés: administration

18. 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”
Utilisation de Maven/Gradle
> ./mvnw clean test

19. 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 et Docker Compose
> docker-compose -f src/main/docker/mysql.yml up -d

20. 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
Support des bases SQL

21. 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
Liquibase

22. 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
Le cache de 2nd niveau Hibernate

23. 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
Spring Cache

24. 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
Hazelcast

25. 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
MongoDB

26. 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!
Cassandra

27. 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
Elasticsearch

28. 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
Kafka

29. 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
La sécurité

30. 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
Internationalisation

31. 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
Swagger

32. 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
WebSockets

33. 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
Mettre à jour une application
> yo jhipster:upgrade

34. Tester l’application générée
Partie 2

35. 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 avec JUnit et Spring

36. 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 unitaires avec Karma.js

37. 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
Tests de performance avec Gatling

38. 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!
Cucumber

39. 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!
Protractor

40. 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
Etude de la qualité du code avec Sonar
> docker-compose -f src/main/docker/sonar.yml up -d
> ./mvnw clean test sonar:sonar

41. 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
Intégration continue / déploiement continu
> yo jhipster:ci-cd

42. Travailler avec une application
générée
Partie 3

43. 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
Un environnement de travail performant

44. 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 Boot devtools

45. 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
Spring Data JPA

46. 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
Méthodes “fluent” dans les entités
Post post = new Post()
.title("Fluent methods are cool!")
.createdOn(LocalDate.now())
.addPostComment(postComment);

47. 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)
Liquibase

48. 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)
Profils

49. 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
Configuration spécifique JHipster

50. Dans les fichiers de configuration “application-
*.yml”
Configurer Spring Boot pour prendre en charge le SSL
Configurer JHipster pour utiliser HTTP/2
Exemple: mettre en place 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

51. 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!
AngularJS 1.x - Gulp & BrowserSync

52. 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
Angular + BrowserSync

53. Bower permet d’installer des librairies JavaScript/
CSS
Ces librairies sont automatiquement injectées
dans le fichier index.html
AngularJS 1 + Bower
> bower install bootstrap-material-design#0.3.0 —save

54. Avec Angular, JHipster migre de Bower vers Yarn
Plus sécurisé et plus performant que Bower
Permet des builds vraiment reproductibles
Utilise un cache
Angular + Yarn
> yarn install

55. 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 AngularJS 1.x

56. 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
Développer avec Angular 2+

57. 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
Personnalisation de Bootstrap

58. Générer des entités
Partie 4

59. 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 d’une entité

60. 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
Création des champs

61. 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
Gestion des relations entre les entités

62. “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
L’entity “User”

63. 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 des DTOs

64. 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
Utilisation d’une couche de service

65. 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
Options de pagination

66. 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
Re-générer une entité

67. Outillage et projets tiers
Partie 5

68. 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
…
JHipster Domain Language

69. 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
JDL Studio

70. 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
JHipster IDE

71. 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!
Modules

72. Passer en production
Partie 6

73. 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é
Construire une application pour la production
> ./mvnw clean package -Pprod
> docker-compose -f src/main/docker/mysql.yml up -d
> cd target
> ./monapplication-0.0.1-SNAPSHOT.war

74. 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!
Monitoring disponible

75. 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
Création d’une image Docker
> ./mvnw package -Pprod docker:build
> docker-compose -f src/main/docker/app.yml up -d

76. 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
Le sous-générateur “docker-compose”

77. 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 et Docker Swarm
> docker-compose scale myapplication-app=3

78. 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
Support de Rancher
> mkdir rancher && cd rancher
> yo jhipster:rancher-compose

79. Kubernetes est l’orchestrateur de containers
Docker le plus populaire
Support dans JHipster initialement développé par Ray Tsang,
de Google
Support de Kubernetes
> mkdir kubernetes && cd kubernetes
> yo jhipster:kubernetes

80. 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
Support de Cloud Foundry
> yo jhipster:cloud-foundry

81. 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.
Support de Heroku
> yo jhipster:heroku

82. AWS
BoxFuse
Serveurs d’applications Java EE
WAR exécutable
Autres plateformes de déploiement

83. Architecture microservices
Partie 7

84. 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
Architecture microservices

86. 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 Gateways

87. 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
Les microservices

88. 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

89. 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
Le JHipster Registry dans le futur

90. 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
HashiCorp Consul

91. 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
JHipster Console

92. 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
Génération d’entités avec des microservices

93. 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
Cache Hazelcast distribué
> docker-compose scale myapplication-app=3

94. 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
La sécurité pour les microservices

95. 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
Déployer avec Docker Swarm
> docker-compose up -d
> docker-compose scale myapplication-app=3

96. Similaire à Docker Swarm, mais avec Kubernetes
Fonctionne sur Google Cloud Platform
Déployer avec Kubernetes
> kubectl apply -f monapplication
> kubectl scale —replicas=3 jhipster/monapplication

97. Trouver de l’aide
Partie 8

98. 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
Où trouver de l’aide?

99. 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/
Plus d’informations

100. Questions
/
Réponses
@juliendubois
@java_hipster
Un oubli ?
Manque de temps ?
Posez vos questions sur Twitter !