Technologies Web

Mon retour sur le passage de PHP à Node.js

Cela fait maintenant depuis le mois de mai (si je me rappelle bien) que je travaille sur un projet Node.JS en lieu et place du PHP. Et cela fait un bout de temps que je me dis que je dois faire un article sur les différences entre ces deux technologies WEB. Ainsi que mon retour sur cette dernière.

Avant d’aller plus en avant, je tiens à préciser à quoi nous sert Node.JS au travail : Créer une API complète (comme l’api twitter). Nous ne nous servons donc pas du tout de Node.JS pour la partie templating.

PHP, Node.JS, qu’est-ce que c’est ?

PHP

PHP est arrivé comme une technologie novatrice au début des années 2000 comme étant le langage dans le vent grâce aux choses suivantes :

  • C’est un langage interprété à la différence du C++ ou du JAVA qui nécessitent de compiler les sources pour fonctionner.
  • Il a la particularité d’être utilisé directement au sein des pages HTML grâce aux balises <?php ?>.
  • Il utilise la programmation procédurale qui est plus facile à apprendre que la programmation orientée objet.
  • Il n’est pas typé et il n’y a pas besoin de déclarer les variables avant de s’en servir.

Depuis, le langage PHP a fait son petit bout de chemin:

  • On peut installer des packages au sein de ses projets avec Composer (compatible PHP 5.3.2+).
  • On peut développer en Objet et utiliser des Designs Patterns comme le Pattern MVC grâce à différents Frameworks (Zend, CakePHP, Laravel, …).

Malgré toutes ces améliorations et l’engouement assez fort, PHP est sujet à de nombreuses vulnérabilités (Injections SQL, …) et il n’a pas de réel gestionnaire de paquets (Composer est un projet indépendant et a été inspiré par le gestionnaire NPM de Node.JS). Il n’y a pas une réelle API au sein de PHP et les performances ne sont pas toujours au rendez-vous.

De plus, de meilleures alternatives ont fait leur apparition pour le web :

  • Ruby on Rails
  • Django
  • Node.JS

Node.JS

Cette technologie est assez jeune (environ 2 ans si je ne me trompe pas), et apporte des choses innovantes (comme pour PHP à l’époque)’

  • Il permet d’exécuter du JavaScript côté serveur en utilisant le moteur de Google : Google Chrome V8 engine.
  • Il intègre nativement un gestionnaire de packages : NPM. Ce gestionnaire permet d’installer des modules soit en global, soit dans un projet.
  • Les modules Node.JS globaux apportent le plus souvent des commandes système supplémentaires. Par exemple : lancer la conversion du Less vers le CSS ou la création d’un projet express directement hiérarchisé.
  • Vous pouvez créer vos modules en code natif (C/C++) et en JavaScript.
  • Il peut faire office de serveur web sans passer par Apache ou Nginx. Mais ces derniers peuvent être nécessaires si vous voulez accéder à différents projets Node.JS sur le même port (80 et 443 par exemple) ou pour utiliser les noms de domaine.
  • Il ne bloque pas les entrées/sorties grâce à l’asynchrone du JavaScript (je n’arrive pas à mieux tourner cette phrase). Ce qui permet un gain notable des performances.

J’ai oublié certainement d’autres points importants, mais ici, je ne cherche pas à montrer tout ce qu’apporte Node.JS, mais quelles sont les choses les plus notables qu’il apporte.

C’est une technologie assez récente et bas niveau. Est-ce que dans 10 ans une autre technologie va aussi le supplanter? Possible, mais nous n’y sommes pas encore.

Comparatifs

Certains d’entre vous sont friands de comparatifs en tout genre, voici les principaux listés ici:

Mon retour

Contexte

Il faut savoir que, comme dit en introduction, j’utilise Node.js uniquement comme API RESTFul. Pourquoi ce choix? Car une API permet d’avoir différents points d’entrée et permet un plus grand large choix de technologies pour ce qui va « consommer » l’API.

Dans mon cas, je n’utilise pas du tout le moteur de templating fourni par NodeJS. Je laisse cette partie au projet de frontend. Node.js permet, grâce à express, d’effectuer des retours JSON avec une facilité enfantine.

Ensuite, notre API est RESTFul. Malheureusement, express ne suffit pas pour répondre à ce besoin. De plus, nous préférons utiliser un pattern structuré tels que le pattern MVC pour nos projets. Locomotive.js est parfait pour répondre à ce besoin.

Et pour finir, le passage à Node.JS seul ne suffit pas, un petit passage de MySQL vers MongoDB s’est avéré utile. Ça répondait à nos besoins puis les résultats de MongoDB sont directement utilisables par Node.JS vu que ce sont des objets/tableaux JSON.

Retour d’expériences

Le plus dur je trouve avec le passage de PHP à Node.js est ce principe d’asynchrone. Dès que vous appelez une fonction avec un callback, il faut bien penser à chaque cas de retour sans en omettre un seul sous peine de se retrouver avec la requête bloquée en attente d’une réponse.

De base, Node.js met en cache tout votre projet avant de l’exécuter. Vous devrez donc penser à bien le relancer après chaque modification de votre code. J’ai eu l’air fin à chercher pendant 15 minutes pourquoi mes modifications n’étaient pas prises en compte.

Sinon, en soi, Node.js est vraiment un plaisir à utiliser. Bien entendu, c’est du JavaScript et sans rigueur, on peut très très vite se retrouver avec du code sale.

Dernier point. Pour les développeurs sous Windows : changez d’OS. La plupart des modules utilisant des librairies natives ne fonctionnent pas chez vous et la ligne de commande étant quand même assez utilisée et aux vues de votre console assez préhistorique, je vous conseille de développer sous Linux ou Mac.