Comment décider quand utiliser Node.js ?
Je suis novice dans ce domaine, mais ces derniers temps, j’ai beaucoup entendu parler de la qualité de [Node.js][1]. Étant donné que j'aime beaucoup travailler avec jQuery et JavaScript en général, je ne peux m'empêcher de me demander comment décider quand utiliser Node.js. L'application web que j'ai en tête ressemble à [Bitly][2] : elle prend du contenu et l'archive.
De tous les devoirs que j'ai faits ces derniers jours, j'ai obtenu les informations suivantes. Node.js
- est un outil en ligne de commande qui peut être exécuté comme un serveur web ordinaire et permet d'exécuter des programmes JavaScript.
- utilise l'excellent [moteur JavaScript V8][3].
- est très bon lorsque vous avez besoin de faire plusieurs choses en même temps
- est basé sur les événements, de sorte que toutes les merveilleuses fonctionnalités de type [Ajax][4] peuvent être exécutées du côté du serveur
- permet de partager le code entre le navigateur et le back-end
- nous permet de parler avec MySQL
Voici quelques-unes des sources que j'ai rencontrées :
- [Diving into Node.js - Introduction and Installation][5] (en anglais)
- Understanding NodeJS (en anglais)
- [Node by Example][7] ([Archive.is][13])
- [Fabriquons une application Web : NodePad][8].
Considérant que Node.js peut être exécuté presque prêt à l'emploi sur les instances EC2 d'[Amazon][9], j'essaie de comprendre quel type de problèmes nécessite Node.js par opposition à l'un des rois puissants là-bas comme [PHP][10], [Python][11] et [Ruby][12]. Je comprends que cela dépend vraiment de l'expertise que l'on a sur un langage, mais ma question tombe plus dans la catégorie générale de : Quand utiliser un framework particulier et à quel type de problèmes est-il particulièrement adapté ?
[1] : http://en.wikipedia.org/wiki/Node.js [2] : https://en.wikipedia.org/wiki/Bitly [3] : http://en.wikipedia.org/wiki/V8_%28JavaScript_engine%29 [4] : http://en.wikipedia.org/wiki/Ajax_%28programming%29 [5] : http://www.stoimen.com/blog/2010/11/16/diving-into-node-js-introduction-and-installation/
[7] : http://blog.osbutler.com/categories/node-by-example/?page=3 [8] : http://dailyjs.com/2010/11/01/node-tutorial/ [9] : http://en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud [10] : http://en.wikipedia.org/wiki/PHP [11] : http://en.wikipedia.org/wiki/Python_%28programming_language%29 [12] : http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 [13] : http://archive.is/exhaR
Vous avez fait un excellent travail en résumant ce qui est génial à propos de Node.js. Mon sentiment est que Node.js est particulièrement adapté aux applications où vous souhaitez maintenir une connexion persistante du navigateur vers le serveur. En utilisant une technique connue sous le nom de ["long-polling"][1], vous pouvez écrire une application qui envoie des mises à jour à l'utilisateur en temps réel. Faire du long polling sur de nombreux géants du web, comme [Ruby on Rails][2] ou [Django][3], créerait une charge immense sur le serveur, car chaque client actif consomme un processus serveur. Cette situation équivaut à une attaque de type [tarpit][4]. Lorsque vous utilisez quelque chose comme Node.js, le serveur n'a pas besoin de maintenir des threads séparés pour chaque connexion ouverte.
Cela signifie que vous pouvez créer une [application de chat basée sur un navigateur][5] en Node.js qui n'utilise pratiquement aucune ressource système pour servir un grand nombre de clients. À chaque fois que vous voulez faire ce genre de long sondage, Node.js est une excellente option.
Il est intéressant de mentionner que Ruby et Python ont tous deux des outils pour faire ce genre de choses ([eventmachine][6] et [twisted][7], respectivement), mais que Node.js le fait exceptionnellement bien, et depuis le début. JavaScript est exceptionnellement bien situé pour un modèle de concurrence basé sur le callback, et il excelle ici. De plus, la possibilité de sérialiser et de désérialiser avec du JSON natif à la fois pour le client et pour le serveur est assez géniale.
J'ai hâte de lire les autres réponses, c'est une question fantastique.
Il convient de souligner que Node.js est également idéal pour les situations dans lesquelles vous réutiliserez une grande partie du code entre le client et le serveur. Le [framework Meteor][8] rend cela très facile, et beaucoup de gens suggèrent que cela pourrait être l'avenir du développement web. Je peux dire par expérience que c'est très amusant d'écrire du code dans Meteor, et une grande partie de cela consiste à passer moins de temps à réfléchir à la façon dont vous allez restructurer vos données, de sorte que le code qui s'exécute dans le navigateur puisse facilement les manipuler et les renvoyer.
Voici un article sur Pyramid et le long-polling, qui s'avère très facile à mettre en place avec un peu d'aide de gevent : [TicTacToe et Long Polling avec Pyramid][9].
[1] : http://en.wikipedia.org/wiki/Push_technology#Long_polling [2] : http://en.wikipedia.org/wiki/Ruby_on_Rails [3] : http://en.wikipedia.org/wiki/Django_%28web_framework%29 [4] : http://en.wikipedia.org/wiki/Tarpit_ (réseau) [5] : https://github.com/rivalslayer/node_chat [6] : http://rubyeventmachine.com/ [7] : https://twistedmatrix.com/trac/ [8] : http://meteor.com [9] : http://michael.merickel.org/2011/6/21/tictactoe-and-long-polling-with-pyramid/
Je pense que Node.js est le mieux adapté aux applications en temps réel : jeux en ligne, outils de collaboration, salons de discussion, ou tout ce qu'un utilisateur (ou un robot ? ou un capteur ?) fait avec l'application doit être vu par les autres utilisateurs immédiatement, sans rafraîchissement de la page.
Je dois également mentionner que Socket.IO, combiné à Node.js, réduira votre latence en temps réel encore plus que ce qui est possible avec un long polling. Socket.IO se rabattra sur le polling long dans le pire des cas, et utilisera à la place les sockets web ou même Flash s'ils sont disponibles.
Mais je dois aussi mentionner que Node.js est la meilleure solution pour toutes les situations où le code peut bloquer à cause des threads. Ou toute situation où vous avez besoin que l'application soit pilotée par des événements.
En outre, Ryan Dahl a dit dans une conférence à laquelle j'ai assisté une fois que les benchmarks Node.js rivalisent étroitement avec Nginx pour les vieilles requêtes HTTP ordinaires. Donc, si nous construisons avec Node.js, nous pouvons servir nos ressources normales de manière assez efficace, et lorsque nous avons besoin de choses pilotées par les événements, il est prêt à les gérer.
De plus, c'est tout JavaScript, tout le temps. Lingua Franca sur l'ensemble de la pile.
Pour faire court :
Node.js est bien adapté aux applications qui ont beaucoup de connexions simultanées et chaque demande ne nécessite que très peu de cycles CPU, car la boucle d'événements (avec tous les autres clients) est bloquée pendant l'exécution d'une fonction.
Un bon article sur la boucle d'événement dans Node.js est [Mixu's tech blog : Understanding the node.js event loop][1].
[1] : http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/