Workflow node.js

By antho1404 • work • 5 Apr 2013

nodeAujourd’hui je vais parler un peu de node.js. Pour ceux qui ne connaissent pas, c’est pour faire du javascript côté serveur. Cette techno fait de plus en plus parler d’elle depuis un bon moment déjà pour une raison très simple, les performances, en effet javascript est un langage asynchrone et de ce fait node.js se base sur ce principe d’asynchrone ce qui permet de ne pas charger le serveur dans des attentes de réponses ou choses comme ça. Résultat on se retrouve avec de très bonne performance et quelque chose de vraiment parfait si on veux faire du temps réel, des websockets et plein de trucs cool comme ça.

Tout ça c’est bien beau mais bien sur ça à un “prix”, le développement se retrouve être un peu plus compliqué qu’avec du Rails par exemple ou en quelques lignes on peut faire une application de folie. La c’est un poil plus compliqué. Il existe une multitude de framework node.js permettant de mettre en place un proto très rapidement, du coup je vais faire un petit tours de ce que j’ai utilisé.

Express

L’un des framework le plus connu et surement le plus utilisé, il est repris dans beaucoup de versions à la mano il permet de mettre en place un serveur de base très rapidement et par la suite il suffit juste de greffer les modules voulus à l’application. Un module pour se connecter à la base de données, un pour mettre en place les sockets…  Par défaut donc ce framework est un peu trop “dépouillé” surtout avec la multitude de modules possibles offrant les mêmes fonctionnalités il est assez dur de savoir le ou lesquels utiliser.

Tower.js

Ce framework est basé sur express mais apporte par défaut une application beaucoup plus complète avec les accès à la base de données déjà intégré, le support du CoffeeScript (essentiel pour moi car le js pur…), un module de test etc…  De plus ce framework est plus que très inspiré de Rails du coup le framework inclut les mêmes petits outils qui font gagner un temps fou, les générateurs pour générer contrôleur, modèles et vues, les relations entre les modèles hasMany, belongsTo… des scopes, des validateurs… Enfin voilà tout pour créer une application très rapidement.

Meteor

Celui ci je ne le connais pas encore vraiment, j’ai juste joué et regardé un peu les démos qu’ils proposent et j’ai été assez séduit, en effet le côté client est serveur sont fortement liés et il a l’air très simple de mettre en place une application en temps réel. Il contient également par défaut la gestion de la base de données, les sockets etc et le petit bonus, il inclus également backbone.js par défaut du coup ce framework semble très intéressant et je sais sur quoi je vais faire mon prochain projet utilisant node.js.

les solutions a la mano:

Ici une multitude de solutions basées sur du node.js avec pour certain juste l’ajout du coffeescript et du scss, d’autres différentes façons d’accéder à la base de données… Énormément de solutions différentes, pour ma part, j’aime bien https://github.com/the-teacher/ExpressOnSteroids qui se base sur Express et qui apporte en plus le support du CoffeeScript, du SCSS et du HAML. Après il y en a une multitude, juste une recherche google du genre framework nodejs et vous serez servis.

 

Mon avis général du coup est que c’est une super techno mais le gros problème à mon sens c’est qu’il y ait une communauté si active que du coup on se retrouve très rapidement “pollué” de pseudo framework sans réels intérêt et donc il est assez difficile je trouve de trouver facilement les réponses à certains problèmes du fait de cette énorme diversité. Tout cela devrait au fur et à mesure converger je l’espère vers un seul gros framework (au moins a base d’Express) mais en ajoutant assez de configuration pour pouvoir travailler avec un bon workflow très facilement et rapidement. Au moins la gestion du coffeescript lors de la création de l’application par exemple :) .

Tags: , , ,

7 Responses

  1. Zetura

    Et du coup quel est l’intérêt de nodeJS face à Rails ? D’autant que de ce que j’ai lu, les performances de NodeJS sont assez médiocre face à Rails et même PHP : http://www.techempower.com/blog/2013/03/28/framework-benchmarks/

    • Ingolmo

      Dans l’article que tu nous montre, NodeJS est clairement meilleur que Rails et PHP pourtant !

    • Cela n’a aucun rapport, tout dépend de tes besoin, si tu veux faire une API, node.js est vraiment pertinent pour son approche asynchrone et non bloquante contrairement à Ruby. Chacun a ses avantages et inconvénients, de plus, il y a 40 000 benchmarks différents comparant node.js vs autres, d’ailleurs, dans ton article, node.js est devant Ruby…

      Et a moins d’etre sur de faire un site ultra populaire, je pense que c’est plus pertinent de se demander plutôt si le langage a un avenir (communauté active), si il est pertinent pour le projet (pour un gros site MVC, rails peut être plus pertinent, pour une web app, node.js le sera…), si il est assez mature, facile à appréhender, etc. Donc les benchmarks ne font pas tout dans le choix d’un langage pour un projet.

    • Ruby ne peut traiter qu’une seule requête par processus, ce qui oblige à utiliser plusieurs instances grace à des outils comme passenger notamment.
      Node.js peut traiter plusieurs requêtes par processus grace à son mode asynchrone (cf libuv).
      Par exemple quand tu attends le resultat d’une requete de base de données, node.js peut faire autre chose pendant ce temps, ce qui donne finalement des performances plus élevées qu’une application multi-thread équivalente qui aurait à gérer des section critiques.
      Pour conclure Node.js est plus performant que ruby et moins gourmant en ressources.

      • Hello !
        Super article, moi qui fait peu de js server, je me sent mieux ! ;)
        Qu’on soit clair, Ruby ne permet pas de traiter plus d’une requête simultanément. Ceci est du au GIL (Glbal Interpreter Lock). Pour ceux que ça inquiète vraiment, Rails tourne sur JRuby et même Rubinius qui eux gèrent les threads nativement et permettent donc de recevoir plusieurs requêtes simultanément.

        Maintenant je viens corriger le commentaire de Henri, Node.js ne traite PAS plusieurs requêtes simultanément. Comme Henri a pu le dire, la nature asynchrone permet a Node.js de simuler un travail parallèle, qui ne l’est en fait pas. Si 100 appels a la db sont fait, ils seront fait 1 par 1 et la réception de la réponse aussi :)

        Je ferais un post a propos de la concurrence, de l’asynchrone et du parallélisme, y’a plein de trucs a voir dedans !

        Ps : Ne pas comparer Node.js (Librarire) avec Ruby (Language) ;)

  2. Pour répondre à la dernière question il y a Nipster pour séparer le bon grain de l’ivraie
    http://eirikb.github.com/nipster

  3. iMeee

    Ruby est parfaitement capable de traiter plusieurs connexions concurrentes sur le même processus de manière asynchrone comme node.js. Des projets comme Event Machine ou Celluloïd permettent de faire de l’asynchrone en Ruby à conditions d’utiliser des librairies non brocantes dans leur exécution.

    D’ailleurs le “serveur d’application” Thin utilise Event Machine et est donc asynchrone.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>