Comment décider quand utiliser Node.js?

Question

Je suis nouveau sur ce genre de trucs, mais dernièrement, j'ai entendu beaucoup de choses sur comment bon Node.js est. Considérant combien j'aime travailler avec jQuery et JavaScript en général, je ne peux pas aider mais se demander comment décider quand utiliser Node.js. L'application web que j'ai à l'esprit est quelque chose comme Bitly - prend un peu de contenu, les services d'archives.

De tous les devoirs, je l'ai fait dans les derniers jours, j'ai obtenu les informations suivantes. Node.js

• est un outil de ligne de commande qui peut être exécuté comme un régulier serveur web et permet d'exécuter des programmes JavaScript
• utilise le grand moteur JavaScript V8
• est très bon, lorsque vous avez besoin de faire plusieurs choses en même temps
• est basé sur des événements de sorte que tous les merveilleux Ajax-comme des choses peut être fait sur le côté serveur
• nous permet de partager du code entre le navigateur et le backend
• nous permet de parler avec MySQL

Certaines des sources que j'ai rencontré sont:

• Plongée dans Node.js – Introduction et Installation
• La Compréhension De NodeJS
• Nœud par Exemple
• Nous allons Faire une Web App: NodePad

Considérant que Node.js peut être exécuté près de dehors-de-le-boîte sur Amazon EC2 cas, je suis en train d'essayer de comprendre de quel type de problèmes exigent Node.js contrairement à l'un des rois puissants là-bas comme PHP, Python et Ruby. Je comprends que cela dépend vraiment de l'expertise que l'on a sur la langue, mais ma question est davantage dans la catégorie général de l': Lors de l'utilisation d'un cadre et de ce type de problèmes est particulièrement adapté pour?

Answer 1

Vous avez fait un excellent travail de résumer ce qui est génial à propos de Node.js. Mon sentiment est que Node.js est particulièrement adapté pour des applications où vous voulez maintenir une connexion permanente à partir du navigateur vers le serveur. En utilisant une technique connue sous le nom de"long polling", vous pouvez écrire une application qui envoie des mises à jour à l'utilisateur en temps réel. Faire de longues interrogation sur la plupart des géants du web, comme Ruby on Rails ou Django, serait de créer une immense charge sur le serveur, parce que chaque client actif mange un processus de serveur. Cette situation équivaut à une tar pit attaque. 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 base de navigateur d'application de chat en Node.js qui prend presque pas de ressources système pour servir un grand nombre de clients. Toutes les fois que vous voulez faire ce genre de long-polling, Node.js est une excellente option.

Il est important de mentionner que Ruby et Python ont tous deux des outils pour faire ce genre de chose (eventmachine et tordu, respectivement), mais que Node.js est-il exceptionnellement bien, et à partir du sol. JavaScript est exceptionnellement bien situé pour un rappel à base de modèle d'accès simultané, et il excelle ici. Aussi, le fait de pouvoir sérialiser et désérialiser avec JSON natif à la fois le client et le serveur est assez chouette.

J'ai hâte de lire les autres réponses ici, c'est une question fantastique.

Il est intéressant de souligner que Node.js est également idéal pour les situations dans lesquelles vous serez en réutilisant beaucoup de code dans le client/serveur à l'écart. Le Météore cadre fait vraiment facilement, et beaucoup de gens sont ce qui suggère que cela pourrait être l'avenir du développement web. Je peux dire par expérience que c'est beaucoup de plaisir à écrire du code dans le Météore, et une grande partie de cela est de passer moins de temps à penser à comment vous allez restructurer vos données, de sorte que le code qui s'exécute dans le navigateur peut facilement manipuler et de les retransmettre.

Voici un article sur la Pyramide et le long du scrutin, qui s'avère être très facile à mettre en place avec un peu d'aide de gevent: TicTacToe et le Long du Scrutin avec Pyramide.

Answer 2

Je crois Node.js est le mieux adapté pour les applications en temps réel: des jeux en ligne, des outils de collaboration, salles de chat, ou quoi que ce soit où ce qu'un utilisateur (ou un robot? ou du capteur?) avec l'application doit être vu par d'autres utilisateurs immédiatement, sans un rafraichissement de la page.

Je dois aussi mentionner que les Socket.IO en combinaison avec Node.js permettra de réduire votre temps de latence encore plus loin que ce qui est possible avec le temps d'interrogation. Socket.IO va retomber le long du scrutin dans le pire des cas, et au lieu d'utiliser les web sockets ou même Flash si elles sont disponibles.

Mais je dois aussi mentionner que juste au sujet de n'importe quelle situation où le code pourra bloquer en raison des filets peuvent être mieux traitées avec Node.js. Ou toute autre situation où vous avez besoin de l'application pour être piloté par les événements.

Aussi, Ryan Dahl, a déclaré dans une conférence que j'ai une fois assisté à que la Node.js repères étroitement rival Nginx régulière de la vieille requêtes HTTP. Donc, si nous construisons avec Node.js nous pouvons servir nos ressources normales de façon très efficace, et quand nous avons besoin de l'événementiel substance, il est prêt à y faire face.

En Plus, c'est un JavaScript tout le temps. Lingua Franca sur l'ensemble de la pile.

Answer 3

Raisons d'utiliser NodeJS:

• Il exécute le Javascript, vous pouvez utiliser le même langage sur le serveur et le client, et même de partager du code entre eux (par exemple pour la validation d'un formulaire, ou à rendre des points de vue à chaque extrémité.)

• L'événementiel système est rapide, par rapport à traditionnel Java ou ROR cadres, lors de la manipulation de beaucoup de requêtes à la fois.

• L'essor de la piscine de paquets, dont la plupart sont idéalement hébergé sur github. Parfois, vous pouvez signaler un problème et de trouver qu'il fixe en quelques heures! C'est agréable d'avoir tout sous un même toit, avec normalisé question de rapports et facile de bifurquer.

• Semble plutôt adapté pour le développement agile et rapide des produits itération.

Raisons de ne pas utiliser NodeJS:

• Il exécute du Javascript, qui n'a pas de type de compilation vérification. Pour les complexes de grande taille critique pour la sécurité des systèmes, ou des projets, y compris la collaboration entre les différentes organisations, une langue qui encourage contractuelles interfaces et fournit statique type de vérification peut vous faire économiser un peu de débogage de temps (et d' explosions) dans le long terme. (Bien que la JVM est coincé avec null, alors veuillez utiliser Haskell pour votre réacteurs nucléaires.)

• Ajouté à cela, beaucoup de paquets dans les MNP sont un peu crus, et encore en cours de développement rapide. Certaines bibliothèques pour les anciens cadres ont subi une décennie de tests et bugfixing, et sont très stables . Npmjs.org n'a pas de mécanisme de taux de paquets, ce qui a conduit à une prolifération des packages de faire plus ou moins la même chose, dont un grand pourcentage n'est plus maintenu.

• Imbriquée rappel de l'enfer. (Bien sûr, il y a 20 différentes solutions à ce...)

• L'essor de la piscine de paquets peut faire un NodeJS projet radicalement différent de l'autre. Il existe une grande diversité dans les implémentations en raison du grand nombre d'options disponibles (p. ex. Express/Voiles.js/Météore/Derby). Cela peut parfois rendre plus difficile pour un nouveau développeur pour sauter sur un Nœud de projet. Voilà qui contraste avec un Rails de développeur de rejoindre un projet existant: il devrait être en mesure de se familiariser avec l'app assez rapidement, parce que tous les Rails applications sont encouragés à utiliser une structure similaire.

• À faire avec les fichiers peuvent être un peu de douleur. Les choses qui sont futiles dans d'autres langues, comme la lecture d'une ligne d'un fichier texte, sont assez étrange à voir avec Node.js qu'il y a une question sur StackOverflow que avec 80+ upvotes. Il n'y a pas de moyen simple de lire un enregistrement à la fois à partir d'un fichier CSV. Etc.

J'aime NodeJS, c'est rapide et sauvage et amusant, mais je suis préoccupé, il a peu d'intérêt dans prouvable-correction. Espérons que nous pouvons éventuellement fusionner le meilleur des deux mondes. Je suis impatient de voir ce qui va remplacer le Nœud dans le futur... :)

Answer 4

Pour faire court:

Node.js est bien adapté pour les applications qui ont beaucoup de connexions simultanées et chaque demande doit seulement très peu de cycles CPU, parce que la boucle d'événements (avec tous les autres clients) est bloqué lors de l'exécution d'une fonction.

Un bon article sur la boucle d'événements dans Node.js est Mixu tech blog: la Compréhension de la node.js boucle d'événements.

Answer 5

J'ai un exemple concret où j'ai utilisé Node.js. L'entreprise où j'ai eu un client qui voulait avoir un simple site HTML statique. Ce site est pour la vente d'un élément à l'aide de PayPal et que le client voulait avoir un compteur qui affiche le nombre d'articles vendus. Le Client devrait avoir énorme quantité de visiteurs à ce site web. J'ai décidé de faire le compteur à l'aide de Node.js et la Express.js cadre.

L'Node.js l'application est simple. Obtenir les articles vendus montant à partir d'un Redis base de données, augmenter le compteur lorsque l'objet est vendu et servir la contre-valeur pour les utilisateurs via les API.

Quelques raisons pour lesquelles j'ai choisi d'utiliser Node.js dans ce cas

1. Il est très léger et rapide. Il y a eu plus de 200000 visites sur ce site web, dans trois semaines, et un minimum de ressources du serveur a été en mesure de gérer tout cela.
2. Le compteur est vraiment facile à faire pour être en temps réel.
3. Node.js était facile à configurer.
4. Il y a beaucoup de modules disponibles gratuitement. Par exemple, j'ai trouvé un Node.js module PayPal.

Dans ce cas, Node.js était un super choix.