NodeJS vs Java EE pour une application web

Depuis 2009, NodeJS a envahi le petit monde du développement web, et petit à petit fait son trou parmi les plateformes de référence pour réaliser une application, site ou APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données. de services. Le vieux Java EE résiste pourtant, et quiconque souhaite aujourd’hui démarrer un nouveau projet peut se confronter à cette problématique : NodeJS ou JavaLangage de développement très populaire ! EE ?

C’est cette question que nous nous proposons de trancher, ou plus modestement d’éclairer de quelques éléments de comparaison qui permettront de structurer la réflexion des décideurs sur les points critiques à prendre en compte en vue de ce choix.

Dans cette analyse, nous considérerons les dernières versions de chacune de ces plateformes : NodeJS 6.10.2, et Java EE 7 sous Java 8. C’est parti !

Javascript vs Java : comparaison des langages

Le Javascript et le Java, en tant que langages de programmation, observent de nombreux points de convergence sur lesquels il est inutile de s’attarder. Voyons directement leurs différences majeures.

Le typage

Le Java possède un typage statique et fort, et est massivement orienté objet. En Java, à l’exception des 8 types primitifs, tout est objet, et la moindre portion de code doit s’insérer dans une classe. Ce cadre restrictif offre une solution de développement contraignante, mais par là-même sécurisante puisqu’elle limite les erreurs de typage dès la pré-compilation.

Le Javascript en revanche possède un typage dynamique. La programmation objet est possible mais n’est pas obligatoire, et les nombreux transtypages automatiques en font un langage infiniment plus souple que Java… avec la limite évidente des risques accrus pour un développeur de se perdre dans son propre code et de générer des erreurs de typage à profusion. L’absence de compilation avant le démarrage de l’application n’aide pas davantage.

L’exécution

Java est un langage pré-compilé en bytecode puis exécuté dans une machine virtuelle qui interprète ce bytecode à la volée.

Comme son nom l’indique, le Javascript est un langage de scripting, donc interprété à la volée. En cela, il se rapproche du Java. En réalité, si cette description est correcte pour du Javascript exécuté dans un navigateur web, elle est erronée pour une application NodeJS. En effet, le moteur d’exécution compile tout ou partie le programme au lancement même de l’application, directement en langage machine. Nous verrons cela en détails un peu plus tard.

Le paradigme de développement

Java est un langage de développement impératif de type procédural : le programme est constitué comme un ensemble d’instructions à exécuter séquentiellement. C’est le paradigme le plus courant et le plus simple à appréhender pour les développeurs, mais ce n’est pas le plus optimisé en termes d’utilisation des ressources de la machine. Nous y reviendrons dans la partie [« Exécution et performance »][5] .

Javascript en revanche est un langage de développement événementiel : le programme est défini comme un ensemble de réactions à des événements. Ce mode de programmation est radicalement différent du précédent dans la mesure où chaque gestionnaire d’événement doit être autonome vis-à-vis du reste du programme. Il est plus complexe à appréhender, notamment par son utilisation massive de l’asynchronicité.

En un mot

Environnement et framework

L’univers Java regorge de librairies open source disponibles pour agrémenter son application web de fonctionnalités absentes du JDK. Des gestionnaires de librairies tels que Maven permettent d’intégrer ces sources annexes dans votre projet, même si leur utilisation peut s’avérer complexe.

De son côté, NodeJS est livré avec son propre gestionnaire de paquets, npm. Celui-ci permet également d’intégrer des libraires à son projet sous forme de paquets. L’utilisation en est simpliste, la fiabilité élevée, et le catalogue est très fourni.

Du point de vue de l’exploitation, une application Java EE ne s’exécute pas directement. Elle doit être exportée sous forme d’archive, par exemple un fichier .war, puis déployée sur un serveur d’applications, comme WildFly. Le serveur d’applications lui-même est un programme Java, qui s’exécute donc dans une JVM. Un serveur d’applications certifié Java EE propose de nombreuses fonctionnalités avancées (caches applicatifs, pools de connexions, clustering, haute disponibilité…), mais leur paramétrage peut s’avérer complexe.

Une application NodeJS s’exécute d’une simple commande : node [nom de votre fichier main]. Quelques paramétrages sont disponibles, mais les fonctionnalités ne sont pas très avancées.

En un mot

Prise en main

Le langage Java en lui-même est rarement une difficulté pour un développeur, en revanche l’architecture d’un projet Java EE a le don de décontenancer ceux qui s’y confrontent pour la première fois, en particulier lors de l’installation. De plus, les nombreuses couches d’abstraction imposées par les frameworks de base de Java EE (Hibernate, JSF, EJB) se présentent souvent comme des boîtes noires dont le contenu est parfois obscur et réserve à l’occasion quelques surprises.

NodeJS, quant à lui, ne nécessite pas de connaître autre chose que le Javascript pour démarrer. L’installation est triviale et le démarrage ne pose en général aucun problème. L’import de modules est inévitable, et leur facilité d’utilisation, en revanche, est très variable, les documentations étant très inégales.

En un mot

Moteur d’exécution et performance

Une application web Java EE est déployée sur un serveur d’applications Java EE. Le processus qui s’exécute est donc celui du serveur, qui porte toute la configuration d’exploitation via le paramétrage de la JVM.

Une application NodeJS est exécutée par le moteur de Google, V8. Le programme est (partiellement) compilé au démarrage. Quelques paramétrages d’exécution existent.

Du point de vue des performances, les serveurs d’applications Java EE proposent des temps de réponse très satisfaisant d’une façon générale. Toutefois, le pattern 1 requête = 1 thread limite ces résultats lors d’une montée en charge, puisque la quantité de ressources croît en proportion.

Avec son pattern proactor, NodeJS évite cet écueil. Chaque requête parvient à un unique thread qui est chargé de répartir les demandes sur un pool de threads de taille fixe, avec une file de taille indéfinie. De plus, l’approche événementielle permet de libérer chaque thread de ce pool dès que le programme est en attente d’une entrée-sortie (fichier, BDD…). L’ensemble de ce système le rend très performant et particulièrement résistant à la montée en charge. 

En un mot

Maintenance et évolutivité

La facilité de maintenance de n’importe quelle application est avant tout liée à la manière dont elle a été développée : architecture applicative, qualité de code, qualité des commentaires, qualité de la documentation. Ces paramètres ne dépendent ni de la technologie ni de l’environnement de développement.

Ce dernier joue un rôle important, en revanche, lorsqu’on hérite de la maintenance d’une application que l’on n’a pas développé soi-même, et qui (comble de malheur…) souffre de lacunes documentaires. Dès lors, les facilités offertes par les IDEEnvironnement de développement permettant de faciliter le développement d'applications. Java pour naviguer dans un projet de lien en lien permettent une exploration facile du programme. Pour l’heure, il n’existe rien d’équivalent dans l’univers NodeJS.

Le niveau d’évolutivité de l’application se base sur les mêmes critères. Quant à l’évolutivité de la technologie elle-même, Java EE est aujourd’hui bien moins dynamique que NodeJS, mais encore bien plus riche en fonctionnalités diverses… jusqu’à quand ?

En un mot

Sécurité

Java EE propose toutes les fonctionnalités nécessaires pour la sécurisation des applications : stratégies d’authentification, cryptage SSL, règles d’accès… Toutefois, ces fonctionnalités sont assez complexes d’utilisation, et le haut niveau d’abstraction proposé par la plateforme a tendance à faire sur-estimer le niveau de sécurisation « par défaut » d’une application. Un travail spécifique est donc nécessaire sur ce point selon le degré de sécurité souhaité.

NodeJS en revanche propose une approche beaucoup plus bas niveau (quoique de plus en plus de modules spécialisés évoluent dans le sens d’un plus haut niveau d’abstraction). L’avantage est clairement la maîtrise de sa stratégie de sécurité. L’inconvénient est que cette maîtrise n’est pas facultative : il faut maîtriser son sujet pour sécuriser son application. Rien de bien sorcier, cela dit, mais une tâche à ne pas confier à un développeur junior.

En un mot

Conclusion

Les deux plateformes sont assez différentes, et possèdent chacune une identité propre assez marquée. Pour autant, malgré les développements que nous venons de faire, il n’est pas évident de trancher entre l’une et l’autre des solutions.

Pour résumer, Java EE est une plateforme très complète, fiable et éprouvée, qui offre des facilités de développement, mais peu de souplesse. Ses performances sont bonnes, à nuancer en cas de montée de charge. On notera également la complexité des paramétrages et l’âge de la technologie, qui laisse espérer peu de nouveautés à venir.

De son côté, NodeJS est une plateforme innovante, dynamique, souple et performante, qui permet une architecture logicielle modulaire. Néanmoins, le développement événementiel peut s’avérer complexe d’approche, et certains points techniques comme la sécurité peuvent parfois devoir être gérés à bas niveau. Il est aussi parfois difficile de choisir un module pour tel ou tel fonctionnalité, ainsi que d’accéder à une documentation digne de ce nom.

Pour conclure, nous dirons que Java EE est plus adapté pour des gros projets, très cadrés, avec des perspectives d’évolutions moyennes à élevées et un cycle de maintenance long. Il convient parfaitement à des développeurs de niveau technique moyen.

NodeJS sera parfait pour des projets de taille plus réduite, avec une gestion de projet plus souple, des perspectives d’évolution faibles ou moyennes, et un cycle de maintenance moyen à long. Il nécessite d’avoir des développeurs (ou a minima un architecte) de niveau technique un peu plus élevé.