Open source et architecture logicielle

[Actualité] Migrer JEE vers Angular.JS et Node.js

par

autran

, 10/01/2016 à 11h30 (6385 Affichages)

Pour faire suite à l'article « Comment convaincre votre DSI d'adopter Node.js et AngularJS pour remplacer JEE », je vous propose une petite réflexion sur le processus migratoire qui pourrait être adopté une fois que la décision est prise.

Je rappelle qu'une telle migration n'est envisageable que sur des applications dont les couches vues et de traitements/persistances sont bien séparées. En effet, une application dans laquelle des JSP se connecteraient à une base de données est à mon sens déjà une telle hérésie qu'elle ne serait éligible qu'à un redéveloppement ex nihilo.

La première étape de la migration sera de migrer les JSF (ou GWT...) vers AngularJS. Cette étape présente deux avantages :

permettre aux développeurs de monter en compétences sur le langage JavaScript qui sera un bon préalable pour attaquer Node.js. En effet, AngularJS permet de bien assimiler les fonctions de Callback qui sont utilisées à souhait ainsi que la notation JSON ;
obtenir rapidement des résultats, car cette étape est centrée sur les IHM (aspect fonctionnel) et que le binding d'AngularJS est à la portée des enfants (aspect technique).

Cette étape sera l'occasion de retoucher éventuellement à la partie métier de JEE pour migrer un maximum de web services en REST. Cette modification permettra d'augmenter l'impact d'AngularJS autant que la laxité du couplage.

La seconde phase de cette migration sera dédiée à la partie serveur de l'application : les couches métier et persistance. À cette étape, les développeurs auront vraisemblablement atteint une maturité suffisante en JavaScript pour s'attaquer à Node.js.
Le succès de cette dernière phase nécessitera une implication importante de l'architecte logiciel qui devra proposer des solutions concernant :

les modules Node.js à utiliser ;
les normes de programmation JavaScript ;
le choix du Framework de tests unitaires ;
l'adoption des ORM de persistance et les bases de données.

De ce que j'ai pu voir, tous les développeurs ayant sauté le pas ont adopté cette technologie et abandonné la précédente. Les communautés de développeurs ont largement communiqué sur ce point, tant et si bien que les chefs de projet auront l'opportunité de rebondir sur la motivation des équipes de développement pour entreprendre cette migration.

Et vous ?

Que pensez-vous de la cinématique de migration proposée ?

Mis à jour 11/01/2016 à 07h37 par ClaudeLELOUP

Tags: angularjs, javascript, node.js

Catégories: Javascript , Développement Web

« Chiffrement AES en JAVA Liste des billets AngularJS, faut-il aller vers la version 2.0 ? »

Commentaires

r_benarbia - 11/01/2016 08h09
- |
Pensant long terme: Je ne comprend toujours pas pourquoi ce langage peux remplacer Java surtout avec son écosystème? Merci de me changer d'avis!
fr1man - 11/01/2016 09h24
- |
Ce que j'aime avec JEE, c'est la normalisation.
Je veux faire de la persistance de données, de la validation, j'ai une implémentation liée à mon serveur ou je peux utiliser une implémentation plus complète.
Dans l'environnent Node, comment dois-je m'y prendre ? Fouiller dans la multitude de projets et trouver le meilleur en espérant qu'il ne soit pas abandonné ?
Concernant par exemple la persistance et la validation de données, existe quelque chose d'aussi complet qu'en JEE ?
faulken32 - 11/01/2016 09h32
- |
Je suis d'accord que angular peu apporter pas mal de souplesse au niveau Ui mais, après avoir testé NodeJs , le code est trop bas niveau même avec un framework , sur des projets de grande ampleur c'est se tirer un balle dans le pied.
youtpout978 - 11/01/2016 09h57
- |
Il y a des développeurs souhaitant passer de Java à une fullstack JS de leur propre chef , je ne sais pas si ça représente énormément de développeur, je suis développeur .net à l'origine mais je travaille sur un front-end actuellement full JS avec angular, je fais ça parce que c'est ce que m'a été demandé par le client, mais je n'envisage pas de faire ça toute ma vie.

Le JS est un langage trop particulier et très pauvre de base il demande souvent l'ajout d'un nombre incalculable de librairie pour être pleinement exploitable sur de gros projets, et le débogage est toujours aussi merdique, je sais que l'ecmascript 6 permet une bonne évolution de ce langage mais il ne fait que singer l'existant (pour plaire aux développeurs venant de langage orienté objet notamment), à terme avec WebAssembly sera-t-il toujours autant utiliser sur de nouveaux projets ? J'en suis moins sûr.

Mis à jour 13/01/2016 à 14h48 par autran
Invité - 11/01/2016 10h18
- |
autant je suis d'accord pour angular sur le front, autant passer d'une techno quelconque mais fonctionnelle sur le back à node me parait risqué (que ce sois du java, du php, ou n'importe quoi d'autre)...
pour un nouveau projet pourquoi pas node, mais pour un ancien je mettrai d'abord une phase de création d'API REST sur la techno existante, pour ensuite passer à angular en front, puis éventuellement une autre techno serveur (pourquoi pas node) avec les même process, ou virer les anciens traitements si on conserve le langage d'origine...
chaya - 11/01/2016 10h40
- |
Cette Article fait suite à un autre article, je m'attendais à voir des choses un peu plus concrètes ?

Mis à jour 13/01/2016 à 14h49 par autran
martopioche - 11/01/2016 11h36
- |
Envoyé par vaild

autant je suis d'accord pour angular sur le front, autant passer d'une techno quelconque mais fonctionnelle sur le back à node me parait risqué (que ce sois du java, du php, ou n'importe quoi d'autre)...
pour un nouveau projet pourquoi pas node, mais pour un ancien je mettrai d'abord une phase de création d'API REST sur la techno existante, pour ensuite passer à angular en front, puis éventuellement une autre techno serveur (pourquoi pas node) avec les même process, ou virer les anciens traitements si on conserve le langage d'origine...

Ceci est également mon opinion. Que Java soit remplacé sur le front n'est même plus une question à se poser, c'est une démarche qui doit être envisagée et lors de toute évolution, le cout n'est pas bien supérieur au cout de maintenance... Si les promesses de l'architecte ne sont pas que du vent...

Cela va nécessiter d'adapter le back, mais migrer de techno... On est réellement dans le syndrome de l'informaticien qui se sent obligé de réparer ce qui marche...

Par contre, ce type de migration n'est pas une occasion de revoir le métier. Le métier est définit par le business et les process, pas par la techno.

Mis à jour 13/01/2016 à 10h53 par autran
amine.hirri - 11/01/2016 11h56
- |
Envoyé par r_benarbia

Pensant long terme: Je ne comprend toujours pas pourquoi ce langage peux remplacer Java surtout avec son écosystème? Merci de me changer d'avis!

En gros voici comment chacun voit cette migration:
* Un responsable technique / developpeur: n'importe quoi sauf pour la partie UI, l'idéal c'est de garder la partie serveur en Java avec des réponse en JSON, et la partie UI en full JS
* Un manager: peut être une façon d'avoir plus de budget pour continuer à "manager" son équipe, si pas d'autres projets plannifiés
* Une boite de conseil: une migration qui s'impose pour suivre la veille technologique (continuer à gagner de l'argent ), sans parler de tous les avantages de JS (bla bla bla)

Rien que comparer un eco-système qui compte BCP d'année de maturité à un language tout récent est (pour moi) une grosse bêtise
baptistelebail - 11/01/2016 12h18
- |
J'affectionne beaucoup Java et son ecosystème.
Mais l'idée d'avoir une stack (build, frontend et backend) entièrement sur le même language/ecosystème, en terme de productivité et de satisfaction : c'est un avantage assez monstrueux je pense.
Les points qui me rendent un peu réfractaire ;
- le langauge, JavaScript reste tout de même particulier bien qu'avec ES6 je commence à apprécier.
- comme dit précédemment, les modules Node n'ont pas la même stabilité/normalisation que les specs JEE. L'idée de baser son projet sur des modules qui peuvent être abandonnés n'importe quand, c'est pas rassurant.
marc.collin - 11/01/2016 13h47
- |
Envoyé par baptistelebail

J'affectionne beaucoup Java et son ecosystème.
Mais l'idée d'avoir une stack (build, frontend et backend) entièrement sur le même language/ecosystème, en terme de productivité et de satisfaction : c'est un avantage assez monstrueux je pense.
Les points qui me rendent un peu réfractaire ;
- le langauge, JavaScript reste tout de même particulier bien qu'avec ES6 je commence à apprécier.
- comme dit précédemment, les modules Node n'ont pas la même stabilité/normalisation que les specs JEE. L'idée de baser son projet sur des modules qui peuvent être abandonnés n'importe quand, c'est pas rassurant.

possible de le faire depuis plusieurs années.... avec par exemple Gwt, OpenXava, vaadin, zk.

Serait bien de cité les avantages de nodejs avec à JEE
SylvainPV - 11/01/2016 14h41
- |
J'ai beau être un fada de JS, je ne suis pas sûr que remplacer une stack JEE par du NodeJS soit toujours une bonne idée. On est encore loin d'avoir des solutions aussi industrialisées qu'en JEE. Je fais moi-même beaucoup de développement avec Node, que ce soit pour un usage serveur ou pour un usage local desktop avec node-webkit et Electron, et le principal reproche que j'ai à faire à la techno est la jungle des modules: pour faire des choses basiques comme de la manipulation de fichiers, il faut parfois recourir à 3, 4, 5 bibliothèques différentes : une pour étendre les fonctions de l'API fs de base, une pour la "promisifier", une pour ajouter des filename matchers, une pour faire les traitements en parallèle etc... on a pas vraiment de solution clé en main, et il semble que chaque grosse entreprise utilisant NodeJS a en interne plusieurs experts et un paquet de modules développés spécifiquement pour leurs besoins.

Pour avoir travaillé avec JEE et NodeJS, je pense que le développement NodeJS est plus souple et plus bas niveau, mais également plus délicat et nécessitant plus de compétences. Le temps d'apprentissage de Node pour un développeur front-end est plus important qu'on ne le croît. En résumé: gros investissement de temps et de ressources, facteur de risque assez important, et un outillage moins développé pour le run. Voilà pourquoi je ne pense pas que ce soit une bonne idée dans le monde de l'entreprise, surtout pour une migration d'un service existant. Certes, on peut se dire qu'il s'agit d'un investissement sur le long terme, mais je suis persuadé que l'arrivée de WebAssembly va bouleverser beaucoup de choses.
marc.collin - 11/01/2016 15h09
- |
Envoyé par SylvainPV

J'ai beau être un fada de JS, je ne suis pas sûr que remplacer une stack JEE par du NodeJS soit toujours une bonne idée. On est encore loin d'avoir des solutions aussi industrialisées qu'en JEE. Je fais moi-même beaucoup de développement avec Node, que ce soit pour un usage serveur ou pour un usage local desktop avec node-webkit et Electron, et le principal reproche que j'ai à faire à la techno est la jungle des modules: pour faire des choses basiques comme de la manipulation de fichiers, il faut parfois recourir à 3, 4, 5 bibliothèques différentes : une pour étendre les fonctions de l'API fs de base, une pour la "promisifier", une pour ajouter des filename matchers, une pour faire les traitements en parallèle etc... on a pas vraiment de solution clé en main, et il semble que chaque grosse entreprise utilisant NodeJS a en interne plusieurs experts et un paquet de modules développés spécifiquement pour leurs besoins.

Pour avoir travaillé avec JEE et NodeJS, je pense que le développement NodeJS est plus souple et plus bas niveau, mais également plus délicat et nécessitant plus de compétences. Le temps d'apprentissage de Node pour un développeur front-end est plus important qu'on ne le croît. En résumé: gros investissement de temps et de ressources, facteur de risque assez important, et un outillage moins développé pour le run. Voilà pourquoi je ne pense pas que ce soit une bonne idée dans le monde de l'entreprise, surtout pour une migration d'un service existant. Certes, on peut se dire qu'il s'agit d'un investissement sur le long terme, mais je suis persuadé que l'arrivée de WebAssembly va bouleverser beaucoup de choses.

pour le peu que j'en es fait, ton témoignage et de nombreux autres me laisse penser que le gain vendu par certain est plus que du pipeau.

on tombe dans du bas niveau, on a besoin d'une tonne de librairie pour faire la moindre petite chose...
martopioche - 11/01/2016 16h40
- |
Envoyé par baptistelebail

Mais l'idée d'avoir une stack (build, frontend et backend) entièrement sur le même language/ecosystème, en terme de productivité et de satisfaction : c'est un avantage assez monstrueux je pense.

En quoi est-ce un avantage ?
bilgetz - 11/01/2016 17h25
- |
Envoyé par martopioche

En quoi est-ce un avantage ?

Rien que les entités.
Au lieu de les définir des 2 coté, tu les définie qu'une seul fois et tu utilise des 2 coté.
Pouvoir utiliser du code et des object coté client et coté serveur peut te faire gagner du temps et être sur d'avoir un comportement pareil des deux coté.
marc.collin - 11/01/2016 17h30
- |
Envoyé par bilgetz

Rien que les entités.
Au lieu de les définir des 2 coté, tu les définie qu'une seul fois et tu utilise des 2 coté.
Pouvoir utiliser du code et des object coté client et coté serveur peut te faire gagner du temps et être sur d'avoir un comportement pareil des deux coté.

tel que déjà dit, tu peux déjà le faire en java, donc rien de nouveau
bilgetz - 11/01/2016 17h51
- |
Envoyé par marc.collin

tel que déjà dit, tu peux déjà le faire en java, donc rien de nouveau

Pas vraiment, car les solution qui existe sont lourde et utilise la génération d'html coté serveur et l'envoie en AJAX, merci les petite connexion.
La, on parle d'avoir des entité JS coté serveur, les envoyer en API rest, la recup cote navigateur avec un match 1 = 1 facile et très léger niveau octet transmis.

Et on parle pas de trans-compilateur java > javascript qui font du code a vomir.

Même si je ne suis pas un fan de Node, je reconnait quand même cet avantage la ( et la gestion de flux qui est tous bonnement exceptionnel ).
mangobango - 11/01/2016 18h31
- |
Alors... de mon point de vue je ferais, avant même d'envisager de changer de backend, un "audit" des modules NodeJS à utiliser. L'écosystème autour de Node est suffisamment immature pour investir un peu de temps à tripatouiller avec les différentes solutions. Pour ma part j'ai perdu BEAUCOUP de temps avec Loopback. Je cherchais un Django-like et Loopback avait à peu près cette promesse. Mais à l'usage, il y avait des bugs de framework qui se mêlaient à mes propres bugs... situation complexe.

Après vraiment vraiment vraiment avoir trouvé les outils pour supporter le changement (et être certains des bénéfices d'un tel changement), alors peut-être.

Mais à priori, pas

Daniel
SylvainPV - 11/01/2016 20h07
- |
Envoyé par marc.collin

pour le peu que j'en es fait, ton témoignage et de nombreux autres me laisse penser que le gain vendu par certain est plus que du pipeau.

Le gain de performances est réel, on a plusieurs preuves de concepts et benchmarks en interne qui ont montré la supériorité d'un serveur Node par rapport à un Tomcat pour le même boulot ; ce qui fait qu'on s'intéresse de près à Node pour les fonctionnalités avec beaucoup de trafic, comme les tchats, les applis temps réel etc... De la même façon, si des énormes entreprises comme Walmart ou Paypal ont migré vers NodeJS, c'est qu'ils y trouvaient un gain qui surpasse les risques : http://venturebeat.com/2012/01/24/wh...using-node-js/

Je ne cherche pas à descendre la techno, vu que je l'utilise moi-même beaucoup. Simplement je tiens à avertir que la transition n'est pas facile et pas toujours justifiée, surtout quand on a pas de développeurs à disposition ayant de fortes compétences en JS.
marc.collin - 11/01/2016 20h20
- |
Envoyé par bilgetz

Pas vraiment, car les solution qui existe sont lourde et utilise la génération d'html coté serveur et l'envoie en AJAX, merci les petite connexion.
La, on parle d'avoir des entité JS coté serveur, les envoyer en API rest, la recup cote navigateur avec un match 1 = 1 facile et très léger niveau octet transmis.

Et on parle pas de trans-compilateur java > javascript qui font du code a vomir.

Même si je ne suis pas un fan de Node, je reconnait quand même cet avantage la ( et la gestion de flux qui est tous bonnement exceptionnel ).

dans gwt, la génération du html se fait du côté client, pas besoin du serveur.

tu peux très bien communiquer en rest, web service... avec ton serveur.

c'est plutôt rare d'avoir un mach 1 = 1, c'est pour ça qu'il y a des dto... autrement tu gaspilles de la bande passante

les trans-compilateur ce n'est pas ça qui manque du côté browser, avec la multitude de langage de script ....

du code à vomir qui est plus performant que ce que la plupart des dev js n'arrive pas à atteindre...
marc.collin - 11/01/2016 20h24
- |
Envoyé par SylvainPV

Le gain de performances est réel, on a plusieurs preuves de concepts et benchmarks en interne qui ont montré la supériorité d'un serveur Node par rapport à un Tomcat pour le même boulot ; ce qui fait qu'on s'intéresse de près à Node pour les fonctionnalités avec beaucoup de trafic, comme les tchats, les applis temps réel etc... De la même façon, si des énormes entreprises comme Walmart ou Paypal ont migré vers NodeJS, c'est qu'ils y trouvaient un gain qui surpasse les risques : http://venturebeat.com/2012/01/24/wh...using-node-js/

Je ne cherche pas à descendre la techno, vu que je l'utilise moi-même beaucoup. Simplement je tiens à avertir que la transition n'est pas facile et pas toujours justifiée, surtout quand on a pas de développeurs à disposition ayant de fortes compétences en JS.

walmart, paypal... c'est des centaines de millions de transactions par jour... rien à voir avec le système moyens...
sans compté que dans de grosse de ce type, pour avoir travailler chez certaine, il n'est pas rare de changer car le boss la demandé.

du côté java ta utiliser les async?

c'est pas juste des bonnes compétences en JS qu'il faut, mais surtout bien maîtriser Node