Mon retour sur le passage de PHP à Node.js

Avant tout une passion

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.

 

Commentaires : 14

  1. RT @throrin19: Vous avez peut-être raté mon retour sur #nodejs : http://t.co/i0zO3hb0Y3

  2. @bnizworks dit :

    Mon retour sur le passage de PHP à Node.js http://t.co/EVGcuoIXVA

  3. Hervé dit :

    « PHP est sujet à de nombreuses vulnérabilités (Injections SQL, …) »

    On ne peut pas dire ça, ce n’est pas inhérent à PHP. On voit de très belles injections de SQL dans tous les langages sur la mailing-list BugTraq par exemple. Ce genre de faille vient de la manière dont l’appli a été développée, ou éventuellement du framework.

  4. dav dit :

    Merci pour ce retour d’expérience.

    Pour le pb de changement non pris en compte sans relance du serveur, j’utilise avec bonheur nodemon qui se charge de relancer le serveur dès qu’il détecte une modification dans un fichier

  5. Mon retour sur le passage de #PHP à #Node.js http://t.co/h6CQvC76Tt

  6. RT @marcelodelage: Retour d’expérience sur le passage de #PHP à #nodejs https://t.co/xGb6zjdpjN

  7. @LaielBen dit :

    Les différences entre #php et #Node.js :
    https://t.co/kY4Vkwdoux

  8. […] : – Open Classrooms – Blog : PHP vs Node.js – Blog: Retour sur le passage de php à Node.js/ – Wikipedia Node.js – Wikipedia V8 (moteur […]

  9. Becoco dit :

    Pas de gestionnaire de packets dans php avant composer ? euuu.. et pear et pecl c’est (c’était) pour les chiens ?

  10. Pascal THOMAS dit :

    Je n’ai pas encore eu l’occasion de tester NodeJS. Mais considerer que NodeJS innove en proposant du Javascript… pas trop non, Microsoft le proposait depuis très longtemps.

    L’on peut faire des plugin C/C++, oui avec PHP aussi, et c’est simple.
    Les no’tions d’Objet, de gestions de paquets,… oui enfin le PHP ce n’est plus le PHP 2.
    Un serveur avec du PHP sans Apache, très facile, j’ai un microservice qui qui tourne ainsi, mais je préfère administrer des sites via Apache ou NGinx, plus d’outils, plus facile.

    Ce retour me semble négliger les avantages réels que sont :

    1/ permet de ne pas avoir a utiliser 2 langages dans le même projet (javascript des 2 cotés)
    2/ NodeJS gère les Websockets facilement avec socketIO
    3/ NodeJS permet la programmation événementielle ce qui est anecdotique à ce niveau mais intéressant

    Concernant la richesse des librairies l’ancienneté du PHP ne peut que le servir, et la gestion du REST est très simple en PHP.
    Concernant les performances il semble qu’avec PHP 7 dans de nombreux bench le rattrapage ai été effectif, en particulier avec OPCache actif.

    Que l’un des langages se distingue en tout est imaginable, mais personne ne me semble le démontrer sauf a considérer de vieilles versions.

    C’est sur des applications comparables, mixant IO – bases de données, calcul et manipulations d’objets en mémoire que l’on pourrait voir la performance en situation “réelle”, et avec des évolutions et maintenance sur le code que l’on mesurera l’essentiel dans la vie d’un projet, à savoir l’évolutivité, la maintenabilité.

    L’essentiel est que sur une base capable de répondre au besoins la maintenabilité soit assurée, ces 2 technos semblent devoir survivre dans un environnement ou beaucoup ne font que briller avant de disparaître, l’une ayant déjà prouvé quelle pouvait arriver a la majorité.

  11. Mike dit :

    Voici un autre comparatif benchmark qui compare les versions recentes entre node.js et php : https://thinkmobiles.com/blog/php-vs-nodejs/

  12. […] n'est pour aucune de ces raisons, elles m'ont simplement confortées dans mon choix. npm. Mon retour sur le passage de PHP à Node.js « Throrïn's Studio. Cela fait maintenant depuis le mois de mai (si je me rappelle bien) que je travaille sur un projet […]

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.