javascript - tutorial - Comment décider quand utiliser Node.js?




node js how to install express (12)

  1. Node est idéal pour les prototypes rapides, mais je ne l'emploierais plus jamais pour des tâches complexes. J'ai passé 20 ans à développer une relation avec un compilateur et ça me manque.

  2. Node est particulièrement pénible pour le maintien du code que vous n'avez pas visité depuis un moment. La détection des erreurs de type et de compilation lors de la compilation est une bonne chose. Pourquoi jeter tout ça? Pour quoi? Et dang, quand quelque chose va au sud, la pile trace assez souvent complètement inutile.

Je suis novice dans ce genre de choses, mais ces derniers temps, j'ai beaucoup entendu parler de la qualité de Node.js 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 Node.js. L’application Web à laquelle je pense est quelque chose comme Bitly - prend du contenu, l’archive.

De tous les devoirs que j'ai faits ces derniers jours, j'ai obtenu les informations suivantes. Node.js

  • est un outil de ligne de commande qui peut être exécuté en tant que serveur Web classique et permet d'exécuter des programmes JavaScript
  • utilise le superbe moteur JavaScript V8
  • est très bon quand vous devez faire plusieurs choses en même temps
  • est basé sur des événements pour que tous les merveilleux trucs semblables à Ajax puissent être réalisés côté serveur
  • nous permet de partager le code entre le navigateur et le backend
  • laisse nous parler avec MySQL

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

Considérant que Node.js peut être exécuté presque tel quel sur les instances EC2 d'Amazon , j'essaie de comprendre quel type de problèmes nécessite Node.js par opposition à l'un des plus puissants rois de la planète tels que PHP , Python et Ruby . Je comprends que cela dépend vraiment de l’expertise que l’on possède sur une langue, mais ma question relève plutôt de la catégorie générale suivante: quand utiliser un cadre particulier et à quel type de problèmes s’adresse-t-il particulièrement?


Il n'y a rien comme Silver Bullet. Tout cela a un coût associé. C'est comme si vous mangiez des aliments gras, vous compromettriez votre santé et des aliments sains ne viennent pas avec des épices comme des aliments gras. C’est un choix individuel, qu’ils souhaitent avoir la santé ou des épices dans leur nourriture. De la même manière, Node.js considère être utilisé dans un scénario spécifique. Si votre application ne correspond pas à ce scénario, vous ne devriez pas en tenir compte pour le développement de votre application. Je ne fais que mettre ma pensée sur le même:

Quand utiliser Node.JS

  1. Si votre code côté serveur nécessite très peu de cycles de processeur. Dans un autre monde, vous effectuez une opération non bloquante et n'avez pas d'algorithme / travail lourd qui consomme de nombreux cycles de processeur.
  2. Si vous êtes issu de Javascript et que vous savez écrire du code à thread unique, tout comme JS côté client.

Quand NE PAS utiliser Node.JS

  1. Votre demande de serveur dépend d'un algorithme / travail gourmand en ressources processeur.

Considération d'évolutivité avec Node.JS

  1. Node.JS lui-même n'utilise pas tous les systèmes centraux sous-jacents et il est threadé par défaut, vous devez écrire votre propre logique pour utiliser un processeur multi-core et le rendre multi-threadé.

Node.JS Alternatives

Il existe une autre option à utiliser à la place de Node.JS. Cependant, Vert.x semble être très prometteur et comporte de nombreuses fonctionnalités supplémentaires telles que la polygot et une meilleure évolutivité.


J'ai un exemple concret où j'ai utilisé Node.js. La société dans laquelle je travaille a un client qui souhaite créer un site Web HTML simple et statique. Ce site Web est destiné à la vente d’un article à l’aide de PayPal . Le client souhaitait également disposer d’un comptoir indiquant le nombre d’articles vendus. Le client devrait avoir une énorme quantité de visiteurs sur ce site. J'ai décidé de faire le compteur en utilisant Node.js et le framework Express.js .

L'application Node.js était simple. Obtenez le montant des articles vendus dans une base de données Redis , augmentez le compteur lorsque l'article est vendu et transmettez la valeur du compteur aux utilisateurs via l' API .

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

  1. C'est très léger et rapide. Il y a eu plus de 200 000 visites sur ce site Web en trois semaines et des ressources de serveur minimales ont é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 module Node.js pour PayPal.

Dans ce cas, Node.js était un choix génial.


Je pense que Node.js est le mieux adapté aux applications en temps réel: jeux en ligne, outils de collaboration, salles de discussion ou tout ce qui fait qu'un utilisateur (ou un robot? Ou un capteur?) Fait avec l'application doit être vu par les autres utilisateurs immédiatement, sans actualisation de la page.

Je devrais également mentionner que Socket.IO associé à Node.js réduira votre latence en temps réel encore plus loin que ce qui est possible avec une longue interrogation. Socket.IO aura recours à une longue interrogation dans le pire des cas et utilisera plutôt des sockets Web ou même Flash s'ils sont disponibles.

Mais je devrais également mentionner que Node.js peut mieux traiter toutes les situations dans lesquelles le code peut bloquer en raison de threads. Ou toute situation dans laquelle l'application doit être pilotée par les événements.

En outre, Ryan Dahl a déclaré dans une conférence à laquelle j'ai assisté une fois que les repères de Node.js étaient très proches de Nginx pour les anciennes requêtes HTTP habituelles. Donc, si nous construisons avec Node.js, nous pourrons utiliser nos ressources normales de manière assez efficace, et lorsque nous aurons besoin de fonctionnalités événementielles, elles seront prêtes à fonctionner.

De plus, c'est tout le JavaScript tout le temps. Lingua Franca sur toute la pile.


Mon autre raison de choisir Node.js pour un nouveau projet est:

Être capable de faire du développement basé sur le cloud pur

J'ai utilisé Cloud9 IDE pendant un certain temps et je ne peux maintenant plus m'en passer, car il couvre tous les cycles de développement. Tout ce dont vous avez besoin est d’un navigateur et vous pouvez coder à tout moment n’importe où sur n’importe quel appareil. Vous n'avez pas besoin de saisir le code sur un ordinateur (comme à la maison), puis de le commander sur un autre ordinateur (comme au lieu de travail).

Bien sûr, il existe peut-être un IDE basé sur le cloud pour d’autres langues ou plates-formes (Cloud 9 IDE ajoute également des supports pour d’autres langues), mais utiliser Cloud 9 pour faire du développement Node.js est vraiment une expérience formidable pour moi.


Mon article: nodejs est idéal pour créer des systèmes en temps réel tels que des outils d'analyse, des applications de chat, des apis, des serveurs de publicité, etc. J'ai créé ma première application de chat avec nodejs et socket.io en moins de 2 heures, ainsi que pendant la semaine des examens!

modifier

Cela fait plusieurs années que j'ai commencé à utiliser nodejs et je l'ai utilisé pour créer de nombreuses choses, y compris des serveurs de fichiers statiques, des analyses simples, des applications de chat et bien plus encore. Ceci est mon point de vue sur l'utilisation de nodejs

Quand utiliser

Lors de la création d'un système mettant l'accent sur la concurrence et la vitesse.

  • Sockets uniquement les serveurs comme les applications de chat, irc, etc.
  • Les réseaux sociaux qui mettent l'accent sur les ressources en temps réel telles que la géolocalisation, le flux vidéo, le flux audio, etc.
  • Gérer très rapidement de petites quantités de données, comme une application Web d'analyse.
  • Comme exposant une seule api REST.

Quand ne pas utiliser

C'est un serveur Web très polyvalent, vous pouvez donc l'utiliser où vous voulez, mais probablement pas dans ces endroits.

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

Gardez à l'esprit que je ne fais que mordre. Pour les serveurs de fichiers statiques, apache est préférable, car il est largement disponible. La communauté de nodejs est devenue plus grande et plus mature au fil des ans et il est prudent de dire que les nodejs peuvent être utilisés un peu partout si vous avez le choix de votre propre hébergement.


Raisons d'utiliser NodeJS:

  • Il utilise Javascript, vous pouvez donc utiliser le même langage sur le serveur et le client, et même partager du code entre eux (par exemple, pour la validation de formulaire ou le rendu de vues à l'une ou l'autre extrémité.)

  • Le système single-threaded piloté par single-threaded événements est fast même lorsque vous traitez de nombreuses demandes à la fois, et simple, par rapport aux frameworks Java ou ROR multi-threadés traditionnels.

  • Le pool sans cesse croissant de packages accessibles via NPM , y compris des bibliothèques / modules côté client et serveur, ainsi que des outils de ligne de commande pour le développement Web. La plupart d'entre eux sont hébergés de manière pratique sur github, où vous pouvez parfois signaler un problème et le résoudre en quelques heures! Il est agréable de tout avoir sous un même toit, avec des rapports de problèmes normalisés et une numérisation facile.

  • Il est devenu l’environnement standard de facto dans lequel sont exécutés les outils liés à Javascript et d’autres outils liés au Web , notamment les gestionnaires de tâches, les minificateurs, les beautifiers, les linters, les pré-processeurs, les bundlers et les processeurs d’analyse.

  • Cela semble tout à fait approprié pour le prototypage, le développement agile et l'itération rapide du produit .

Raisons pour ne pas utiliser NodeJS:

  • Il utilise Javascript, qui n'a pas de vérification de type à la 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 les interfaces contractuelles et fournit une vérification de type statique peut vous faire économiser un temps de débogage (et des explosions ) à long terme. (Bien que la machine virtuelle Java soit bloquée avec la valeur null , veuillez utiliser Haskell pour vos réacteurs nucléaires.)

  • Ajoutés à cela, beaucoup de paquets dans NPM sont un peu crus et sont encore en développement rapide. Certaines bibliothèques de frameworks plus anciens ont subi une décennie de tests et de corrections de bugs, et sont maintenant très stables . Npmjs.org ne dispose d'aucun mécanisme d'évaluation des paquets , ce qui a entraîné une prolifération de paquets faisant plus ou moins la même chose, et dont un pourcentage important n'est plus maintenu.

  • Enfer imbriqué de rappel. (Bien sûr, il y a 20 solutions différentes à cela ...)

  • Le pool de packages en croissance constante peut faire en sorte qu'un projet NodeJS paraisse radicalement différent du suivant. Il existe une grande diversité d'implémentations en raison du grand nombre d'options disponibles (par exemple, Express / Sails.js / Meteor / Derby ). Cela peut parfois rendre plus difficile pour un nouveau développeur de se lancer dans un projet de nœud. Comparez cela avec un développeur Rails rejoignant un projet existant: il devrait être capable de se familiariser assez rapidement avec l'application, car toutes les applications Rails sont encouragées à utiliser une structure similaire .

  • Traiter des fichiers peut être un peu pénible. Les choses triviales dans d'autres langues, comme la lecture d'une ligne à partir d'un fichier texte, sont assez étranges pour faire avec Node.js qu'il existe une question à ce sujet avec plus de 80 votes positifs en amont. Il n'y a pas de moyen simple de lire un enregistrement à la fois à partir d'un fichier CSV . Etc.

J'adore NodeJS, c'est rapide, sauvage et amusant, mais je crains qu'il n'ait que peu d'intérêt à être prouvé. Espérons que nous pourrons éventuellement fusionner le meilleur des deux mondes. J'ai hâte de voir ce qui remplacera Node à l'avenir ... :)


Un autre élément fourni par le noeud est la possibilité de créer plusieurs versions v8 du noeud à l’aide du processus enfant du noeud ( childProcess.fork() chacun nécessitant 10 Mo de mémoire conformément à la documentation), sans affecter le processus principal exécutant le serveur. Donc, décharger un travail en arrière-plan qui nécessite une charge de serveur énorme devient un jeu d'enfant et nous pouvons facilement les tuer à tout moment.

J'utilise beaucoup de nœuds et dans la plupart des applications que nous construisons, des connexions au serveur sont requises en même temps, d'où un trafic réseau important. Des frameworks comme Express.js et les nouveaux Koajs (qui ont supprimé l'enfer de rappel) ont rendu le travail sur les nœuds encore plus facile.


Vous avez fait un excellent travail en résumant ce qui est génial avec Node.js. Mon sentiment est que Node.js est particulièrement adapté aux applications où vous souhaitez conserver une connexion persistante du navigateur au serveur. En utilisant une technique appelée "long-polling" , vous pouvez écrire une application qui envoie des mises à jour à l'utilisateur en temps réel. Faire de longues interrogations sur de nombreux géants du Web, comme Ruby on Rails ou Django , créerait une charge énorme sur le serveur, car chaque client actif consomme un processus serveur. Cette situation équivaut à une attaque de tarpit . 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 discussion basée sur un navigateur dans Node.js qui ne nécessite pratiquement aucune ressource système pour servir un grand nombre de clients. Node.js est une excellente option chaque fois que vous souhaitez effectuer ce type d'interrogation longue.

Il est intéressant de noter que Ruby et Python ont tous les deux des outils pour faire ce genre de choses ( eventmachine et twisted , respectivement), mais que Node.js le fait exceptionnellement bien, et ce, à partir de eventmachine . JavaScript est exceptionnellement bien placé pour un modèle de concurrence basé sur le rappel, et il excelle ici. De plus, être en mesure de sérialiser et de désérialiser avec JSON natif à la fois sur le client et sur le serveur est assez astucieux.

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

Il est intéressant de noter que Node.js est également idéal pour les situations dans lesquelles vous allez réutiliser beaucoup de code sur l’espace client / serveur. Le framework Meteor rend cela vraiment facile, et beaucoup de gens suggèrent que cela pourrait être l'avenir du développement web. Je peux dire d’expérience que c’est très amusant d’écrire du code dans Meteor, et qu’une grande partie de cela consomme moins de temps à réfléchir à la façon dont vous allez restructurer vos données, de sorte que le code exécuté dans le navigateur puisse facilement. manipulez-le et renvoyez-le.

Voici un article sur Pyramid et long-polling, qui s’avère très facile à configurer avec un peu d’aide de gevent: TicTacToe et Long Polling with Pyramid .


Noeud idéal pour la gestion des demandes simultanées -

Alors, commençons par une histoire. Depuis 2 ans, je travaille sur JavaScript et développe un front-end Web et je l'apprécie. Les gars du back end nous fournissent des API écrites en Java, python (on s'en moque) et nous écrivons simplement un appel AJAX, récupérons nos données et devinons quoi! nous avons fini. Mais en réalité, ce n’est pas si facile, si les données que nous obtenons ne sont pas correctes ou s’il ya une erreur de serveur, nous sommes bloqués et nous devons contacter notre équipe par courrier ou par chat (parfois aussi sur WhatsApp :)). c'est pas cool. Et si nous écrivions notre API en JavaScript et appelions ces API depuis notre site? Oui, c'est plutôt cool, car si nous rencontrons un problème avec l'API, nous pouvons l'examiner. Devine quoi ! vous pouvez le faire maintenant, comment? - Node est là pour vous.

Ok, vous pouvez écrire votre API en JavaScript, mais que se passe-t-il si le problème ci-dessus me convient? Avez-vous une autre raison d'utiliser l'API noeud pour reste?

alors voici la magie commence. Oui, j'ai d'autres raisons d'utiliser noeud pour nos API.

Revenons à notre système d'API repos traditionnel qui repose sur une opération de blocage ou un processus d'exécution. Supposons que deux demandes simultanées se produisent (r1 et r2), chacune d’elles nécessitant une opération de base de données. Donc, dans le système traditionnel, ce qui va arriver:

1. Manière d’attente: notre serveur commence à r1 demande r1 et attend la réponse à la requête. après la fin de r1 , le serveur commence à servir r2 et le fait de la même manière. Donc, attendre n'est pas une bonne idée car nous n'avons pas beaucoup de temps.

2. Manière de thread: Notre serveur crée deux threads pour les requêtes r1 et r2 et remplit leur fonction après avoir interrogé la base de données afin de le refroidir rapidement. Mais cela consomme de la mémoire car vous pouvez voir que nous avons démarré deux threads et que le problème augmente lorsque les deux requêtes interrogent mêmes données, vous devez faire face à des problèmes de type impasse. C'est donc mieux que d'attendre, mais les problèmes sont toujours là.

Maintenant, voici comment le noeud le fera:

3. Nodeway: lorsque la même requête concurrente arrive dans le nœud, il enregistre un événement avec son rappel et continue, il n'attend pas la réponse à une requête pour une requête particulière. Ainsi, lorsque la requête r1 arrive, la boucle d'événement du nœud (oui, il y a un événement). boucle dans le noeud qui sert à cette fin.) enregistre un événement avec sa fonction de rappel et avance pour servir la requête r2 et enregistre de la même manière son événement avec son rappel. Chaque fois qu'une requête est terminée, elle déclenche l'événement correspondant et exécute son rappel jusqu'à son terme sans interruption.

Donc, pas d’attente, pas de thread, pas de consommation de mémoire - oui, c’est nodeway pour servir l’API de repos


Je peux partager quelques points où et pourquoi utiliser le noeud js.

  1. Pour les applications en temps réel telles que la discussion en ligne, la retouche en collaboration, nous préférons utiliser nodejs car il s'agit de la base d'événements où les événements et les données sont déclenchés vers les clients depuis le serveur.
  2. Simple et facile à comprendre car il s'agit d'une base javascript où la plupart des gens ont une idée.
  3. La plupart des applications Web actuelles s’orientent vers le js angulaire et le backbone. Avec node, il est facile d’interagir avec le code côté client car les deux utilisent des données json.
  4. Beaucoup de plugins disponibles.

Désavantages:-

  1. Node supportera la plupart des bases de données, mais le mieux est mongodb qui ne supportera pas les jointures complexes et autres.
  2. Erreurs de compilation ... le développeur doit gérer chacune des exceptions d'une autre manière si une application d'accord d'erreur cesse de fonctionner, là où nous devons à nouveau la démarrer manuellement ou à l'aide d'un outil d'automatisation.

Conclusion: - Nodejs est préférable pour les applications simples et en temps réel. Si vous avez une très grande logique métier et des fonctionnalités complexes, ne devez pas utiliser nodejs. Si vous souhaitez créer une application en même temps que le chat et toute fonctionnalité collaborative, le nœud peut être utilisé dans des parties spécifiques et doit rester associé à votre technologie de pointe.


Si votre application fixe principalement une interface Web, ou d’autres canaux io, donnez ou prenez une interface utilisateur, node.js peut être un choix judicieux pour vous, en particulier si vous souhaitez obtenir le maximum d’évolutivité, ou si votre langue principale dans la vie est javascript (ou transpilers javascript de toutes sortes). Si vous créez des microservices, node.js est également acceptable. Node.js est également adapté à tout projet de petite taille ou simple.

Son principal argument de vente est de permettre aux utilisateurs d’assumer la responsabilité des opérations d’arrière-plan plutôt que de la division typique. Un autre argument de vente justifiable est que, dès le départ, votre personnel est orienté javascript.

Au-delà d’un certain seuil, vous ne pouvez pas redimensionner votre code sans de terribles piratages pour forcer la modularité, la lisibilité et le contrôle des flux. Cependant, certaines personnes aiment ces hacks, en particulier celles qui proviennent d’un contexte javascript événementiel, elles semblent familières ou pardonnables.

En particulier, lorsque votre application doit exécuter des flux synchrones, vous commencez à saigner des solutions à moitié cuites qui vous ralentissent considérablement en termes de processus de développement. Si vous avez des pièces qui nécessitent beaucoup de calcul dans votre application, faites attention à ne choisir que (noeud) node.js. Peut-être que Koajs ou d’autres nouveautés atténuent ces aspects initialement épineux, par rapport à la situation où j’avais utilisé node.js ou écrit ceci.





web-applications