Open source et architecture logicielle

Moi je dit oui sans soucis mais attention au dimenssionnement de l'appli, car j'ai toujours pas vu tourner un site angular JS avec des milliers de requetes, de l'upload de fichiers lourds et des traitements complexes, à voir.

Par contre ce que je vois davantage c'est un mix JEE/Angular il me semble que c'est un bon compromis, et puis coté IDE que peut-on utiliser ? il me semble pas que javascript bénéficie d'une intégration aussi avancé que Java en terme d'IDE ? Meme chose pr les API faut-il importer "à la mano" les dépendances ? Car faut pas oublier que si Maven existe c'est pas pour rien ! :-)

Pour les développeurs avec un certain bagage, il n'y a pas de soucis pour faire de petites applications avec les grosses architectures et une belle usine logicielle, ça pérennise l'application dans le temps. De plus Maven nous propose tous un tas d'artefacts qui permettent de faire un starter en 2 temps 3 mouvements.

Mais javascript offre beaucoup plus de possibilités intéressantes en terme de développement (surtout pour l'UI, j'adore le prototypage), j'ai hâte qu'il atteigne le niveau de maturité de Java et l'écosystème qui va avec, J'attend la suite de ce post avec impatience.

il manque une grosse partie ... il n'y a que la vision dev (et je la trouve très étroite, désolé )

attention à la partie exploitation et toute la problématique de :
- charge de l'appli
- load balancing / scalabilité
- maintenance et patching de l'appli
- multiples instances mutualisées

les applis node.js que nous hébergeons actuellement ne tiennent pas la charge (mais pas du tout) comparée à une app php/j2ee.
En fait, elles n'ont jamais été prévues pour l'exploitation, cette partie est tout simplement oubliée.

Je ne vois pas le rapport entre GWT et JavaEE !
Ensuite, côté env de dev, il n'y a pas besoin de sortir l'artellerie lourde (i.e intégration continue) pour développer une petite appli...
De plus si on te suit tu vas utiliser gulp, bower, etc, pour construire ton appli... bref, tu vas remplacer des outils de build par d'autre outil de build !!!!

Côté techno... pour une petite/moyenne appli, la pile Java est bien plus lourde à mettre en oeuvre... mais quand ton appli va monter en charge tu devras aussi mettre en oeuvre des technos comparables à celle de la puile Java...

a+
Philippe

Premièrement on ne remplace pas du JEE par du angular + node, JEE n'étant qu'une technologie backend.

Il s'agit en faite de remplacer JEE + GWT par angular + node (enfin de ce que je comprend la description de l'article).

Les bases nosql sont autant utilisables en javascript qu'en java, php, .NET ou tout autres technologies, qui plus est on peut tout à fait utiliser du MYSQL sur du node. Le choix de la base de donnée dépend surtout des usages et des contraintes d'administration (une base de donnée c'est avant tout de la gestion en run & assez peu de contraintes de développements). Sur du SI, le relationnel est souvent très utile car il décrit bien les relations entre les entités métiers (ex : une relation entre un produit et des tarifs). Le NOSQL est arrivé avec les gros acteurs du web qui avait des problèmes de gestion de très gros volume de données avec une très forte charge, c'est une approche différente.

Ensuite il n'existe pas de solution unique et miraculeuse à toutes les problématiques, NodeJS est une bonne techno pour la mise en place de plateformes simples (plateformes de médiations, routeur intelligent, système gérant les websockets etc...) et basées sur beaucoup d'IO néanmoins il souffre de grosses problématiques :
- Javascript et son environnement évolue extrêmement vite même si cela commence à se stabiliser un peu et avec énormément de manière complètement différentes d'arriver à ses fins. Si l'on prend de l'ES5 par exemple, il doit bien exister 3 ou 4 manières différentes de faire de l'objet nativement (sans parler des librairies) et il s'agit d'une des bases du langage! Cela implique de mettre en ligne tous les développeurs sur la même approche sans quoi tous les codes risquent d'être codés complètements différemment.
- Ensuite il s'agit d'un langage avec un typage TRES faible, ce qui pose rapidement des soucis sur le développement de couches métiers. Il n'y a pas trop de soucis sur du CRUD de base, mais le CRUD hormis quelques règles de validation ne comporte que peu de mécanisme métiers. Dès que l'on commence à avoir des systèmes un peu complexe, cela engendre pas mal de soucis qui sont réglés très rapidement sur des langages à fort typages (comme du java mais aussi du python ou du .NET). On peut compenser en utilisant typescript mais l'on rajoute encore une couche.

Si l'on part d'un environnement JEE il ne faut pas non plus ignorer la résistance au changement des développeurs dans ce domaine. Passer de JEE à node est quand même un changement très lourd et va prendre du temps, il ne faut pas ignorer le facteur humain. Tous les développeurs ne sont pas des as pouvant passer du jour au lendemain de JEE à javascript avant de passer le surlendemain à du scala par exemple.

Ensuite, indépendamment de la technologie, l'intégration des outils d'intégration continue tel que jenkins & sonar sont garants de la qualité et de la même manière que la base de données ne sont que peu liés à la technologie choisie. J'ai déjà mis en place une chaîne d'intégration continue sur une application ionic (angularjs + apache cordova pour du développement mobile) et j'étais bien content de l'avoir en particulier pour la partie sonar (c'est fou ce que cela peut apporter sur du javascript pour détecter des gros soucis liés à de petites erreurs de code). Après je suis d'accord que sur de petits projet ce n'est pas forcément essentiel, mais sur de de gros projets c'est le passage obligé!

Bref tout cela pour dire que le post décrit avant toute chose une envie de développeur plutôt qu'une lettre pour motiver un DSI. Un DSI se fiche complètement de la technologie en elle même, ce qui l'intéresse c'est surtout les avantages (et les faiblesses) associés que ce soit sur le développement mais aussi sur l'impact en terme de compétences requises, d'opérations, de supervisions, de gestion de l'historique etc... Et à ce titre il n'existe aucune solution miracle.

A titre personnelle, j'aurais plutôt tendance à conseiller à une entreprise fortement axé sur JEE de regarder les frameworks agiles de la stack java (play framework, grails ...) qui ont l'avantage de pouvoir être déployés sur le même type d'infrastructure que les vieilles applications JEE mais peuvent être aussi être déployées de manière autonome (comme node). Il n'y a pas de changement de langage nécessaire (ou alors vers un langage proche de java : groovy) et il est possible de réutiliser des composants déjà existants. Il est aussi important en parallèle de faire monter en compétences les développeurs sur les technologies du web (et ne plus cacher cette partie au travers d'un GWT ou d'un framework type wicket) pour la partie client.

Pour n'en dire que quelques mots, nous pouvons parler d'outils :
de Build comme Maven, qui peut nécessiter la création et l'administration d'un entrepôt ;
intégration continue comme Jenkins qui s’exécutera dans un serveur TOMCAT ;
ou de qualimétrie comme sonar.
Développer en JEE impose donc de maitriser toute une pile logicielle. Quant à la mise en production d'une application JEE, cela nécessite d'utiliser des ressources en CPU et RAM très importantes sur la plateforme d’hébergement.

Ca n'a absolument aucun rapport, maven, jenkins et sonar sont totalement indépendants de JEE, sinon on faisait comment pour packager un war/ear avant?

Maven, jenkins et sonar sont des outils améliorant la qualité des déliverables, en terme de code, et de reproduction et automatisation de build, en quoi une petite ou moyenne application n'a pas besoin de qualité?

Maven ne nécessite pas la création ni l'administration d'un entrepôt, soit on utilise un repo local auquel cas, rien a faire, soit effectivement un manager de repo comme archiva ou nexus, mais ça n'a de sens que si il est partagé par plusieurs applications, donc déjà existant...

Jenkins ne fonctionne pas obligatoirement dans un tomcat, il est également possible de le télécharger en package natif ou mieux en image docker. https://jenkins-ci.org/

CPU et RAM très important? la JVM alloue un espace mémoire défini, avec son propre overhead de +/- 200 mo, c'est peu à notre époque, quant au CPU, des chiffres seraient appréciables, parce que la JVM est tout de même optimisée pour le système sur lequel elle tourne et évolue en même temps que celui-ci, ce qui ne serait pas le cas d'une application native.

Beaucoup d'informations erronées ou incomplètes.

Bonjour,

en lisant le titre je me suis précipité pour avoir plus d'arguments sur ce sujet mais j'ai vraiment rien trouvé sauf des "préjugés"

1- node.js est utilisé par plusieurs boites niveau production ( liste des appli + sites utilisant node.js dans l'onglet stack http://stackshare.io/nodejs )
2- la présentation de la complexité pour le travail avec l'architecture JEE en intégrant Jenkins, sonar etc est vraiment a coté du vrai sujet sur la complexite car ces outils sont optionnels et sont la pour le respect de normes de codage, détection des bugs et l'intégration et le test du travail de l'équipe sur un environnement d'intégration ( pour ne plus tomber dans la fameuse "ça marche sur ma machine" )
3- le couple node.js / angular.js n'est pas le seul FullStack JS qu'on peut utilisé , donc je comprend pas la présentation de ces deux la comme alternative ou fatalité au lieu de présenter des FULL StackJS et laisser le libre choix au développeurs ou architecte de choisir selon le besoin
4- je ne vois aucun argument qu'on trouve facilement sur des forums qui traitent ce sujet pour l'après développement ! déploiement, load-balancing comme si c'était bénifique seulement pour les développeurs d'adopter ces frameworks ou passe vers du JS

Liste des app et site utilisant Node.js avec une explication d'un de leurs développeurs sur la partie sur laquelle il l'utilise :

Netflix (http://www.talentbuddy.co/blog/build...js-at-netflix/)
ebay ( http://www.talentbuddy.co/blog/build...de-js-at-ebay/ )
dowjones ( http://www.talentbuddy.co/blog/build...-at-dow-jones/ )
New York Times (http://www.talentbuddy.co/blog/build...ew-york-times/ )
PayPal ( http://www.talentbuddy.co/blog/building-with-node-js/ )
Medium ( http://www.talentbuddy.co/blog/on-bu...s-a-developer/ )
LinkedIn (http://www.talentbuddy.co/blog/build...s-at-linkedin/)

on peut avoué que c'est des app, sites qui ont du trafic

En cliquant sur le premier (netflix) le mec explique qu'ils n'ont pas encore migrer certains services qui demeurent en java même si ils prévoient une migration pr obtenir une appli JS full stack...

Apres je suis quand mm surpris du nombre d'appli utilisant cette techno ! moi je pense que dans la "Bay" il faut être à la mode, et les devs se font vite chier si ils innovent pas ... c'est valable aussi ailleurs mais c'est moins marqué, il y a une certain image à cultiver la-bas :-)

Mais ce qu'ils oublient souvent de dire ce sont les heures passés à retranscrire des algos etc. d'un langage vers un autre, à réécrire les API, refaire la roue etc. pour au final jouir d'un service REST ecrit en 10 lignes sous VIM mais qui derriere reste difficile à exploiter, les mecs analysent les dump Node et sont obliger d'utiliser des frameworks "observable" c'est pas pr rien à mon avis :-)

Envoyé par yildiz-online

Maven, jenkins et sonar sont des outils améliorant la qualité des déliverables, en terme de code, et de reproduction et automatisation de build, en quoi une petite ou moyenne application n'a pas besoin de qualité?

Maven ne nécessite pas la création ni l'administration d'un entrepôt, soit on utilise un repo local auquel cas, rien a faire, soit effectivement un manager de repo comme archiva ou nexus, mais ça n'a de sens que si il est partagé par plusieurs applications, donc déjà existant...

Jenkins ne fonctionne pas obligatoirement dans un tomcat, il est également possible de le télécharger en package natif ou mieux en image docker. https://jenkins-ci.org/

Je partage totalement cette critique. Même sur un petit projet, ne pas utiliser des outils d'automatisation et de suivi est une aberration. On n'utilise pas Node.js ou AngularJS pour se passer des outils de production...

Par contre, deux remarques :
- Ces outils ne sont pas des outils améliorant la qualité. Maven et Jenkins sont des outils d'automatisation, Sonar est un Dashboard. C'est tout. Il peuvent servir à appliquer la politique qualité mise en place et alors l'améliorer mais leur simple mise en place n'a pas d'autre impact sur la qualité que que celle apportée par l'automatisation de tâches.

- Archiva, Artifactory ou Nexus ont un sens déjà en tant que cache (penser contraintes de gestion de licence). Ils ont un sens dès qu'on pense composants et non applications. Donc mis à part si on est dans une Start-up avec une grosse culture Git, ils sont fondamentaux dès l'outillage.

Je comprendrais jamais cette logique de vouloir migrer absolument sous node.js. C'est pourtant le sentiment que reflète cet article quand je le lis. C'est peut-être très bien mais c'est pas absolu...

Pourquoi le lien 'Forum' n'est pas disponible dans cette news? Du coup il est impossible de voir les discussions sur le site mobile

Le DSI ne sait pas ce qu'est "EJB", mais se limiter à dire que ça sert à faire du CRUD relève du mensonge car l'information est trop incomplète. Ensuite tu dis qu'un développeur Java doit connaitre, en plus de Java, les outils comme Maven, Jenkins, Tomcat, Sonar. D'accord, Node.js n'a pas besoin de serveur HTTP comme Java, mais pour le reste tu tends juste le bout des doigts pour te faire taper dessus, n'importe quel professionnel sait à quel point ces outils sont importants et qu'ils ne sont pas spécifiques à Java. Tu prends PHP, tu vas retrouver le même modèle, l'outil de build qui ne sera plus Maven mais Composer par exemple, Jenkins et Sonar etc. Bref si tu veux faire du Node.js pour ne pas avoir à faire du Maven/Jenkins/Sonar, tu peux toujours rester sur du Java.

Sans vouloir te vexer, cet article c'est un peu du WTF. On ressent certes la volonté de convaincre quelqu'un à passer sous Node.js mais limité à la vision d'1 développeur, donc si tu veux convaincre un DSI je te dis tout de suite ce que tu dois faire : migrer des applications critiques vers Node.js puis faire un benchmark et dire que Node.js lui coute revient moins cher.

Citations :

• Par curiosité, qu'as-tu voulu dire avec "la technologie JEE permet de faire face à la montée en charge en clonant les « tiers » (aussi appelé scalabilité)" ?
• "Quant à la mise en production d'une application JEE, cela nécessite d'utiliser des ressources en CPU et RAM très importantes sur la plateforme d’hébergement." => Fais nous un joli benchmark d'application réelle please.
• "Sur un prochain post, je montrerai comment migrer en douceur de JEE vers AngularJS et Node.js." AngularsJS 1 c'est devenu has been, alors faudra surtout pas oublier de nous montrer comment migrer des applications Java EE Servlets & Spring & Struts & JSF vers du AngularsJS 2 en TypeScript.

Envoyé par frfancha

Pourquoi le lien 'Forum' n'est pas disponible dans cette news? Du coup il est impossible de voir les discussions sur le site mobile

Et en fait même sur le site web je n'ai pas trouvé de façon autre de voir les commentaires au delà des quelques premiers autrement qu'en cliquant sur "répondre" ?

Liste des app et site utilisant Node.js avec une explication d'un de leurs développeurs sur la partie sur laquelle il l'utilise :

Netflix (http://www.talentbuddy.co/blog/build...js-at-netflix/)
ebay ( http://www.talentbuddy.co/blog/build...de-js-at-ebay/ )
dowjones ( http://www.talentbuddy.co/blog/build...-at-dow-jones/ )
New York Times (http://www.talentbuddy.co/blog/build...ew-york-times/ )
PayPal ( http://www.talentbuddy.co/blog/building-with-node-js/ )
Medium ( http://www.talentbuddy.co/blog/on-bu...s-a-developer/ )
LinkedIn (http://www.talentbuddy.co/blog/build...s-at-linkedin/)

on peut avoué que c'est des app, sites qui ont du trafic

génial cette liste , si on se rend sur les divers site que tu propose, appart paypal et peut être netflix ( qui n'a pas encore tout migré sous nodejs ), on vois clairement des problèmes de performances, medium étant le pire des cas, avec 3 fois rien comme contenue ( bha oui c'est un blog avec des commentaire ) le bordel rame comme pas possible ( je parle même pas de leur version mobile html sur laquelle naviguer devient un vrai challenge )

Envoyé par Gugelhupf

• Par curiosité, qu'as-tu voulu dire avec "la technologie JEE permet de faire face à la montée en charge en clonant les « tiers » (aussi appelé scalabilité)" ?
• "Quant à la mise en production d'une application JEE, cela nécessite d'utiliser des ressources en CPU et RAM très importantes sur la plateforme d’hébergement." => Fais nous un joli benchmark d'application réelle please.
• "Sur un prochain post, je montrerai comment migrer en douceur de JEE vers AngularJS et Node.js." AngularsJS 1 c'est devenu has been, alors faudra surtout pas oublier de nous montrer comment migrer des applications Java EE Servlets & Spring & Struts & JSF vers du AngularsJS 2 en TypeScript.

Par curiosité, qu'as-tu voulu dire avec "la technologie JEE permet de faire face à la montée en charge en clonant les « tiers » (aussi appelé scalabilité)" ?
JEE permet de mettre en place une architecture multi-tiers, un tier étant une couche de l'application. Chaque tier pouvant être hébergé sur une plate-forme hard (CPU + RAM + HD) différente.
Afin de gérer la sollicitation de chaque tier, on peut utiliser un cluster de serveurs dédié à une couche. C'est ce que j'appelle cloner un tier. Au passage cela permet de faire face à la montée en charge mais aussi d’implémenter la résilience vis à vis d'une défaillance technique.

"Quant à la mise en production d'une application JEE, cela nécessite d'utiliser des ressources en CPU et RAM très importantes sur la plateforme d’hébergement." => Fais nous un joli benchmark d'application réelle please.
Ce que je veux dire, et là nous sommes au cœur de l'article, c'est que pour développer une application qui sera utilisée par 10 personnes dont 1 personne connectée H24 et 9 qui se connecteront 1 fois par semaine. Pour une application qui met a peine 20 objets en persistance. Pour une application dont l'aspect transactionnel de la persistance est sur une mise à jour de table toute les 15 minutes. Pour une application qui se compose de moins de 10 écrans. Pour ce genre d'application que je qualifierais de petite, utiliser un WILDFLY, voire à minima un TOMCAT si l'on fait l'impasse sur les EJB, requiert pas mal de CPU et de RAM. Ben oui, parce que même un pauvre TOMCAT + APACHE est infiniment plus consommateur de RAM et CPU que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var app = express();

.....pour ça pas besoin de faire un benchmark.

"Sur un prochain post, je montrerai comment migrer en douceur de JEE vers AngularJS et Node.js." AngularsJS 1 c'est devenu has been, alors faudra surtout pas oublier de nous montrer comment migrer des applications Java EE Servlets & Spring & Struts & JSF vers du AngularsJS 2 en TypeScript.
AngularJS est en version 1.4 me semble-t-il la V2 est pour le moment dans les cartons. Pour ma part j'ai déjà fait un tuto sur DVP pour démontrer en quoi Angular (version hasbeen) permet de faire largement aussi bien que JSF (+ AJAX).

Donc oui, dans la mesure ou j'ai déjà migré du JSF vers GWT (un tuto aussi sur DVP pour cette techno) et migré du GWT en angularJS (hasbeen), je pense sans malheureusement pouvoir démontrer que cet espace migratoire est pourvu d'une loi de composition ni que la propriété de transitivité soit vérifiée que l'on doit pouvoir migrer du JSF en Angular.

Bon je vais pas refaire un post là dessus car je vois que je déclenche des réactions épidermiques chez certains. Mais pour moi le premier step de la migration était JSF --> Angular. Pour les steps suivants, je vais les garder au chaud et attendre que mes idées avant-gardistes soient jugées moins mauvaises. Surtout que ça parle de référentiels et d'urbanisation.

Pourquoi le convaincre?

Il faut alors très bien apprendre javascript, j'ai rarement vu des gens qui le maîtrisait vraiment?

A terme est-ce que angular est pérenne? si on se fit à ce que fait google en général, ça peut faire peure à certain.

Angular 2 va sortir et n'est pas vraiment compatible à la version 1, d'ailleurs certain grosse pointure sont partie et travaille sur aurelia

Niveau composant graphique, angular est très pauvre comparativement à ext-js (sench), smart-client

Il faut apprendre un nouveau type de bd (nosql), utiliser un orm fait en js...

Au final il faut tout réapprendre avec des gains incertains.

Quand tu regardes ceux qui ont sauté le pas, c'est souvent de très gros système qui n'a rien à voir avec la quasi totalité des applications que les gens travaillent...

Un petit sprint boot, suivi de micro service rest. C'est simple, très rapide en mette en place tout en ayant la possibilité de mettre le tout dans le cloud.

Je suis plutôt du même avis que Gugelhupf. Sauf sur AngularJS, je n'ai aucun avis sur cette techno.

Par contre je ne comprends pas trop le but de ton article.

Au début, Tu parles d'écrire une petite application, et de devoir convaincre la DSI.
La DSI qui est en train de gérer plusieurs projets à quelques dizaines de M€, elle s'en fout un peu de cette application.
C'est pour ça que dans toutes les boîtes, tu as des milliers de petites applications écrites en: PHP, VB, Python, Macros Excel, etc... alors pourquoi pas AngularJS + NodeJS, GWT, Vaadin, Dropwizard, ajouter ici la dernière stack à la mode qui va bien. C'est ce que l'on nomme Shadow IT.

Juste pour infos dans les DSI pour lesquelles j'ai eu l'occasion de bosser, cela fait quelques années que AngularJS fait partie de leur boîte à outils.
C'est juste un outil, pas un but en soi. Elles ont pas eue besoin d'être convaincu.

Ensuite tu conclut ton article en changeant de problématique, tu nous parlant de migration, sans nous expliquer quels seraient les avantages de cette migration pour une DSI.
Oui, il est certainement possible de migrer de JSF vers AngularJS, mais dans quel but ? Pour quel gain ?

Je n'ai pas ton expérience des migrations, dans ma carrière je n'ai fait qu'une migration pour un budget de 100 K€, et 3 pour des budgets > 10 M€.
Mais c'est marrant la motivation ce n'était pas: chouette, une nvlle stack à la mode, allons joyeusement dépenser notre budget illimité.

A chaque fois la motivation principale c'était l'obsolescence: obsolescence des technologies, des matériels ou des compétences.
Il existe évidemment d'autres motivation pour faire des migrations.

Bonjour, tu sembles assimiler JEE à JSF et Node à Angular. J'ai constaté au cours de mes dernières années de dev que SpringMVC était devenu davantage à la mode et que JSF était considéré comme devenu obsolète. SpringMVC se marie très bien avec Angular, ce qui est effectivement moins le cas de JSF.

Concernant l'écosystème (Jenkins, Maven, Sonar, etc...) qui accompagne souvent les applications JEE, cet écosystème ne fait que répondre à des préoccupations en terme d'intégration continue, qualimétrie, etc... Cet écosystème ne fait pas partie de la norme JEE, ce n'est qu'un complément optionnel.

Pour ce qui est des arguments qui pourraient convaincre un DSI d'adopter Node, je pense qu'il ne faut pas obligatoirement l'associer à Angular, bien au contraire. Je suis convaincu que les architectures à base de micro services sont une tendance, bien que naissante, qui a vocation à s'imposer à l'avenir dans certains SI. C'est une architecture qui est portée par le mouvement Docker et qui répond bien à la volonté des DSI de découpler les développements. Pour faire un petit clin d'oeil, c'est finalement la même philosophie de découplage (mais poussée plus loin) qui motive l'adoption des micro services que celle qui a motivé en son temps l'adoption des EJB.

Si je parle des micro services, c'est parce que Node est tout particulièrement bien adapté à ce type d'architecture. Ou du moins certains micro services, puisque cette architecture permet d'avoir un environnement technique hétérogène. Le gain en temps de développement pour du simple CRUD est manifeste entre une application Node et JEE. Les deux freins à l'adoption de Node sont le typage faible de Javascript qui interdit de l'utiliser dans des applications avec un métier complexe, et le manque de confiance dans une techno encore jeune.

Si tu veux convaincre ton DSI, commence avec des ambitions modestes. Identifie un projet complexe bien adapté à une architecture de micro service, et propose de développer les modules CRUD avec Node et la promesse de gain de temps.

Autre domaine où Node est bien adapté, les API qui opèrent le backend des applis mobiles, car ce backend est souvent constitué de simples opérations CRUD.

Ces suggestions sont basées sur l'avantage en terme de temps de développement, mais il existe aussi d'autres avantages. La moindre occupation mémoire en est une, qui là aussi fait que Node est bien adapté à du micro services. Mais je crois savoir qu'il existe encore d'autres avantages liés notamment au mode de traitement des requêtes au niveau du système.

Rien n'empêche d'utiliser du angular et ça marche très bien avec du java, et comparer jee avec nodeJS est un non-sens.

D'autant plus qu'il y a spring qui marche bien pour les petites et moyennes entreprises pour faire des services; et je ne vois pas le problème du nosql, pareil on peut l'utiliser très bien.

Quitte à vouloir migrer des développeurs Java vers du FullStack JS, je choisirais plutôt le combo ( nodeJS, Ember). En effet cela sera beaucoup moins traumatisant car Ember se rapproche plus de la conception Object de Java que Angular. De plus Avec Ember-cli, les développeurs aurait une structure définis à disposition et serais beaucoup plus guidé qu'avec Angular.

Dans tout les cas le niveau de JavaScript nécessaire pour développer une application FullStack JS est autrement plus coriace que d'utiliser jQuery ou les composants Primefaces dont se contente la plupart des développeurs Java. ( Ce n'est pas une critique négative, juste une constatation du fait qu'il n'y à pas besoin d'en connaître forcement plus.)