Question Qu'est-ce que Node.js? [fermé]


Je ne comprends pas complètement Node.js est tout au sujet de. Peut-être que c'est parce que je suis principalement un développeur d'applications Web. Qu'est-ce que c'est et à quoi ça sert?

Ma compréhension jusqu'à présent est la suivante:

  1. Le modèle de programmation est axé sur les événements, en particulier la façon dont il gère I / O.
  2. Il utilise JavaScript et l'analyseur est V8.
  3. Il peut être facilement utilisé pour créer des applications serveur simultanées.

Mes compréhensions sont-elles correctes? Si oui, alors quels sont les avantages des E / S événementielles, est-ce juste plus pour la concurrence? En outre, la direction de Node.js doit-elle devenir un modèle de programmation basé sur JavaScript (basé sur V8)?


507
2017-12-10 23:05


origine


Réponses:


Je pense que les avantages sont:

  1. Développement Web dans une langue dynamique (JavaScript) sur une VM incroyablement rapide (V8). C'est beaucoup plus rapide que Ruby, Python ou Perl.

  2. Possibilité de gérer des milliers de connexions simultanées avec une surcharge minimale sur un seul processus.

  3. JavaScript est parfait pour les boucles d'événements avec des objets de fonction et des fermetures de première classe. Les gens savent déjà comment l'utiliser de cette façon l'ayant utilisé dans le navigateur pour répondre aux événements initiés par l'utilisateur.

  4. Beaucoup de gens connaissent déjà JavaScript, même ceux qui ne prétendent pas être des programmeurs. C'est sans doute le langage de programmation le plus populaire.

  5. L'utilisation de JavaScript sur un serveur Web ainsi que sur le navigateur réduit l'inadéquation d'impédance entre les deux environnements de programmation qui peuvent communiquer des structures de données via JSON qui fonctionnent de la même manière des deux côtés de l'équation. Le code de validation de formulaire en double peut être partagé entre le serveur et le client, etc.


213
2017-12-14 19:37



J'utilise Node.js au travail et je trouve qu'il est très puissant. Obligé de choisir un mot pour décrire Node.js, je dirais "intéressant" (ce qui n'est pas un adjectif purement positif). La communauté est dynamique et en pleine croissance. JavaScript, malgré ses étrangetés, peut être un bon langage pour coder. Et vous allez chaque jour repenser votre propre compréhension des «meilleures pratiques» et des modèles de code bien structuré. Il y a une énorme énergie d'idées qui coule dans Node.js en ce moment, et y travailler vous expose à toutes ces pensées - un grand haltérophilie mentale.

Node.js en production est certainement possible, mais loin du déploiement "clé en main" apparemment promis par la documentation. Avec Node.js v0.6.x, "cluster" a été intégré dans la plate-forme, fournissant l'un des blocs de construction essentiels, mais mon script "production.js" est encore ~ ​​150 lignes de logique pour gérer des choses comme la création du journal annuaire, recyclage des travailleurs morts, etc. Pour un service de production "sérieux", vous devez également être prêt à limiter les connexions entrantes et à faire tout ce que fait Apache. PHP. Être juste, Ruby sur Rails a ceci exact problème. Il est résolu via deux mécanismes complémentaires: 1) Mettre Ruby on Rails / Node.js derrière un serveur web dédié (écrit en C et testé en enfer et en arrière) comme Nginx (ou Apache / Lighttd). Le serveur Web peut efficacement servir le contenu statique, accéder à la journalisation, réécrire les URL, terminer SSL, appliquer des règles d'accès et gérer plusieurs sous-services. Pour les demandes qui atteignent le service de nœud réel, le serveur Web transfère la requête par le biais de la requête. 2) En utilisant un cadre comme Licorne cela permettra de gérer les processus de travail, de les recycler périodiquement, etc. Je n'ai pas encore trouvé de framework de distribution Node.js qui semble complètement cuit; il peut exister, mais je ne l'ai pas encore trouvé et j'utilise toujours ~ 150 lignes dans mes "production.js".

Lecture des cadres comme Express Il semble que la pratique standard consiste simplement à tout servir par l'intermédiaire d'un service Node.js "jack-of-all-trades" ... "app.use (exprès.static (__ dirname + '/ public'))". Pour les services à faible charge et le développement, c'est probablement bien. Mais dès que vous essayez de mettre beaucoup de temps à votre service et que vous le faites fonctionner 24 heures sur 24 et 7 jours sur 7, vous découvrirez rapidement les motivations qui poussent les grands sites à avoir un code C bien durci Nginx faire face à leur site et gérer toutes les demandes de contenu statique (... jusqu'à ce que vous définissiez un CDN, comme Amazon CloudFront)). Pour un point de vue quelque peu humoristique et totalement négatif, voir ce mec.

Node.js trouve également de plus en plus d’utilisations hors service. Même si vous utilisez autre chose pour diffuser du contenu Web, vous pouvez toujours utiliser Node.js comme outil de génération, en utilisant NPM des modules pour organiser votre code, Naviguer pour le coudre en un seul atout, et uglify-js pour le réduire au déploiement. Pour traiter avec le web, JavaScript est parfait impédance et souvent cela en fait la voie d'attaque la plus facile. Par exemple, si vous voulez ramper à travers un tas de JSON charges utiles de réponse, vous devriez utiliser mon underscore-CLI module, la ceinture utilitaire de données structurées.

Avantages / inconvénients:

  • Pro: Pour un type de serveur, l'écriture de JavaScript sur le backend a été une «drogue de passage» à l'apprentissage des modèles d'interface utilisateur modernes. Je ne crains plus d'écrire du code client.
  • Pro: Tend à encourager la vérification correcte des erreurs (err est renvoyé par pratiquement tous les callbacks, harcelant le programmeur pour le manipuler, async.js et d'autres bibliothèques gèrent le paradigme "échouer si l'une de ces sous-tâches échoue" )
  • Pro: Certaines tâches intéressantes et normalement difficiles deviennent triviales - comme obtenir le statut sur les tâches en vol, communiquer entre les travailleurs, ou partager l'état du cache
  • Pro: communauté énorme et des tonnes de grandes bibliothèques basées sur un gestionnaire de paquets solide (npm)
  • Con: JavaScript n'a pas de bibliothèque standard. Vous êtes tellement habitué à importer des fonctionnalités qu'il vous semble étrange d'utiliser JSON.parse ou une autre méthode intégrée qui ne nécessite pas l'ajout d'un module npm. Cela signifie qu'il y a cinq versions de tout. Même les modules inclus dans le "noyau" Node.js ont cinq variantes supplémentaires si vous n'êtes pas satisfait de l'implémentation par défaut. Cela conduit à une évolution rapide, mais aussi à un certain niveau de confusion.

Versus un modèle simple d'un processus par requête (LAMPE):

  • Pro: extensible à des milliers de connexions actives. Très rapide et très efficace. Pour une flotte web, cela pourrait signifier une réduction de 10X du nombre de boîtes nécessaires par rapport à PHP ou Ruby
  • Pro: Ecrire des motifs parallèles est facile. Imaginez que vous deviez récupérer trois (ou N) blobs de Memcached. Fais cela en PHP ... as-tu juste écrit du code pour récupérer le premier blob, puis le second, puis le troisième? Wow, c'est lent. Il y a un spécial PECL Module pour résoudre ce problème spécifique pour Memcached, mais que se passe-t-il si vous souhaitez récupérer des données Memcached en parallèle avec votre requête de base de données? Dans Node.js, parce que le paradigme est asynchrone, avoir une requête web fait plusieurs choses en parallèle est très naturel.
  • Con: Le code asynchrone est fondamentalement plus complexe que le code synchrone, et la courbe d'apprentissage initiale peut être difficile pour les développeurs sans une solide compréhension de ce que signifie réellement l'exécution simultanée. Pourtant, c'est beaucoup moins difficile que d'écrire n'importe quel type de code multithread avec le verrouillage.
  • Con: Si une requête nécessitant beaucoup de temps de calcul dure, par exemple, 100 ms, elle bloquera le traitement des autres requêtes qui sont traitées dans le même processus Node.js ... AKA, coopératif-multitâche. Cela peut être atténué avec le modèle Web Workers (en supprimant un sous-processus pour gérer la tâche coûteuse). Sinon, vous pouvez utiliser un grand nombre de travailleurs Node.js et laisser chacun traiter une seule requête simultanément (encore assez efficace car il n'y a pas de processus de recyclage).
  • Con: Exécuter un système de production est BEAUCOUP plus compliqué qu'un CGI modèle comme Apache + PHP, Perl, RubisLes exceptions non gérées réduiront tout le processus, ce qui nécessitera une logique pour redémarrer les travailleurs défaillants (voir grappe). Les modules avec du code natif bogué peuvent bloquer le processus. Chaque fois qu'un travailleur meurt, toutes les demandes qu'il traite sont supprimées, donc une API buggué peut facilement dégrader le service pour d'autres API co-hébergées.

Par rapport à l'écriture d'un "vrai" service en Java / C # / C (C? Vraiment?)

  • Pro: Faire asynchrone dans Node.js est plus facile que de faire la sécurité des threads nulle part ailleurs et offre sans doute plus d'avantages. Node.js est de loin le paradigme asynchrone le moins douloureux dans lequel j'ai jamais travaillé. Avec de bonnes bibliothèques, ce n'est que légèrement plus difficile que d'écrire du code synchrone.
  • Pro: Pas de bogue multithreading / verrouillage. Vrai, vous investissez à l'avance dans l'écriture d'un code plus détaillé qui exprime un flux de travail asynchrone approprié sans opérations de blocage. Et vous devez écrire quelques tests et faire fonctionner la chose (c'est un langage de script et les noms de variables de doigté gras ne sont capturés qu'à l'heure de l'unité de test). MAIS, une fois que vous le faites fonctionner, la surface de heisenbugs - des problèmes étranges qui ne se manifestent qu'une fois sur un million de fois - cette surface est beaucoup plus faible. Les taxes écrivant le code Node.js sont lourdement chargées dans la phase de codage. Ensuite, vous avez tendance à vous retrouver avec un code stable.
  • Pro: JavaScript est beaucoup plus léger pour exprimer des fonctionnalités. Il est difficile de le prouver avec des mots, mais JSON, le typage dynamique, la notation lambda, l'héritage prototypique, les modules légers, peu importe ... cela prend moins de code pour exprimer les mêmes idées.
  • Con: Peut-être que vous aimez vraiment vraiment les services de codage en Java?

Pour une autre perspective sur JavaScript et Node.js, consultez De Java à Node.js, un article de blog sur les impressions et les expériences d'un développeur Java sur Node.js.


Modules Lorsque vous envisagez un noeud, gardez à l'esprit que votre choix de bibliothèques JavaScript DÉFINIR ton expérience. La plupart des gens en utilisent au moins deux, un assistant de modèle asynchrone (Step, Futures, Async) et un module de sucre JavaScript (Underscore.js).

Aide / JavaScript sucre:

  • Underscore.js - utilisez ceci. Fais-le. Il rend votre code agréable et lisible avec des choses comme _.isString (), et _.isArray (). Je ne suis pas vraiment sûr de savoir comment écrire un code sécurisé autrement. En outre, pour améliorer la ligne de commande-fu, consultez ma propre Underscore-CLI.

Modules de modèles asynchrones:

  • Étape - une manière très élégante d'exprimer des combinaisons d'actions en série et en parallèle. Ma recommandation personnelle. Voir mon message sur quoi ressemble le code Step.
  • Futures - une manière beaucoup plus flexible (est-ce vraiment une bonne chose?) d'exprimer les commandes en fonction des exigences. Peut exprimer des choses comme "commencer a, b, c en parallèle Quand A, et B finissent, démarrer AB Quand A, et C finir, démarrer AC." Une telle flexibilité nécessite plus de soin pour éviter les bogues dans votre flux de travail (comme ne jamais appeler le rappel, ou l'appeler plusieurs fois). Voir Le message de Raynos sur l'utilisation des futures (c'est le post qui m'a fait "get" futures).
  • Async - bibliothèque plus traditionnelle avec une méthode pour chaque modèle. J'ai commencé avec ceci avant ma conversion religieuse au pas et à la réalisation suivante que tous les modèles dans Async pourraient être exprimés dans l'étape avec un seul paradigme plus lisible.
  • TameJS - Ecrit par OKCupid, c'est un précompilateur qui ajoute une nouvelle langue primative "await" pour écrire élégamment des workflows en série et en parallèle. Le motif semble incroyable, mais il nécessite une pré-compilation. Je suis encore en train de me décider sur celui-ci.
  • StreamlineJS - concurrent de TameJS. Je me penche vers Tame, mais tu peux te décider.

Ou pour tout lire sur les bibliothèques asynchrones, voir cette interview en panel avec les auteurs.

Web Framework:

  • Express Grand framework Ruby on Rails-esk pour l'organisation de sites web. Il utilise JADE comme un moteur de template XML / HTML, ce qui rend la création de HTML beaucoup moins pénible, voire élégante.
  • jQuery Bien qu'il ne soit pas techniquement un module de nœud, jQuery devient rapidement un standard de facto pour l'interface utilisateur côté client. jQuery fournit des sélecteurs de type CSS pour «interroger» les ensembles d'éléments DOM qui peuvent ensuite être exploités (définir les gestionnaires, les propriétés, les styles, etc.). Dans le même ordre d'idées, Twitter Bootstrap Cadre CSS, Backbone.js pour un MVC motif, et Browserify.js pour assembler tous vos fichiers JavaScript dans un seul fichier. Ces modules sont tous en train de devenir des normes de facto, vous devriez donc au moins les vérifier si vous n'en avez pas entendu parler.

Essai:

  • JSHint - Doit utiliser; Je ne l'ai pas utilisé au début, ce qui semble maintenant incompréhensible. JSLint ajoute un tas de vérifications de base que vous obtenez avec un langage compilé comme Java. Parenthèses incompatibles, variables non déclarées, types de nombreuses formes et tailles. Vous pouvez également activer différentes formes de ce que j'appelle le "mode anal" où vous vérifiez le style des espaces et autres, ce qui est OK si c'est votre tasse de thé - mais la valeur réelle vient d'obtenir un retour instantané sur le numéro de ligne exact vous avez oublié une fermeture ")" ... sans avoir à exécuter votre code et à frapper la ligne incriminée. "JSHint" est une variante plus configurable de Douglas Crockfordde JSLint.
  • Moka concurrent aux vœux que je commence à préférer. Les deux frameworks gèrent assez bien les bases, mais les motifs complexes ont tendance à être plus faciles à exprimer dans Mocha.
  • Vœux Les vœux sont vraiment très élégants. Et il imprime un joli rapport (--spec) qui vous montre les cas de test réussis / échoués. Passez 30 minutes à l’apprendre et vous pouvez créer des tests de base pour vos modules avec un minimum d’efforts.
  • Zombi - Test sans tête pour HTML et JavaScript en utilisant JSDom en tant que "navigateur" virtuel. Des trucs très puissants. Combinez-le avec Rejouer pour obtenir des tests déterministes rapides de code in-browser.
  • Un commentaire sur la façon de «penser à» tester:
    • Les tests ne sont pas optionnels. Avec un langage dynamique comme JavaScript, il y a très peu de contrôles statiques. Par exemple, en passant deux paramètres à une méthode qui s'attend à ce que 4 ne se casse pas jusqu'à ce que le code soit exécuté. Barre assez basse pour créer des bogues en JavaScript. Les tests de base sont essentiels pour combler l'écart de vérification avec les langages compilés.
    • Oubliez la validation, faites simplement exécuter votre code. Pour chaque méthode, mon premier cas de validation est "rien ne casse", et c'est le cas qui se déclenche le plus souvent. Prouver que votre code s'exécute sans jeter attrape 80% des bogues et fera tellement pour améliorer la confiance de votre code que vous vous retrouverez en arrière et en ajoutant les cas de validation nuancés que vous avez omis.
    • Commencez petit et brisez la barrière inertielle. Nous sommes tous paresseux et pressés par le temps, et il est facile de voir le test comme un «travail supplémentaire». Alors commencez petit. Ecrivez le cas de test 0 - chargez votre module et signalez le succès. Si vous vous forcez à faire cela, alors la barrière inertielle aux tests est rompue. C'est moins de 30 minutes pour le faire la première fois, y compris la lecture de la documentation. Maintenant, écrivez le cas de test 1 - appelez l'une de vos méthodes et vérifiez que «rien ne casse», c'est-à-dire que vous n'obtenez pas d'erreur. Le test élémentaire 1 devrait vous prendre moins d'une minute. Avec l'inertie disparue, il devient facile d'étendre progressivement votre couverture de test.
    • Maintenant, faites évoluer vos tests avec votre code. Ne soyez pas intimidé par ce à quoi ressemblerait le test de bout en bout "correct" avec les serveurs fictifs et tout ça. Le code commence simple et évolue pour gérer de nouveaux cas; les tests devraient aussi. Lorsque vous ajoutez de nouveaux cas et une nouvelle complexité à votre code, ajoutez des cas de test pour exercer le nouveau code. Lorsque vous trouvez des bugs, ajoutez des vérifications et / ou de nouveaux cas pour couvrir le code défectueux. Lorsque vous déboguez et perdez confiance en un morceau de code, revenez en arrière et ajoutez des tests pour prouver qu'il fait ce que vous pensez. Capturez des chaînes de données d'exemple (provenant d'autres services que vous appelez, des sites Web que vous explorez, etc.) et transmettez-les à votre code d'analyse. Quelques cas ici, amélioration de la validation là-bas, et vous vous retrouverez avec un code très fiable.

En outre, consultez le liste officielle des modules Node.js recommandés. cependant, GitHub's  Modules de nœuds Wiki est beaucoup plus complet et une bonne ressource.


Pour comprendre Node, il est utile de prendre en compte quelques-uns des choix de conception clés:

Node.js est ÉVÉNEMENT BASÉ et ASYNCHRONE / NON-BLOQUANT. Les événements, comme une connexion HTTP entrante, déclencheront une fonction JavaScript qui effectuera un peu de travail et lancera d'autres tâches asynchrones telles que la connexion à une base de données ou l'extraction de contenu d'un autre serveur. Une fois que ces tâches ont été lancées, la fonction d'événement se termine et Node.js redevient actif. Dès que quelque chose d'autre se produit, comme la connexion à la base de données établie ou le serveur externe répondant avec le contenu, les fonctions de rappel se déclenchent et davantage de code JavaScript s'exécute, provoquant potentiellement encore plus de tâches asynchrones (comme une requête de base de données). De cette manière, Node.js se fera un plaisir d’entrelacer des activités pour plusieurs flux de travail parallèles, en exécutant les activités non bloquées à tout moment. C'est pourquoi Node.js fait un excellent travail en gérant des milliers de connexions simultanées.

Pourquoi ne pas utiliser un processus / thread par connexion comme tout le monde? Dans Node.js, une nouvelle connexion est juste une très petite allocation de tas. Le spinning d'un nouveau processus prend beaucoup plus de mémoire, un méga-octet sur certaines plateformes. Mais le coût réel est la surcharge associée au changement de contexte. Lorsque vous avez 10 ^ 6 threads de noyau, le noyau doit faire beaucoup de travail pour déterminer qui doit exécuter ensuite. Un tas de travail a été fait pour construire un planificateur O (1) pour Linux, mais au final, il est beaucoup plus efficace d'avoir un seul processus événementiel que 10 ^ 6 processus en compétition pour le temps CPU. De plus, dans des conditions de surcharge, le modèle multi-processus se comporte très mal, privant les services d'administration et de gestion critiques, en particulier SSHD (ce qui signifie que vous ne pouvez même pas vous connecter à la boîte pour savoir comment il est vraiment).

Node.js est SIMPLE FILET et VERROUILLAGE GRATUIT. Node.js, en tant que choix de conception très délibéré n'a qu'un seul thread par processus. Pour cette raison, il est fondamentalement impossible pour plusieurs threads d'accéder aux données simultanément. Ainsi, aucun verrou n'est nécessaire. Les fils sont durs. Vraiment très dur. Si vous ne le croyez pas, vous n'avez pas fait assez de programmation threadée. Obtenir un verrouillage correct est difficile et entraîne des bogues qui sont vraiment difficiles à localiser. L'élimination des verrous et du multi-threading fait disparaître l'une des classes de bogues les plus méchantes. Cela pourrait être le plus grand avantage du nœud.

Mais comment puis-je profiter de ma boîte 16 core?

Deux façons:

  1. Pour les grosses tâches de calcul lourdes comme le codage d'image, Node.js peut déclencher des processus enfants ou envoyer des messages à des processus de travail supplémentaires. Dans cette conception, vous auriez un thread gérant le flux des événements et N processus faisant de lourdes tâches de calcul et mâchant les 15 autres processeurs.
  2. Pour mettre à l'échelle le débit sur un service Web, vous devez exécuter plusieurs serveurs Node.js sur une boîte, une par cœur, en utilisant grappe (Avec Node.js v0.6.x, le module "cluster" officiel lié ici remplace la version d'learnboost qui a une API différente). Ces serveurs locaux Node.js peuvent alors rivaliser sur un socket pour accepter de nouvelles connexions, en équilibrant la charge entre eux. Une fois qu'une connexion est acceptée, elle devient étroitement liée à un seul de ces processus partagés. En théorie, cela semble mauvais, mais en pratique cela fonctionne plutôt bien et vous permet d'éviter le mal de tête d'écrire du code thread-safe. En outre, cela signifie que Node.js obtient une excellente affinité pour le cache du processeur, en utilisant plus efficacement la bande passante mémoire.

Node.js vous permet de faire des choses vraiment puissantes sans vous ruiner. Supposons que vous avez un programme Node.js qui effectue une variété de tâches, écoute sur un TCP port pour les commandes, encode certaines images, peu importe. Avec cinq lignes de code, vous pouvez ajouter un portail de gestion Web basé sur HTTP qui affiche l'état actuel des tâches actives. Cela est facile à faire:

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end(myJavascriptObject.getSomeStatusInfo());
}).listen(1337, "127.0.0.1");

Vous pouvez maintenant cliquer sur une URL et vérifier l'état de votre processus en cours. Ajoutez quelques boutons, et vous avez un "portail de gestion". Si vous avez un script Perl / Python / Ruby en cours d'exécution, il suffit de lancer un portail de gestion.

Mais JavaScript n'est-il pas lent / mauvais / mal / spawn-du-diable? JavaScript a des bizarreries étranges, mais avec "les bonnes parties" il y a un langage très puissant, et dans tous les cas, JavaScript est LE langage sur le client (navigateur). JavaScript est là pour rester; D'autres langues le ciblent comme un IL, et le talent de classe mondiale est en concurrence pour produire les moteurs JavaScript les plus avancés. En raison du rôle de JavaScript dans le navigateur, de gros efforts d’ingénierie sont déployés pour rendre JavaScript plus rapide. V8 est le dernier et le meilleur moteur javascript, au moins pour ce mois. Il souffle les autres langages de script dans l'efficacité et la stabilité (en vous regardant, Ruby). Et ça ne va que s'améliorer avec d'énormes équipes travaillant sur le problème chez Microsoft, Google et Mozilla, en compétition pour construire le meilleur moteur JavaScript (Ce n'est plus un "interpréteur" JavaScript car tous les moteurs modernes font des tonnes de JIT compiler sous le capot avec interprétation uniquement comme solution de repli pour le code execute-once). Oui, nous souhaitons tous que nous puissions réparer quelques-uns des choix de langage JavaScript les plus étranges, mais ce n’est vraiment pas si grave. Et le langage est tellement flexible que vous ne codez pas vraiment JavaScript, vous codez Step ou jQuery - plus que tout autre langage, en JavaScript, les bibliothèques définissent l'expérience. Pour construire des applications web, il faut à peu près connaître JavaScript, donc coder avec le serveur a une sorte de synergie de compétences. Cela m'a fait craindre d'écrire du code client.

En outre, si vous détestez vraiment JavaScript, vous pouvez utiliser du sucre syntaxique comme CoffeeScript. Ou toute autre chose qui crée du code JavaScript, comme Google Web Toolkit (GWT).

En parlant de JavaScript, qu'est-ce qu'une "fermeture"? - C'est une façon très sophistiquée de dire que vous conservez des variables lexicalement réparties entre les chaînes d'appels. ;) Comme ça:

var myData = "foo";
database.connect( 'user:pass', function myCallback( result ) {
    database.query("SELECT * from Foo where id = " + myData);
} );
// Note that doSomethingElse() executes _BEFORE_ "database.query" which is inside a callback
doSomethingElse();

Voyez comment vous pouvez juste utiliser "myData" sans rien faire de gênant comme le planquer dans un objet? Et contrairement à Java, la variable "myData" ne doit pas être en lecture seule. Cette fonction de langage puissante rend la programmation asynchrone beaucoup moins verbeuse et moins douloureuse.

L'écriture de code asynchrone sera toujours plus complexe que l'écriture d'un simple script monothread, mais avec Node.js, ce n'est pas si difficile et vous bénéficiez de nombreux avantages en plus de l'efficacité et de l'évolutivité de milliers de connexions simultanées. ..


620
2017-07-21 20:37



V8 est une implémentation de JavaScript. Il vous permet d'exécuter des applications JavaScript autonomes (entre autres).

Node.js est simplement une bibliothèque écrite pour V8 qui effectue des E / S avec événement. Ce concept est un peu plus compliqué à expliquer, et je suis sûr que quelqu'un va répondre avec une meilleure explication que moi ... L'essentiel est que plutôt que de faire des entrées ou des sorties et d'attendre que ça arrive, ne pas Attendez que ça finisse. Par exemple, demandez la dernière heure d'un fichier:

// Pseudo code
stat( 'somefile' )

Cela peut prendre quelques millisecondes, ou cela peut prendre quelques secondes. Avec evented I / O il vous suffit de déclencher la requête et, au lieu d'attendre, de joindre un rappel qui est exécuté à la fin de la requête:

// Pseudo code
stat( 'somefile', function( result ) {
  // Use the result here
} );
// ...more code here

Cela ressemble beaucoup à du code JavaScript dans le navigateur (par exemple, avec Ajax fonctionnalité de style).

Pour plus d'informations, vous devriez consulter l'article Node.js est vraiment excitant ce qui était mon introduction à la bibliothèque / plate-forme ... je l'ai trouvé très bien.


86
2017-12-10 23:19



Node.js est un outil de ligne de commande open source construit pour le code JavaScript côté serveur. Vous pouvez télécharger un tarball, compilez et installez la source. Il vous permet d'exécuter des programmes JavaScript.

Le JavaScript est exécuté par le V8, un moteur JavaScript développé par Google qui est utilisé dans Chrome navigateur. Il utilise une API JavaScript pour accéder au réseau et au système de fichiers.

Il est populaire pour ses performances et sa capacité à effectuer des opérations en parallèle.

Comprendre node.js est la meilleure explication de node.js J'ai trouvé jusqu'à présent.

Voici quelques bons articles sur le sujet.


36
2018-01-04 10:12



Les fermetures sont un moyen d'exécuter du code dans le contexte dans lequel il a été créé.

Ce que cela signifie pour la concurence est que vous pouvez définir des variables, puis initier un non-blocage I / O fonction, et lui envoyer une fonction anonyme pour son rappel.

Lorsque la tâche est terminée, la fonction de rappel s'exécutera dans le contexte avec les variables, il s'agit de la fermeture.

La raison pour laquelle les fermetures sont si bonnes pour écrire des applications avec des E / S non bloquantes est qu'il est très facile de gérer le contexte des fonctions qui s'exécutent de manière asynchrone.


13
2018-04-12 00:56



Deux bons exemples concernent la gestion des modèles et l’utilisation des améliorations progressives. Vous avez juste besoin de quelques morceaux légers de code JavaScript pour le faire fonctionner parfaitement.

Je vous recommande fortement de regarder et de lire ces articles:

Prenez n'importe quelle langue et essayez de vous rappeler comment vous géreriez vos modèles de fichiers HTML et ce que vous deviez faire pour mettre à jour un seul CSS nom de la classe dans votre DOM structure (par exemple, un utilisateur a cliqué sur un élément de menu et vous voulez qu'il soit marqué comme "sélectionné" et mettre à jour le contenu de la page).

Avec Node.js c'est aussi simple que de le faire dans le code JavaScript côté client. Obtenez votre noeud DOM et appliquez votre classe CSS à cela. Obtenez votre noeud DOM et innerHTML votre contenu (vous aurez besoin de code JavaScript supplémentaire pour cela.) Lisez l'article pour en savoir plus.

Un autre bon exemple, c'est que vous pouvez rendre votre page Web compatible à la fois avec JavaScript activé ou désactivé avec le même morceau de code. Imaginez que vous ayez une sélection de date faite en JavaScript qui permettrait à vos utilisateurs de prendre n'importe quelle date en utilisant un calendrier. Vous pouvez écrire (ou utiliser) le même code JavaScript pour le faire fonctionner avec votre JavaScript activé ou désactivé.


8
2018-02-28 23:44



Il y a une très bonne analogie de restauration rapide qui explique le mieux le modèle de Node.js, voir l'article complet, Node.js, les cabinets de médecin et les restaurants de restauration rapide - Comprendre la programmation axée sur les événements

Voici un résumé:

Si l'articulation de la restauration rapide suivait un modèle traditionnel à base de fil, vous pourriez commander votre nourriture et faire la queue jusqu'à ce que vous la receviez. La personne derrière vous ne serait pas en mesure de commander jusqu'à ce que votre commande a été faite. Dans un modèle axé sur les événements, vous commandez votre nourriture et vous sortez de la file d'attente pour attendre. Tout le monde est alors libre de commander.

Node.js est piloté par les événements, mais la plupart des serveurs Web sont basés sur des threads.York explique comment fonctionne Node.js:

  • Vous utilisez votre navigateur Web pour faire une demande pour "/about.html" sur un Node.js serveur web.

  • Le serveur Node.js accepte votre requête et appelle une fonction pour récupérer ce fichier à partir du disque.

  • Alors que le serveur Node.js attend le fichier à récupérer, il traite la prochaine requête Web.

  • Lorsque le fichier est récupéré, il y a une fonction de rappel qui est inséré dans la file d'attente des serveurs Node.js.

  • Le serveur Node.js exécute cette fonction qui dans ce cas affichez la page "/about.html" et renvoyez-la à votre navigateur Web. "


7
2017-12-19 23:28



Bien, je comprends que 

  • Le but de Node est de fournir un moyen facile   construire des programmes réseau évolutifs.
  • Node est similaire dans la conception et influencé par des systèmes tels que Ruby's Event Machine ou Python's Twisted.
  • E / S événementielles pour le javascript V8.

Pour moi, cela signifie que vous aviez raison dans les trois hypothèses. La bibliothèque a l'air prometteuse!


6
2017-12-10 23:17



Aussi, n'oubliez pas de mentionner que le V8 de Google est TRES rapide. Il convertit réellement le code JavaScript en code machine avec les performances correspondantes du binaire compilé. Donc, avec toutes les autres grandes choses, c'est incroyablement rapide.


6
2017-11-29 15:15



Q: Le modèle de programmation est axé sur les événements, en particulier la façon dont il gère I / O.

Correct. Il utilise des rappels, donc toute demande d'accès au système de fichiers entraînerait l'envoi d'une requête au système de fichiers, puis Node.js commencerait à traiter sa requête suivante. Il ne se soucierait que de la demande d'E / S après avoir reçu une réponse du système de fichiers, à quel moment il exécutera le code de rappel. Cependant, il est possible de faire des requêtes d'E / S synchrones (c'est-à-dire de bloquer des requêtes). C'est au développeur de choisir entre asynchrone (callbacks) ou synchrone (waiting).

Q: Il utilise JavaScript et l'analyseur est V8.

Oui

Q: Il peut être facilement utilisé pour créer des applications serveur simultanées.

Oui, bien que vous ayez besoin de coder à la main beaucoup de JavaScript. Il serait peut-être préférable d’examiner un cadre tel que http://www.easynodejs.com/ - qui comprend une documentation complète en ligne et un exemple d'application.


3
2018-03-09 12:47