Après 1 mois de JHIPSTER

Dans un lointain article, j’ai commencé à bidouiller avec JHIPSTER. Pour répondre à un besoin professionnel « one shot », j’ai décidé d’ utiliser ce framework car je n’avais pas pas beaucoup de temps à m’y consacrer.
Voici un rapide retour d’expérience d’un mois ( en pointillé ) d’utilisation.

Cas d’utilisation

Le cas d’utilisation se prêtait bien à JHIPSTER:

  • CRUD
  • Authentification via les réseaux sociaux
  • Application responsive permettant d’être manipulée via pc, tablette ou téléphone
  • Interface d’administration

Ce que JHIPSTER m’a permit de réaliser très simplement

  • L’interface d’administration était déjà prête pour moi. Je n’ai eu qu’à customiser certains comportements .
  • La création du front et back pour mes entités . Ici JHIPSTER est très fort. Ca fonctionne très bien. A tel point que pour une modification, j’en suis venu à supprimer et refaire ma configuration.
  • La sécurité : tout est mis en place ( JWT, Authentification via réseaux sociaux). Des directives ANGULAR sont également disponibles pour gérer les habilitations sur certaines parties de l’interface graphique (ex. has-authority).
  • L’intégration de docker. Tout est déjà crée pour vous 🙂
  • La mécanique JAVASCRIPT. Ce n’est pas ce que je préfère. JHIPSTER m’ a permis d’avoir un cadre de développement qui corresponde à mes besoins.
  • La création des pipelines JENKINS ou GITLAB

La ou j’ai galéré

Comme j’indiquai dans mon précédent post, dès qu’on sort du cadre, on galère un peu… Je n’ai pas échappé à la règle.

AngularJS vs html5

Bien que cela soit documenté. J’ai un peu galéré à activer le mode html5. J’ai eu quelques effets de bord sur les liens.

Permalien

Pour ce point, je pense que le soucis est plus dû à mon inexpérience de développeur WEB ( je suis plus back que front …).J’ai du implémenter une URL accessible directement sans passer par la page d’accueil (accès). J’ai opté pour une URL publique. La ça a été le début des problèmes. La CSS ne se charge pas tout le temps.
Bon pour ce cas d’utilisation, je ne me suis pas trop pris la tête. Je pense qu’une solution plus viable serait déjà de passer par Angular2/4 et de mettre des redirections dans le frontal NGINX

En conclusion

Le retour est positif. Pour une application « one-shot » c’est parfait. Je pense que pour une prochaine application je partirai sur du Angular et non du AngularJS. Pour une application métier plus poussée, je partirai sur un seed maison pour maitriser et avoir la main sur l’évolution de toutes les couches. Une autre chose qui m’a un peu étonné était le ratio entre développement BACK et FRONT. J’ai passé près de 70% dans le développement ANGULARJS. Spring et la génération JHIPSTER embarque déjà pas mal de fonctionnalités.

Découverte de JHIPSTER

Dans la série, je me réveille après les autres, me voici en train de découvrir JHIPSTER.


Pourquoi me direz-vous. En bien je souhaite réaliser un site avec des fonctionnalités assez courantes (CRUD, recherche, identification via réseaux sociaux,…) sans trop me prendre la tête. Et là, je n’ai pas encore trouvé plus simple :).

J’étais tenté de passer par PlayFramework, mais à première vue, JHIPSTER parait plus simple à mettre en œuvre.

Mais bon qu’est-ce qu’il y a sous le capot ?
Un outil de scaffolding basé sur Yeoman fournissant un front angular (1ou 2) un back basé sur spring boot, une couche de persistance pour une base de données (mongodb, cassandra ou SGBDR) et bien plus encore.

Je ne décrirai pas la procédure d’installation car elle est déjà très bien documentée.

Voici plus précisément les fonctionnalités que je teste :
Coté front

  • AngularJS
  • Bootstrap
  • JWT

Coté Back

  • Spring Boot
  • Identification avec Spring Social / Spring Security
  • Persistence avec MongoDB ( Cassandra n’est pas encore supporté pour l’identification via réseaux sociaux )
  • Utilisation de SWAGGERUI pour documenter les API

J’ai toujours été un peu réticent vis à vis des outils de ce type ( appfuse, jboss forge,..) . Mais, là je suis bluffé. Si on veut faire une application de type CRUD sans se prendre la tête à réinventer la roue pour l’identification, l’ administration des logs, la documentation, etc , JHIPSTER est, à mon avis, l’un des meilleurs choix actuellement.

Cependant, cette intégration à un coût. En effet, l’équipe a fait des choix très structurants. Ce qui est normal pour fournir une solution aussi intégrée. Il faut les accepter si on opte pour ce genre de solution. Par exemple, le monitoring des services springboot est uniquement visible par une console web alors quand dans version standard de ce FRAMEWORK, c’est visible via API REST. C’est certes pas mal quand on est tout seul à gérer l’application, mais dès que l’on veut intégrer la supervision dans une entreprise qui dispose déjà d’outils tels que NAGIOS, cela devient plus problématique.
(Supprimé suite au commentaire de J. DUBOIS)

Pour finir, je dirais que l’une des contraintes à accepter lorsqu’on utilise ce genre de FRAMEWORK est qu’il faut rester dans le cadre préétabli pour qu’il y ait une réelle productivité. Si on veut tordre le modèle on risque de perdre en efficacité et en maintenabilité. A titre personnel pour mon use case, je m’en accommode bien et ça me permet de faire plus de choses en JAVASCRIPT que je n’aurai pu faire avec une application réalisée « from scratch ».