IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Open source et architecture logicielle

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

Note : 3 votes pour une moyenne de 5,00.
par , 10/01/2016 à 12h30 (6532 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 ?

Envoyer le billet « Migrer JEE vers Angular.JS et Node.js » dans le blog Viadeo Envoyer le billet « Migrer JEE vers Angular.JS et Node.js » dans le blog Twitter Envoyer le billet « Migrer JEE vers Angular.JS et Node.js » dans le blog Google Envoyer le billet « Migrer JEE vers Angular.JS et Node.js » dans le blog Facebook Envoyer le billet « Migrer JEE vers Angular.JS et Node.js » dans le blog Digg Envoyer le billet « Migrer JEE vers Angular.JS et Node.js » dans le blog Delicious Envoyer le billet « Migrer JEE vers Angular.JS et Node.js » dans le blog MySpace Envoyer le billet « Migrer JEE vers Angular.JS et Node.js » dans le blog Yahoo

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

Catégories
Javascript , Développement Web

Commentaires

Page 1 sur 2 12 DernièreDernière
  1. Avatar de r_benarbia
    • |
    • permalink
    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!
  2. Avatar de fr1man
    • |
    • permalink
    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 ?
  3. Avatar de faulken32
    • |
    • permalink
    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.
  4. Avatar de youtpout978
    • |
    • permalink
    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 à 15h48 par autran
  5. Avatar de Invité
    • |
    • permalink
    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...
  6. Avatar de chaya
    • |
    • permalink
    Cette Article fait suite à un autre article, je m'attendais à voir des choses un peu plus concrètes ?
    Mis à jour 13/01/2016 à 15h49 par autran
  7. Avatar de martopioche
    • |
    • permalink
    Citation 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 à 11h53 par autran
  8. Avatar de amine.hirri
    • |
    • permalink
    Citation 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
  9. Avatar de baptistelebail
    • |
    • permalink
    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.
  10. Avatar de marc.collin
    • |
    • permalink
    Citation 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
  11. Avatar de SylvainPV
    • |
    • permalink
    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.
  12. Avatar de marc.collin
    • |
    • permalink
    Citation 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...
  13. Avatar de martopioche
    • |
    • permalink
    Citation 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 ?
  14. Avatar de bilgetz
    • |
    • permalink
    Citation 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é.
  15. Avatar de marc.collin
    • |
    • permalink
    Citation 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
  16. Avatar de bilgetz
    • |
    • permalink
    Citation 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 ).
  17. Avatar de mangobango
    • |
    • permalink
    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
  18. Avatar de SylvainPV
    • |
    • permalink
    Citation 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.
  19. Avatar de marc.collin
    • |
    • permalink
    Citation 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...
  20. Avatar de marc.collin
    • |
    • permalink
    Citation 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
Page 1 sur 2 12 DernièreDernière