Comment décider quand utiliser le noeud.js?

je suis nouveau à ce genre de choses, mais dernièrement j'ai entendu beaucoup sur la façon dont bon noeud.js est. Considérant combien j'aime travailler avec jQuery et JavaScript en général, je ne peux pas m'empêcher de me demander comment décider quand utiliser noeud.js. L'application web que j'ai en tête est quelque chose comme bit - prend un peu de contenu, l'archive.

de tous les devoirs que j'ai fait ces derniers jours, j'ai obtenu le informations suivantes. Nœud.js

  • est un outil en ligne de commande qui peut être exécuté comme un serveur web régulier et permet à un utilisateur D'exécuter des programmes JavaScript
  • utilise le grand V8 moteur JavaScript
  • 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 tous les merveilleux Ajax - comme des choses peuvent être faites sur le côté du serveur
  • permet de partager le code entre le navigateur et le backend
  • permet de parler avec MySQL

certaines des sources que j'ai rencontrées sont:

vu ce nœud.js peut être exécuté presque out-of-the-box sur Amazon EC2 instances, j'essaie de comprendre quel type de problèmes nécessitent un noeud.js par opposition à l'un des rois puissants là-bas comme PHP , Python et Ruby . Je comprendre que cela dépend vraiment de l'expertise que l'on a d'une langue, mais ma question relève davantage de la catégorie générale: quand utiliser un cadre particulier et à quel type de problèmes convient-il particulièrement?

2200
demandé sur Was 2011-02-21 08:20:51
la source

17 ответов

vous avez fait un excellent travail de résumer ce qui est génial sur Node.js. Mon sentiment est ce noeud.js est particulièrement adapté pour les applications où vous souhaitez maintenir une connexion persistante du navigateur vers le serveur. En utilisant une technique connue sous le nom "long-polling" , vous pouvez écrire une application qui envoie des mises à jour à l'utilisateur en temps réel. Faire de longs sondages sur la plupart des géants du web, comme Ruby on Rails ou Django , créerait une énorme charge sur le serveur, parce que chaque client actif consomme un processus serveur. Cette situation équivaut à une attaque tarpit . Quand vous utilisez quelque chose comme le noeud.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 le navigateur dans le noeud.js qui prend presque pas de ressources système pour servir un grand nombre de clients. Tout temps vous voulez faire ce genre de long-sondage, noeud.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 chose ( eventmachine et twisted , respectivement), mais ce noeud.js le fait exceptionnellement bien, et de bas en haut. JavaScript est exceptionnellement bien placé pour un modèle de concurrence basé sur le callback, et il excelle ici. Aussi, être capable de sérialiser et de desérialiser avec JSON natif à la fois pour le client et le serveur est assez chic.

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

il vaut la peine de souligner ce noeud.js est également idéal pour les situations dans lesquelles vous allez réutiliser beaucoup de code à travers l'écart client/serveur. Le Meteor framework rend cela vraiment facile, et beaucoup de gens suggèrent que cela pourrait être l'avenir du développement web. Je peux dire de l'expérience que c'est beaucoup de plaisir d'écrire du code dans Meteor, et une grande partie de cela passe moins de temps à penser à la façon dont vous allez restructurer vos données, de sorte que le code qui tourne dans le navigateur peut facilement le manipuler et le passer en arrière.

voici un article sur la pyramide et le long-sondage, qui s'avère être très facile à mettre en place avec un peu d'aide de gevent: TicTacToe et le long sondage avec la pyramide .

1359
répondu Benson 2014-05-14 19:56:33
la source

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

je devrais aussi mentionner cette prise.IO en combinaison avec noeud.js réduira votre latence en temps réel encore plus que ce qui est possible avec de longs sondages. Socket.IO se rabattra sur les sondages dans le pire des cas, utilisez plutôt des sockets web ou même Flash s'ils sont disponibles.

mais je dois également mentionner que juste à peu près n'importe quelle situation où le code pourrait bloquer en raison de threads peut être mieux adressée avec noeud.js. Ou toute situation où vous avez besoin que l'application soit axée sur les événements.

aussi, Ryan Dahl a dit dans un discours que j'ai une fois assisté que le noeud.les benchmarks js rivalisent étroitement avec Nginx pour les anciennes requêtes HTTP régulières. Donc, si nous construisons avec Nœud.js, nous pouvons servir nos ressources normales assez efficacement, et quand nous avons besoin de l'événement, il est prêt à le gérer.

Plus le JavaScript tout le temps. Lingua Franca sur toute la pile.

410
répondu fisherwebdev 2011-02-21 09:43:31
la source

raisons d'utiliser NodeJS:

  • il exécute Javascript, de sorte que vous pouvez utiliser le même langage sur le serveur et le client, et même partager un certain code entre eux (par exemple pour la validation de formulaire, ou pour rendre des vues à l'une ou l'autre extrémité.)

  • le monofiltre système entraîné par un événement est rapide même lors de la manipulation de lots des requêtes à la fois, et aussi simple, par rapport aux cadres multi-filetés traditionnels Java ou ROR.

  • le pool toujours croissant de paquets accessibles par NPM , y compris les bibliothèques/modules côté client et côté serveur, ainsi que des outils en ligne de commande pour le développement web. La plupart d'entre eux sont commodément hébergés sur github, où parfois vous pouvez signaler un problème et le trouver fixe en quelques heures! Il est agréable d'avoir tout sous un même toit, avec des rapports d'émission standardisés et fourche facile.

  • il est devenu l'environnement standard de defacto dans lequel exécuter Javascript-related tools et d'autres web-related tools , y compris les coureurs de tâches, les minifieurs, les embellisseurs, les linters, les préprocesseurs, les bundlers et les processeurs analytiques.

  • Il semble tout à fait approprié pour le prototypage, le développement agile et itération de produit rapide .

raisons pas pour utiliser NodeJS:

  • il exécute Javascript, qui n'a pas de contrôle de type de compilation. Pour les grands systèmes complexes critiques pour la sécurité , ou les projets incluant la collaboration entre différentes organisations, un langage qui encourage interfaces contractuelles et fournit contrôle de type statique peut vous faire économiser du temps de débogage (et explosions ) dans le long terme. (Bien que le JVM soit collé avec null , alors s'il vous plaît utilisez Haskell pour vos réacteurs nucléaires.)

  • ajouté à cela, beaucoup des paquets dans NPM sont un peu raw , et encore en développement rapide. Quelque bibliothèques pour les anciens cadres ont subi une décennie de tests et bugfixing, et sont très stable . Npmjs.org n'a pas de mécanisme pour évaluer les paquets , ce qui a conduit à une prolifération de paquets faisant plus ou moins la même chose, dont un fort pourcentage n'est plus maintenu.

  • Callback Hell imbriqué. (Bien sûr, il y a 20 solutions différentes à ce...)

  • le nombre toujours croissant de paquets peut faire apparaître un projet NodeJS radicalement différent du suivant. Il existe une grande diversité dans la mise en œuvre en raison du grand nombre d'options disponibles (par exemple, les voiles Express/ ).js / Meteor / Derby ). Cela peut parfois rendre plus difficile pour un nouveau développeur pour sauter sur un Nœud de projet. Contraste qu'avec un Rails développeur rejoindre un projet existant: il devrait être en mesure de se familiariser avec l'application assez rapidement, parce que toutes les applications Rails sont encouragés à utiliser une structure similaire .

  • traiter des fichiers peut être un peu pénible. Les choses qui sont triviales dans d'autres langues, comme lire une ligne à partir d'un fichier texte, sont assez bizarre à faire avec le noeud.js qu'il y a un StackOverflow question sur que avec 80+ upvotes. Il n'y a aucune façon simple de lire un enregistrement à la fois à partir D'un fichier CSV . Etc.

j'aime NodeJS, il est rapide et sauvage et amusant, mais je suis préoccupé qu'il a peu d'intérêt à la preuve-exactitude. Espérons que nous pouvons éventuellement fusionner le meilleur des deux mondes. Je suis impatient de voir ce qui remplacera noeud dans le futur... :)

209
répondu joeytwiddle 2017-05-23 13:31:35
la source

pour faire court:

Node.js est bien adapté pour les applications qui ont beaucoup de connexions simultanées et chaque requête ne nécessite que très peu de cycles CPU, parce que la boucle d'événement (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 le noeud.JS est le blog technique de Mixu: comprendre le noeud.js boucle d'événement .

208
répondu stewe 2014-03-14 22:20:25
la source

j'ai un exemple réel où J'ai utilisé le noeud.js. L'entreprise où je travaille a obtenu un client qui voulait avoir un simple site Web HTML statique. Ce site est pour la vente d'un article en utilisant PayPal et le client voulait également avoir un compteur qui montre la quantité d'articles vendus. Le Client s'attend à recevoir un grand nombre de visiteurs sur ce site web. J'ai décidé de faire le compteur en utilisant le noeud.js et L'Express .js cadre de.

Le Noeud.l'application js était simple. Obtenez le montant des articles vendus à partir d'un Redis base de données, augmenter le compteur lorsque l'article est vendu et servir la valeur du compteur aux utilisateurs via le API .

quelques raisons pour lesquelles j'ai choisi D'utiliser le noeud.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 en trois semaines et un minimum les 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 Nœud.module js pour PayPal.

dans ce cas, noeud.js était un choix génial.

127
répondu Joonas 2014-03-14 22:23:57
la source

les raisons les plus importantes pour commencer votre prochain projet en utilisant Node ...

  • Tous plus cool les mecs sont en elle ... donc doit être amusant.
  • vous pouvez traîner à la glacière et avoir beaucoup D'aventures nodales pour se vanter.
  • vous êtes un Pincher quand il s'agit des coûts d'hébergement cloud.
  • y a-t-il eu Cela fait avec les Rails
  • tu détestes IIS déploiements
  • votre ancien travail informatique devient plutôt ennuyeux et vous souhaitez que vous étiez dans une nouvelle Start-Up brillante.

à quoi s'attendre ...

  • vous vous sentirez en sécurité avec Express sans tout le bloatware serveur dont vous n'avez jamais eu besoin.
  • Fonctionne comme une fusée et d'échelles.
  • vous en rêvez. Vous l'avez installé. Le paquet de noeuds repo npmjs.org est le plus grand écosystème de bibliothèques open source dans le monde.
  • votre cerveau sera déformé dans le temps au pays des callbacks imbriqués ...
  • ... jusqu'à ce que vous appreniez à tenir vos promesses .
  • Sequelize et Passeport sont à votre nouvelle API amis.
  • déboguer principalement du code async va obtenir umm ... intéressant .
  • le Temps pour tous les Noders de maître Tapuscrit .

qui l'utilise?

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • voilà pourquoi ils sont passés au noeud .
105
répondu Tony O'Hagan 2016-08-16 13:14:20
la source

rien ne vaut Silver Bullet. Tout est livré avec des coûts qui lui sont associés. C'est comme si vous mangiez des aliments huileux, vous compromettez votre santé et les aliments sains ne viennent pas avec des épices comme les aliments huileux. Il s'agit d'un choix individuel, qu'il s'agisse de santé ou d'épices comme dans leur nourriture. Même manière, Node.js envisager à être utilisé dans un scénario spécifique. Si votre application ne correspond pas à ce scénario, vous ne devriez pas l'envisager pour votre développement d'application. Je mets juste ma pensée sur le même chose:

quand utiliser le noeud.JS

  1. si votre code côté serveur nécessite très peu de cycles cpu. Dans un autre monde, vous faites une opération sans blocage et n'avez pas d'algorithme lourd/travail qui consomme beaucoup de cycles CPU.
  2. si vous êtes de Javascript Back ground et à l'aise dans l'écriture de code fileté simple tout comme le côté client JS.

quand Pas pour utiliser le noeud.JS

  1. votre requête de serveur dépend d'un algorithme/travail de consommation de CPU lourd.

de l'Évolutivité de l'Examen avec le Noeud.JS

  1. Node.JS lui-même n'utilise pas tout le noyau du système sous-jacent et il est simple threadé par défaut, vous devez écrire la logique par votre propre pour utiliser multi processeur de noyau et le rendre multi threadé.

noeud.Js Alternatives

il y a une autre option à utiliser à la place du noeud.JS cependant Vert.x semble être assez prometteur et a beaucoup de fonctionnalités supplémentaires comme le polygot et de meilleures considérations d'évolutivité.

60
répondu ajay 2016-08-13 21:46:35
la source

une autre grande chose que je pense personne n'a mentionné sur le noeud.js est la communauté amazing, le système de gestion de paquets (npm) et la quantité de modules existants que vous pouvez inclure en les incluant simplement dans votre paquet.fichier json.

41
répondu BoxerBucks 2013-06-06 21:42:29
la source

mon morceau: nodejs est grand pour faire des systèmes en temps réel comme l'analyse, chat-apps, apis, serveurs publicitaires, etc. Merde, j'ai fait ma première application de chat en utilisant nodejs et socket.io moins de 2 heures et cela aussi pendant l'examen semaine!

Modifier

Cela fait plusieurs années que j'ai commencé à utiliser nodejs et je l'ai utilisé pour faire beaucoup de choses différentes, y compris des serveurs de fichiers statiques, des analyses simples, des applications de chat et bien plus encore. C'est mon avis sur le moment d'utiliser nodejs

quand utiliser

lors de la fabrication du système qui met l'accent sur la concurrence et la vitesse.

  • Prises uniquement les serveurs d'applications de chat, irc apps, etc.
  • réseaux sociaux qui mettent l'accent sur les ressources en temps réel comme la géolocalisation, Le flux vidéo, le flux audio, etc.
  • manipulation de petits morceaux de données vraiment rapide comme un analytics webapp.
  • Comme exposant un RESTE seulement de l'api.

quand ne pas utiliser

C'est un serveur web très polyvalent de sorte que vous pouvez l'utiliser où vous voulez mais probablement pas ces endroits.

  • blogs simples et sites statiques.
  • comme un serveur de fichiers statique.

Gardez à l'esprit que je suis tatillon. Les serveurs de fichiers, apache est mieux, principalement parce qu'il est largement disponible. La communauté nodejs est devenue plus grande et plus mature au fil des ans et il est sûr de dire nodejs peut être utilisé à peu près partout si vous avez votre propre choix d'hébergement.

37
répondu shash7 2014-09-12 17:07:38
la source

il peut être utilisé où

  • Applications qui sont fortement axées sur les événements et qui sont fortement liées aux e/s
  • Applications traitant un grand nombre de connexions à d'autres systèmes
  • applications en temps réel (Node.js a été conçu à partir du sol en temps réel et d'être facile utiliser.)
  • Applications jongler avec une flopée de l'information en streaming et en provenance d'autres sources
  • Une grande circulation des applications Évolutives
  • applications mobiles qui doivent parler à la plate-forme API & base de données, sans avoir à faire beaucoup de données analytics
  • construire des applications en réseau
  • Applications qui ont besoin de parler à l'arrière très souvent

sur le front Mobile, les entreprises aux heures de grande écoute se sont fiées au noeud.js pour leurs solutions mobiles. regardez pourquoi?

LinkedIn est un utilisateur important. Toute leur pile mobile est construite sur un noeud.js. Ils sont passés de l'exécution de 15 serveurs avec 15 instances sur chaque machine physique, à seulement 4 instances – qui peuvent gérer le double du trafic!

eBay lancé ql.io,un langage de requête Web pour les API HTTP, qui utilise le noeud.js comme la pile d'exécution. Ils ont été en mesure de mettre au point une station de travail Ubuntu régulière de qualité développeur pour gérer plus de 120 000 connexions actives par noeud.processus js, avec chaque connexion consommant environ 2KB de mémoire!

Walmart re-conçu son application mobile pour utiliser un Nœud.js et a poussé son traitement JavaScript sur le serveur.

pour en savoir plus: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js /

30
répondu Vinayak Bevinakatti 2015-12-17 20:01:42
la source

Nœud de mieux pour simultanées de traitement de la demande -

donc, commençons par une histoire. Depuis 2 ans, je travaille sur JavaScript et le développement front end web et je l'apprécie. Back end guys provide nous fournit quelques API écrites en Java, python (nous nous en fichons) et nous écrivons simplement un appel AJAX, obtenez nos données et devinez quoi ! nous avons terminé. Mais en réalité ce n'est pas si facile, si les données que nous obtenons ne sont pas correctes ou s'il y a une erreur de serveur alors nous avons collé et nous devons contacter nos gars back end sur le courrier ou chat (parfois sur whatsApp aussi:).) Ce n'est pas cool. Et si nous écrivions nos API en JavaScript et appelions ces API de notre front end ? Oui c'est assez cool parce que si nous faisons face à n'importe quel problème dans API nous pouvons regarder dedans. Devinez quoi ! tu peux faire ça maintenant , comment ? – Le nœud est là pour vous.

Ok a convenu que vous pouvez écrire votre API en JavaScript mais que faire si je suis ok avec le problème ci-dessus. Avez-vous d'autres raison d'utiliser le noeud pour L'API rest ?

voici donc le début de la magie. Oui, j'ai d'autres raisons d'utiliser node pour nos API.

revenons à notre système D'API rest traditionnel qui est basé soit sur l'opération de blocage, soit sur le filetage. Supposons que deux requêtes simultanées se produisent (r1 et r2) , chacune d'elles nécessite le fonctionnement de la base de données. Ainsi, dans le système traditionnel, que se passera-t-il:

1. Chemin D'Attente: Notre le serveur commence à servir la requête r1 et attend la réponse de la requête. après l'achèvement de r1 , le serveur commence à servir r2 et le fait de la même manière. Donc l'attente n'est pas une bonne idée car nous n'avons pas beaucoup de temps.

2. Notre serveur va créer deux threads pour les deux requêtes r1 et r2 et servir leur but après avoir interrogé la base de données afin de refroidir sa vitesse.Mais il consomme la mémoire parce que vous pouvez voir que nous avons démarré deux threads aussi des augmentations de problèmes lorsque les deux requêtes interrogent les mêmes données, alors vous avez à traiter avec des problèmes de type impasse . Si ses mieux que d'attendre façon, mais toujours des problèmes sont là.

maintenant voici, comment noeud le fera:

3. Nodeway: quand la même requête concurrente arrive dans le noeud alors il enregistrera un événement avec son callback et ira de l'avant il n'attendra pas la réponse de requête pour un requête particulière.Ainsi, lorsque la requête r1 arrive, la boucle d'Événement du noeud (oui, il y a une boucle d'événement dans le noeud qui sert ce but.) enregistrer un événement avec sa fonction de rappel et aller de l'avant pour servir r2 demande et même d'enregistrer son événement avec son rappel. Chaque fois que n'importe quelle requête termine il déclenche son événement correspondant et exécute son rappel à l'achèvement sans être interrompu.

Donc pas d'attente, pas de filetage , pas de consommation de mémoire - oui, ici nodeway pour servir L'API rest.

20
répondu Anshul 2015-01-17 00:00:15
la source

Mon une raison de plus pour choisir le Nœud.js pour un nouveau projet:

Être en mesure de faire pur basée sur le cloud de développement

j'ai utilisé Cloud9 IDE pendant un certain temps et maintenant je ne peux pas imaginer sans elle, il couvre tous les cycles de développement. Tout ce que vous avez besoin est un navigateur et vous pouvez coder à tout moment sur n'importe quel appareil. Vous n'avez pas besoin d'enregistrer le code dans un ordinateur(comme à à la maison), puis départ dans un autre ordinateur(comme sur le lieu de travail).

bien sûr, il y a peut-être de l'IDE basé sur le cloud pour d'autres langues ou plateformes (L'IDE de Cloud 9 ajoute des supports pour d'autres langues également), mais en utilisant Cloud 9 pour faire des Noeuds.js developement est vraiment une grande expérience pour moi.

16
répondu Sean Zhao 2014-02-18 12:14:59
la source

une autre chose que le noeud fournit est la possibilité de créer plusieurs instants v8 du noeud en utilisant le processus enfant du noeud ( childProcess.fork () nécessitant chacun 10mb de mémoire selon docs) à la volée, n'affectant donc pas le processus principal tournant le serveur. Ainsi, décharger une tâche de fond qui nécessite une énorme charge de serveur devient un jeu d'enfant et nous pouvons facilement les tuer en tant que de besoin.

j'ai utilisé node beaucoup et dans la plupart des applications nous construire, nécessite des connexions de serveur en même temps donc un trafic réseau lourd. Cadres comme Express.js et le nouveau Koajs (qui a enlevé callback hell) ont rendu le travail sur le noeud encore plus facile.

15
répondu I_Debug_Everything 2014-06-08 18:27:17
la source

Enfilage de l'amiante longjohns...

Hier, mon titre avec Packt Publications, Réactif de Programmation avec JavaScript . Il n'est pas vraiment un Nœud.titre js-centric; premiers chapitres sont destinés à couvrir la théorie, et plus tard code-chapitres lourds couvrent la pratique. Parce que je ne pensais pas vraiment qu'il serait approprié de ne pas donner aux lecteurs un serveur web, un noeud.js semblait de loin le choix évident. L'affaire a été close avant même son ouverture.

j'aurais pu donner une vue très rose de mon expérience avec Node.js. Au lieu de cela, j'ai été honnête sur les bons points et les mauvais points que j'ai rencontrés.

permettez-moi d'inclure quelques citations qui sont pertinentes ici:

Avertissement: Noeud.js et son écosystème sont chaud --assez chaud pour brûler de mal!

lorsque j'étais l'assistant d'un enseignant en mathématiques, l'une des suggestions non évidentes qui m'a été faite était de ne pas dire à un élève que quelque chose était "facile"."La raison était un peu évidente en rétrospective: si vous dites aux gens que quelque chose est facile, quelqu'un qui ne voit pas de solution peut finir par se sentir (encore plus) stupide, parce que non seulement ils ne parviennent pas à résoudre le problème, mais le problème qu'ils sont trop stupides pour comprendre est un problème facile!

il y a gotchas qui ne fait pas que déranger les gens venant de Python / Django, qui recharge immédiatement la source si vous changez quoi que ce soit. Avec Le Noeud.js, le comportement par défaut est que si vous faites une modification, l'ancienne version reste active jusqu'à la fin des temps ou jusqu'à ce que vous arrêtiez et redémarriez manuellement le serveur. Ce comportement inapproprié ne dérange pas seulement Pythonistas; il irrite également noeud natif.utilisateurs de js qui fournissent diverses solutions de rechange. La question StackOverflow " auto-rechargement des fichiers dans le noeud.js" a, au moment de cet écrit, plus de 200 upvotes et 19 réponses; une édition dirige l'utilisateur à un script nounou, noeud-superviseur, avec la page d'accueil à http://tinyurl.com/reactjs-node-supervisor . Ce problème permet aux nouveaux utilisateurs avec une grande occasion de se sentir stupide parce qu'ils pensaient qu'ils avaient corrigé le problème, mais l'ancien, comportement buggy est complètement inchangé. Et il est facile d'oublier de faire rebondir le serveur; je l'ai fait plusieurs fois. Et le message que je voudrais donner est: "Non, vous n'êtes pas stupide, parce que ce comportement de Nœud.js t'a mordu le dos, c'est juste que les designers de Node.js n'a vu aucune raison de fournir un comportement approprié ici. Essayez de faire face avec elle, peut-être en prenant un peu d'aide de noeud-superviseur ou une autre solution, mais s'il vous plaît ne marchez pas loin en se sentant que vous êtes stupide. Vous n'êtes pas le problème; le problème est dans le Nœud.le comportement par défaut de js."

cette section, Après un certain débat, a été laissée dans, précisément parce que je ne veux pas donner une impression de "C'est facile."Je me suis coupé les mains à plusieurs reprises tout en faisant fonctionner les choses, et je ne veux pas aplanir les difficultés et vous mettre en place pour croire que Obtenir noeud.js et son écosystème pour bien fonctionner est une question simple et si ce n'est pas simple pour vous aussi, vous ne savez pas ce que vous faites. Si vous ne rencontrez pas des difficultés désagréables en utilisant Node.js, c'est merveilleux. Si tu le fais, j'espère que tu ne t'en vas pas en pensant: stupide-il doit y avoir quelque chose de mal avec moi."Vous n'êtes pas stupide si vous rencontrez de mauvaises surprises traitant avec noeud.js. Ce n'est pas vous! C'est le Nœud.js et son écosystème!

L'Annexe, que je n'ai pas vraiment voulu après le crescendo ascendant dans les derniers chapitres et la conclusion, parle de ce que j'ai pu trouver dans l'écosystème, et a fourni une solution de contournement pour la littérature moronique:

une autre base de données qui semblait comme un ajustement parfait, et peut-être encore être échangeable, est une implémentation côté serveur du HTML5 key-value store. Cette approche a l'avantage fondamental d'une API que la plupart des bons développeurs initiaux comprennent assez bien. D'ailleurs, c'est aussi une API que la plupart des développeurs initiaux qui ne sont pas si bons comprennent assez bien. Mais avec le paquet node-localstorage, alors que l'accès à la syntaxe du dictionnaire n'est pas offert (vous voulez utiliser localStorage.setItem (clé, valeur) ou localStorage.getItem(clé), pas localStorage[key]), la sémantique complète localStorage sont mis en œuvre, y compris un quota par défaut de 5 Mo- pourquoi? les développeurs JavaScript côté serveur doivent-ils être protégés d'eux-mêmes?

pour les capacités de base de données côté client, un quota de 5 Mo par site web est vraiment une quantité généreuse et utile de respiration pour permettre aux développeurs de travailler avec elle. Vous pourriez définir un quota beaucoup plus faible et encore offrir aux développeurs une amélioration incommensurable sur la boiterie le long avec la gestion des cookies. Une limite de 5 Mo ne se prête pas très rapidement au traitement de gros données côté client, mais il y a une allocation vraiment très généreuse que les développeurs ingénieux peuvent utiliser pour faire beaucoup. Mais d'un autre côté, 5 Mo n'est pas une partie particulièrement grande de la plupart des disques achetés n'importe quand récemment, ce qui signifie que si vous et un site Web en désaccord sur ce qui est une utilisation raisonnable de l'espace disque, ou un site est tout simplement hoggish, il ne vous coûte pas vraiment beaucoup et vous n'êtes pas en danger d'un débordement disque dur sauf si votre disque dur était déjà trop plein. Peut-être que nous serions mieux lotis si le solde était un peu moins ou un peu plus, mais dans l'ensemble, c'est une bonne solution pour régler la tension intrinsèque pour un contexte côté client.

cependant, il pourrait être légèrement souligné que lorsque vous êtes le seul code d'écriture pour votre serveur, vous n'avez pas besoin d'une protection supplémentaire de faire votre base de données plus qu'une taille acceptable de 5MB. La plupart des développeurs n'auront pas besoin voulez des outils agissant comme nounou et les protégeant de stocker plus de 5 Mo de données côté serveur. Et le quota de 5 Mo qui est un jeu d'équilibre d'or du côté du client est plutôt un peu idiot sur un noeud.js serveur. (Et, pour une base de données pour plusieurs utilisateurs telle que décrite dans cette annexe, il pourrait être souligné, légèrement douloureusement, que ce n'est pas 5 Mo par compte d'utilisateur à moins que vous ne créiez une base de données distincte sur le disque pour chaque compte d'utilisateur; c'est 5 Mo partagés entre tous les comptes d'Utilisateur ensemble. Que pourrait obtenir douloureux si vous aller virale!) La documentation indique que le quota est personnalisable, mais un e-mail envoyé il y a une semaine au développeur demandant comment modifier le quota est sans réponse, tout comme la question de StackOverflow demandant la même chose. La seule réponse que j'ai pu trouver est dans la source CoffeeScript de Github, où elle est listée comme un second argument entier optionnel pour un constructeur. Donc, c'est assez facile, et vous pouvez spécifier un contingent égal à un disque ou une partition taille. Mais en plus du portage d'une fonctionnalité qui n'a pas de sens, l'auteur de l'outil a complètement échoué à suivre une convention très standard d'interprétation de 0 comme signifiant "illimité" pour une variable ou une fonction où un entier doit spécifier une limite maximale pour une certaine utilisation de la ressource. La meilleure chose à faire avec cette déformation est probablement de spécifier que le quota est infini:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

la Permutation de deux commentaires dans l'ordre:

les gens se sont inutilement tiré dans le pied en utilisant constamment JavaScript comme un tout, et une partie de JavaScript étant rendu langage respectable était un Douglas Crockford disant en essence, "JavaScript comme un langage a des parties vraiment bonnes et des parties vraiment mauvaises. Voici les bonnes pièces. Juste oublier que n'importe quoi d'autre est là."Peut-être le chaud Nœud.js écosystème augmentera son propre "Douglas Crockford," qui vont dire, "Le Nœud.js écosystème est un codage Sauvage West, mais il y a de vraies gemmes à trouver. Voici une feuille de route. Ici sont les zones à éviter à tout prix. Voici les zones avec certains des paydirt les plus riches à trouver dans N'importe quelle langue ou environnement."

peut-être que quelqu'un d'autre peut prendre ces mots comme un défi, et suivre L'exemple de Crockford et écrire" les bonnes parties "et / ou" les meilleures parties " pour Noeud.js et son écosystème. J'aimerais acheter un exemplaire!!!

et vu le degré d'enthousiasme et de simples heures de travail sur tous les projets, il peut être justifié dans un an, ou deux, ou trois, de tempérer fortement toute remarque au sujet d'un écosystème immature faite au moment de la rédaction du présent document. Il pourrait vraiment faire sens dans cinq ans de dire, "le noeud 2015.l'écosystème de js comptait plusieurs champs de mines. Le Nœud 2020.l'écosystème js a plusieurs paradis."

15
répondu JonathanHayward 2015-09-04 15:15:48
la source

si votre application utilise principalement des API web, ou d'autres canaux io, donnez ou prenez une interface utilisateur, un noeud.js peut être un bon choix pour vous, en particulier si vous voulez éliminer la plus évolutive, ou, si votre langue principale dans la vie est javascript (ou javascript transpilers de toutes sortes). Si vous construisez des microservices, noeud.js est également correct. Nœud.js est également adapté pour tout projet qui est petit ou simple.

son principal argument de vente est qu'il permet aux la responsabilité pour les choses plutôt que l'habituel diviser. Un autre argument de vente justifiable est si votre main-d'œuvre est orientée javascript pour commencer.

au-delà d'un certain point cependant, vous ne pouvez pas dimensionner votre code sans de terribles hacks pour forcer la modularité, la lisibilité et le contrôle de flux. Certaines personnes aiment ces piratages, cependant, surtout venant d'un contexte javascript piloté par un événement, ils semblent familiers ou pardonnables.

en particulier, lorsque votre application doit effectuer des flux synchrones, vous commencez à saigner sur des solutions à moitié cuites qui vous ralentissent considérablement en termes de votre processus de développement. Si vous avez des pièces de calcul intensif dans votre application, tread avec la sélection prudente (seulement) noeud.js. Peut-être http://koajs.com / ou d'autres nouveautés soulagent ces aspects initialement épineux, par rapport à quand j'ai utilisé initialement noeud.js ou écrit.

9
répondu matanster 2015-03-19 00:41:27
la source

je peux partager quelques points où et pourquoi utiliser node js.

  1. pour les applications en temps réel comme le chat,l'édition collaborative mieux nous allons avec nodejs comme il est la base d'événements où l'événement de feu et les données aux clients à partir du serveur.
  2. Simple et facile à comprendre car il est javascript base où la plupart des gens ont idée.
  3. la plupart des applications web actuelles allant vers angular js & backbone, avec noeud il est facile d'interagir avec le code côté client comme les deux utiliseront des données json.
  4. beaucoup de plugins disponibles.

Inconvénients:-

  1. noeud supportera la plupart des bases de données, mais le meilleur est mongodb qui ne supportera pas les jointures complexes et autres.
  2. Erreurs De Compilation...le développeur doit gérer toutes les exceptions autrement sage si une application d'accord d'erreur va arrêter de travailler là où encore nous devons aller et le démarrer manuellement ou à l'aide de tout outil d'automatisation.

Conclusion:- Nodejs à utiliser pour des applications simples et en temps réel..si vous avez une très grande logique d'affaires et des fonctionnalités complexes mieux ne devrait pas utiliser nodejs. Si vous voulez construire une application avec chat et n'importe quelle fonctionnalité collaborative.. noeud peut être utilisé dans des pièces spécifiques et rester devrait aller avec votre technologie de commodité.

-2
répondu BEJGAM SHIVA PRASAD 2016-08-09 18:02:47
la source
  1. noeud est idéal pour les prototypes rapides, mais je ne l'utiliserais plus jamais pour quelque chose de complexe. J'ai passé 20 ans à développer une relation avec un compilateur et ça me manque.

  2. noeud est particulièrement douloureux pour maintenir le code que vous n'avez pas visité depuis un certain temps. Les informations de Type et la détection d'erreurs de compilation sont de bonnes choses. Pourquoi jeter tout ça? Pour quoi faire? Et dang, quand quelque chose va vers le sud la pile trace tout à fait souvent complètement inutiles.

-3
répondu mbert65 2015-01-06 13:45:25
la source

Autres questions sur