Discussion :

[zecreator]

Bonjour,

Je me pose la question : Pourquoi déployer une grosse machinerie J2EE côté serveur pour une application web qui pourrait fonctionner sous NodeJS et qui permettrait l'utilisation d'un seul langage des 2 côtés (client et serveur) ?

Y a t-il des choses que le J2EE peut faire que NodeJS ne fait pas ?

Je ne prends partie pour aucune des 2 technologies, c'est pour avoir vos arguments pour mon orientation.

Merci.

[Marco46]

Si tu as des traitements à effectuer (conso CPU) il vaut mieux développer ça avec Java ou C#.
Si tu as beaucoup de requêtes dont la payload va trigger directement une I/O (BDD, autre WS, filesystem, ...) sans effectuer de traitement il vaut mieux utiliser Node.js.

Il n'y a pas de parti à prendre sur une techno ou une autre parce qu'elles ne répondent pas au même besoin. Node.js sert à traiter un grand nombre de requêtes qui vont chacune consommer extrêmement peu de CPU. Si tu fais du calcul côté Node ça effondre les perfs du serveur (blocage de l'event loop). Ça a été conçu spécifiquement pour traiter cette problématique.

C'est aussi beaucoup plus léger et beaucoup plus rapide à démarrer.

En résumé ça scale mieux, c'est moins cher à exploiter mais c'est pas fait pour faire du calcul.

[zecreator]

Si tu as des traitements à effectuer (conso CPU) il vaut mieux développer ça avec Java ou C#...

Oui, le Java/J2EE a une image assez austère par rapport au NodeJS. On sent bien que J2EE n'est pas principalement utilisé pour des sites d'entertainement, mais plutôt pour le traitement de Big Data.

Du coup, le Java est le premier langage en demande sur le marché. Quels secteurs d'activité qui sont en demandent de J2EE plutôt que toutes autres technologies pour du web ?

PS : Je parles de J2EE, pas du J2SE ou du Java embarqué dans du hardware.

[Marco46]

La plupart des grands comptes ont leurs backends en J2EE pour des raisons historiques.

Ils sont aussi frileux sur les nouvelles technos et ont une veille techno dégueulasse puisqu'ils utilisent des prestataires en masse. Ils ont peu de profils techniques en interne. On entend encore des conneries du style Node n'est pas une techno assez mature pour être utilisée en prod (alors que tout le fortune 500 l'utilise mais c'est pas grave ). J'ai même entendu des conneries du style Git est une techno pas assez mature on préfère SVN

En revanche les startups et les boites nouvelles technos, disons en gros la "french tech" sont très friandes de nouvelles technos. Il y a vraiment beaucoup de demande sur Node.js dans ces boites.

Le big data est aussi très utilisé avec Node. Je pense à la stack Mongo / Node ou même Elastic Search / Node. Tout dépend de ce que tu as à effectuer comme traitement avant de pousser les données dans ta persistance. Si tu as beaucoup de requêtes et peu de traitements à effectuer avant de les pousser dans ta persistance Node.js est bien plus efficace.

Côté frontend les SPA avec Angular / React / Vue raflent tout. Les grands comptes ont aussi investi là dessus depuis quelques années d'abord sur AngularJS. Désormais une partie réécrit les front sur Angular et une autre partie assez significative migre vers Vue.js. Il ya une grosse demande sur React dans les startups.

Cet engouement des SPA ajoute un intérêt supplémentaire à l'usage de Node quand il est possible, ça uniformise le langage utilisé. Les organisations qui prennent des devs fullstack et qui ont une stack basée sur J2EE ou .NET vont souvent privilégier Angular pour avoir du TypeScript directement dans la webapp. C'est beaucoup moins clair quand les équipes sont séparées front / back. Mais pour palier à ça Vue 3 aura un support de TypeScript très amélioré.

[gangsoleil]

Hello,

Je vais essayer de répondre à ta question bien que je ne connaisse pas bien les frameworks JS -- j'ai principalement travaillé sur des backends en C, avec des apps J2EE en front

Comme l'a bien dit Marco46, il y a déjà un problème d'historique : lorsque tu as un logiciel en J2EE d'un million de lignes, qui fonctionne plutôt bien, tu n'as pas forcément envie d'investir pour le ré-écrire en JS.

Ensuite, il y a le problème de l'évolution des frameworks JS (rappel : je connais moins cette partie, il est possible que je raconte des boulettes, mais elles mettent probablement en avant une réalité) : il y a 5 ans, backbone (et consors) était LE truc à utiliser. Aujourd'hui, c'est REACT. Alors je sais qu'il est toujours possible de passer de l'un à l'autre, mais pour un grand compte, ou pour des secteurs pas très évolutifs (backend des banques, des assurances), c'est trop rapide (n'oublions pas qu'il reste des backends écrits en Cobol, d'autres en C qui font tourner du code qui a plus de 25 ans).

Enfin, il y a des problèmes de performance -- peut-être de perception de performance. Prenons un cas réel : un module quelconque, qui doit traiter quelques millions de transactions en 12h. Gagner ou perdre 1 milliseconde par traitement, ça semble dérisoire, mais c'est 1h par jour de gagné ou de perdu (1ms * 3 600 000transactions = 3 600 secondes de traitement = 1h). Si ton traitement dure 1h, tu te fous de cette heure, si ton traitement dure 11h, c'est critique.

Changer ce backend pour le ré-écrire avec des technologies modernes (js, bases noSQL, ...) permettrait peut-être de diviser le temps de traitement par 2, mais à quel prix ?

Voilà, pour moi, les technologies dont tu parles sont, dans ces domaines, bien pour les front, mais trop coûteux pour les backends. Par contre, pour les entreprises avec moins d'historique, c'est une bonne piste.

[Marco46]

Enfin, il y a des problèmes de performance -- peut-être de perception de performance. Prenons un cas réel : un module quelconque, qui doit traiter quelques millions de transactions en 12h. Gagner ou perdre 1 milliseconde par traitement, ça semble dérisoire, mais c'est 1h par jour de gagné ou de perdu (1ms * 3 600 000transactions = 3 600 secondes de traitement = 1h). Si ton traitement dure 1h, tu te fous de cette heure, si ton traitement dure 11h, c'est critique.

Voilà, pour moi, les technologies dont tu parles sont, dans ces domaines, bien pour les front, mais trop coûteux pour les backends.

C'est surtout que c'est pas fait pour ça. Node.js n'est pas fait pour effectuer des traitements, il est fait pour avaler / cracher un très grand nombre de requêtes par seconde.

Si ton traitement c'est prendre un POST / PUT et le mettre presque tel quel dans une DB, ou tirer une requête avec un GET sans trop de transformation, alors Node.js est hyper performant. Si tu dois calculer plein de trucs c'est juste pas fait pour ça.

il y a 5 ans, backbone (et consors) était LE truc à utiliser. Aujourd'hui, c'est REACT.

Backbone c'était il y a 10 ans. Il y a 6 ans jusqu'à il y a 2 ans c'était AngularJS / Ember.

Depuis 2 ans c'est Angular / Vue / React.