web-dev-qa-db-fra.com

Qu'est-ce que Node.js?

Je ne comprends pas bien ce que Node.js concerne. C'est peut-être parce que je suis principalement un développeur d'applications métier basé sur le Web. De quoi s'agit-il et à quoi sert-il?

Ma compréhension jusqu'ici est que:

  1. Le modèle de programmation est basé sur les événements, en particulier sur la manière 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.

Est-ce que mes compréhensions sont correctes? Si oui, quels sont les avantages des E/S événementées? S'agit-il davantage de la concurrence? En outre, la direction de Node.js est-elle en train de devenir un cadre semblable à un modèle de programmation basé sur JavaScript (basé sur V8)?

javascriptnode.jsv8evented-io
506
Jeff

Je pense que les avantages sont:

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

  2. Capacité à gérer des milliers de connexions simultanées avec un temps système minimal sur un seul processus.

  3. JavaScript est parfait pour les boucles d'événement avec des objets fonction et des fermetures de première classe. Les gens savent déjà comment l'utiliser de cette manière, 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 le décalage d'impédance entre les deux environnements de programmation pouvant communiquer des structures de données via JSON fonctionnant 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
postfuturist

J'utilise Node.js au travail et le trouve très puissant. Forcé 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 croissance. JavaScript, malgré ses bizarreries, peut être un excellent langage pour coder. Et vous repenserez quotidiennement votre propre compréhension de la "meilleure pratique" et des modèles de code bien structuré. Node.js est actuellement doté d'une énorme énergie d'idées et son travail vous expose à toutes ces idées - un excellent haltérophilie mentale.

Node.js en production est certes 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é à la plate-forme, fournissant l'un des éléments de base essentiels, mais mon script "production.js" contient toujours environ 150 lignes de logique pour gérer des tâches telles que la création du journal. répertoire, recyclage des travailleurs morts, etc. Pour un service de production "sérieux", vous devez également être prêt à étrangler les connexions entrantes et à faire tout ce que fait Apache pour PHP . Pour être juste, Ruby on Rails a ce problème exact ==. Il est résolu via deux mécanismes complémentaires: 1) Placer Ruby on Rails/Node.js derrière un serveur Web dédié (écrit en C et testé à fond) comme Nginx (ou Apache / Lighttd ). Le serveur Web peut gérer efficacement le contenu statique, journaliser les accès, réécrire les URL, terminer SSL , appliquer les règles d'accès et gérer plusieurs sous-services. Pour les demandes qui atteignent le service de noeud réel, le serveur Web envoie un proxy à la demande. 2) Utilisation d'un cadre tel que nicorn qui gérera les processus de travail, les recyclera périodiquement, etc. Je n'ai pas encore trouvé de cadre de service Node.js qui semble totalement cuit; il existe peut-être, mais je ne l’ai pas encore trouvé et j’utilise toujours environ 150 lignes dans mon "production.js" roulé à la main.

La lecture de cadres tels que Express donne l’impression que la pratique habituelle est de tout servir par le biais d’un seul service polyvalent: Node.js ... "app.use (express.static (__ dirname + '/Publique'))". Pour les services et le développement à faible charge, c'est probablement très bien. Mais dès que vous essayez de surcharger votre service et de le faire fonctionner 24h/24, vous découvrirez rapidement les motivations qui poussent les gros sites à obtenir du code C bien cuit et durci comme Nginx = en faisant face à leur site et en traitant toutes les demandes de contenu statique (... jusqu'à ce que vous ayez configuré un CDN , comme Amazon CloudFront )). Pour un point de vue quelque peu humoristique et sans reproche, voir this guy .

Node.js trouve également de plus en plus d’utilisations non liées aux services. Même si vous utilisez autre chose pour servir du contenu Web, vous pouvez toujours utiliser Node.js comme outil de construction, en utilisant npm modules pour organiser votre code, Browserify pour l'assembler. en un seul actif, et glify-js pour le réduire en vue du déploiement. Pour traiter avec le Web, JavaScript est un parfait correspondance d'impédance et le rend souvent la voie d'attaque la plus simple. Par exemple, si vous souhaitez parcourir des tas de charges utiles de réponses JSON , vous devez utiliser mon module nderscore-CLI , la ceinture d'utilitaires de données structurées.

Avantages/inconvénients:

  • Pro: Pour un serveur, écrire du code JavaScript sur le backend a été une "drogue de passerelle" pour l'apprentissage des modèles d'interface utilisateur modernes. Je ne crains plus l'écriture de code client.
  • Pro: tend à encourager la vérification correcte des erreurs (err est renvoyé par pratiquement tous les rappels, harcelant le programmeur pour le gérer; de plus, async.js et d'autres bibliothèques gèrent le paradigme "échec si l'une de ces sous-tâches échoue" beaucoup mieux que le code synchrone typique )
  • Pro: certaines tâches intéressantes et normalement difficiles deviennent triviales - comme obtenir l'état des tâches en vol, la communication entre les travailleurs ou le partage de l'état du cache
  • Pro: énorme communauté et des tonnes d'excellentes 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 est étrange d'utiliser JSON.parse ou une autre méthode de construction ne nécessitant pas l'ajout d'un module npm. Cela signifie qu'il existe cinq versions de tout. Même les modules inclus dans le "noyau" de 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 à un processus par demande ( LAMP ):

  • Pro: extensible à des milliers de connexions actives. Très rapide et très efficace. Pour un parc Web, cela pourrait signifier une réduction de 10 fois le nombre de boîtes requises par rapport à PHP ou à Ruby.
  • Pro: L'écriture de modèles parallèles est facile. Imaginez que vous deviez récupérer trois (ou N) blobs de Memcached . Faites ceci dans PHP ... vous venez d'écrire le code qui va chercher le premier blob, puis le deuxième, puis le troisième? Wow, c'est lent. Il existe un module spécial PECL pour résoudre ce problème spécifique à Memcached, mais que faire 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, comme le paradigme est asynchrone, il est très naturel de pouvoir effectuer plusieurs requêtes en parallèle.
  • Contre: 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 compréhension solide de ce que signifie une exécution simultanée. Néanmoins, c’est beaucoup moins difficile que d’écrire tout type de code multithread avec verrouillage.
  • Inconvénients: si une requête nécessitant beaucoup de calcul s'exécute pendant 100 ms, par exemple, le traitement d'autres requêtes gérées dans le même processus Node.js sera bloqué ... AKA, coopérative-multitasking . Cela peut être atténué avec le modèle Web Workers (création d'un sous-processus pour traiter la tâche coûteuse). Alternativement, vous pouvez utiliser un grand nombre de travailleurs Node.js et laisser chacun traiter une seule demande simultanément (ce qui est quand même assez efficace car il n’ya pas de processus de recyclage).
  • Con: Exécuter un système de production est BEAUCOUP plus compliqué qu'un modèle CGI comme Apache + PHP, Perl , Ruby , etc. Exceptions non gérées annulera tout le processus, ce qui nécessitera une logique pour redémarrer les travailleurs en échec (voir cluster). Les modules avec un code natif buggy peuvent bloquer le processus. Chaque fois qu'un employé décède, toutes les demandes qu'il traitait sont abandonnées. Une API buggy peut donc facilement dégrader le service des autres API co-hébergées.

Versus en écrivant un "vrai" service en Java/C #/C (C? Vraiment?)

  • Pro: Faire asynchrone dans Node.js est plus facile que de faire de la sécurité des threads n'importe où ailleurs et procure sans doute un plus grand avantage. Node.js est de loin le paradigme asynchrone le moins pénible dans lequel j'ai jamais travaillé. Avec de bonnes bibliothèques, il est légèrement plus difficile que d'écrire du code synchrone.
  • Pro: Pas de bugs multithreading/lock. Certes, vous investissez dès le départ dans l'écriture de code plus détaillé qui exprime un flux de travail asynchrone approprié sans opération de blocage. Et vous devez écrire des tests et faire en sorte que tout fonctionne (il s’agit d’un langage de script et les noms de variables de doigté volumineux n’ont été détectés qu’au moment des tests unitaires). MAIS, une fois que cela fonctionne, la surface pour heisenbugs - d’étranges problèmes qui ne se manifestent qu’une fois sur un million - cette surface est tout simplement beaucoup plus basse. Les taxes qui écrivent le code Node.js sont fortement impliqué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 les fonctionnalités. Il est difficile de le prouver avec des mots, mais JSON , typage dynamique, notation lambda, héritage des prototypes, 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 coder les services en Java?

Pour une autre perspective sur JavaScript et Node.js, consultez De Java à Node.js, un billet de blog sur les impressions et les expériences d'un développeur Java en matière d'apprentissage de Node. .js.

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

Helper/JavaScript Sugar:

  • nderscore.js - utilisez ceci. Simplement fais-le. Cela rend votre code agréable et lisible avec des choses comme _.isString () et _.isArray (). Je ne sais pas vraiment comment vous pourriez écrire un code sécurisé autrement. En outre, pour améliorer la commande en ligne de commande, consultez mon propre nderscore-CLI .

Modules de modèle asynchrone:

  • Step - une manière très élégante d’exprimer des combinaisons d’actions en série et en parallèle. Ma recommandation personnelle. Voir my post ​​sur le code de l'étape.
  • Futures - beaucoup plus flexible (est-ce vraiment une bonne chose?) Pour exprimer les commandes en fonction des besoins. Peut exprimer des choses comme "commencer a, b, c en parallèle. Quand A et B finissent, démarrez AB. Quand A et C finissent, démarrez 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 l'article de Raynos sur l'utilisation des contrats à terme (c'est le message qui m'a fait "obtenir" les contrats à terme).
  • Async - bibliothèque plus traditionnelle avec une méthode pour chaque motif. J'ai commencé avec cela avant ma conversion religieuse en step et la réalisation ultérieure que tous les modèles en async pouvaient être exprimés dans Step avec un seul paradigme plus lisible.
  • TameJS - Écrit par OKCupid, c'est un précompilateur qui ajoute une nouvelle primitive de langue "wait" pour l'écriture élégante de 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 vous pouvez vous faire votre propre idée.

Ou pour tout savoir sur les bibliothèques asynchrones, voir this panel-interview avec les auteurs.

Cadre Web:

  • Express Grand cadre Ruby on Rails-esk pour l'organisation de sites Web. Il utilise JADE en tant que moteur de modélisation XML/HTML, ce qui rend la construction HTML beaucoup moins pénible, voire même élégante.
  • jQuery Sans être techniquement un module de nœud, jQuery est en train de devenir rapidement un standard de facto pour l’interface utilisateur côté client. jQuery fournit des sélecteurs de type CSS permettant de "rechercher" des ensembles d'éléments DOM sur lesquels des opérations peuvent ensuite être effectuées (gestionnaires d'ensembles, propriétés, styles, etc.). Dans le même ordre d'idées, le cadre CSS Bootstrap de Twitter, Backbone.js pour un motif MVC , et Browserify.js pour assembler tous vos fichiers JavaScript dans un seul fichier. Ces modules deviennent tous 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 rajoute un tas des vérifications de base que vous obtenez avec un langage compilé comme Java. Parenthèses mal assorties, variables non déclarées, types de plusieurs formes et tailles. Vous pouvez également activer différentes formes de ce que j'appelle le "mode anal", où vous pouvez vérifier le style des espaces et autres, ce qui est OK si c'est votre tasse de thé - mais la véritable valeur provient de la possibilité d'obtenir un retour instantané sur le numéro de ligne exact. vous avez oublié une fermeture ")" ... sans avoir à exécuter votre code et cliquez sur la ligne incriminée. "JSHint" est une variante plus configurable de Douglas Crockford 's JSLint .
  • Moka concurrent aux voeux 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 en moka.
  • Voeux Les voeux sont vraiment très élégants. Et il affiche un joli rapport (--spec) vous indiquant les cas de test réussis/ayant échoué. Passez 30 minutes à l’apprentissage et vous pouvez créer des tests de base pour vos modules avec un minimum d’effort.
  • Zombie - Test sans tête pour HTML et JavaScript en utilisant JSDom comme "navigateur" virtuel. Des choses très puissantes. Combinez-le avec Replay pour obtenir des tests déterministes ultra-rapides du code dans le navigateur.
  • Un commentaire sur la façon de "penser aux" tests:
    • Le test n'est pas facultatif. Avec un langage dynamique comme JavaScript, il y a very peu de contrôles statiques. Par exemple, transmettre deux paramètres à une méthode qui s'attend à ce que 4 ne soit pas interrompu tant que le code n'est pas exécuté. Barre assez basse pour la création de bugs en JavaScript. Les tests de base sont essentiels pour combler le vide 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 lancer attrape 80% des bogues et fera beaucoup pour améliorer la confiance de votre code en vous permettant de revenir en arrière et d'ajouter les cas de validation nuancés que vous avez ignorés.
    • Commencez petit et brisez la barrière d'inertie. Nous sommes tous paresseux et pressés par le temps, et il est facile de voir les tests comme un "travail supplémentaire". Alors commencez petit. Rédigez le scénario de test 0 - chargez votre module et signalez le succès. Si vous vous forcez à faire autant, la barrière inertielle aux tests est brisée. Cela fait <30 minutes pour le faire votre première fois, y compris la lecture de la documentation. Maintenant, écrivez le scénario de test 1 - appelez l’une de vos méthodes et vérifiez que rien ne se casse, c’est-à-dire que vous ne recevez pas d’erreur en retour. Le cas de test 1 devrait vous prendre moins d'une minute. Une fois l'inertie éliminée, il devient facile d'étendre progressivement la couverture de votre test.
    • Maintenant, faites évoluer vos tests avec votre code. Ne soyez pas intimidé par ce à quoi ressemblerait le "bon" test de bout en bout avec des serveurs fictifs et tout le reste. Le code commence simplement et évolue pour traiter les 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 bogues, ajoutez des vérifications et/ou de nouveaux cas pour couvrir le code défectueux. Lorsque vous déboguez et perdez confiance en un élément de code, revenez en arrière et ajoutez des tests pour prouver qu'il fonctionne comme vous le pensez. Capturez des chaînes de données d'exemple (provenant d'autres services que vous appelez, de sites Web que vous grattez, etc.) et transmettez-les à votre code d'analyse. Quelques cas ici, une validation améliorée là-bas, et vous obtiendrez un code hautement fiable.

Consultez également la liste officielle des modules recommandés par Node.js. Cependant, GitHub'sWiki Modules de nœuds est beaucoup plus complet et constitue une bonne ressource.

Pour comprendre Node, il est utile d’examiner quelques-uns des principaux choix de conception:

Node.js est basé sur un événement et ASYNCHRONE/ NON BLOQUANT . Les événements, comme une connexion HTTP entrante, déclenchent une fonction JavaScript qui effectue un peu de travail et lance d'autres tâches asynchrones telles que la connexion à une base de données ou l'extraction de contenu depuis un autre serveur. Une fois ces tâches lancées, la fonction événement se termine et Node.js se rendort. Dès que quelque chose d'autre se produit, telle que la connexion à la base de données en cours d'établissement ou le serveur externe répondant au contenu, les fonctions de rappel sont déclenchées et plus de code JavaScript s'exécute, ce qui peut déclencher encore plus de tâches asynchrones (comme une requête de base de données). De cette manière, Node.js entrelacera volontiers des activités pour plusieurs flux de travail parallèles, exécutant toutes les activités débloquées à tout moment. C'est pourquoi Node.js fait un travail remarquable 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, un nouvelle connexion est juste une très petite allocation de tas. Le lancement d'un nouveau processus nécessite beaucoup plus de mémoire, un mégaoctet sur certaines plates-formes. Mais le coût réel est le surcoût associé au changement de contexte. Lorsque vous avez 10 ^ 6 threads de noyau, le noyau doit faire beaucoup de travail pour déterminer qui doit être exécuté ensuite. Un tas de travail a été consacré à la construction d'un ordonnanceur O(1) pour Linux, mais au final, il est beaucoup plus efficace de disposer d'un processus unique piloté par événement que de 10 ^ 6 processus en concurrence pour le processeur. temps. En outre, 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 la SSHD (ce qui signifie que vous ne pouvez même pas vous connecter à la boîte pour déterminer à quel point il est foutu).

Node.js est SIMPLE FILETÉ et LOCK FREE . Node.js, en tant que choix de conception très délibéré, ne comporte qu'un seul thread par processus. Pour cette raison, il est fondamentalement impossible pour plusieurs threads d'accéder simultanément aux données. Ainsi, aucun verrou n'est nécessaire. Les fils sont durs. Vraiment très difficile. Si vous ne le croyez pas, vous n'avez pas fait assez de programmation par thread. Bien verrouiller est difficile et donne lieu à des bugs difficiles à détecter. L'élimination des verrous et du multi-threading fait disparaître l'une des classes de bugs les plus odieuses. Cela pourrait être le plus gros avantage du noeud.

Mais comment puis-je tirer parti de mes 16 boites?

Deux manières:

  1. Node.js peut déclencher des processus enfants ou envoyer des messages à des processus de travail supplémentaires pour les tâches de calcul lourdes telles que le codage d'image. Dans cette conception, vous auriez un thread qui gérera le flux d’événements et N processus qui effectueront des tâches de calcul lourdes et mordilleront les 15 autres processeurs.
  2. Pour adapter le débit d’un service Web, vous devez exécuter plusieurs serveurs Node.js sur un boîtier, un par cœur, en utilisant cluster (Node.js v0.6.x, le module officiel "cluster" lié remplace ici la version de learnboost qui a une API différente). Ces serveurs locaux Node.js peuvent alors entrer en concurrence 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 à l'un de ces processus partagés. En théorie, cela sonne mal, mais dans la pratique, cela fonctionne assez bien et vous permet d’éviter les maux de tête liés à l’écriture de code thread-safe. De plus, cela signifie que Node.js obtient une excellente affinité pour le cache du processeur, utilisant plus efficacement la bande passante mémoire.

Node.js vous permet de faire des choses vraiment puissantes sans vous laisser transpirer. Supposons que vous ayez un nœud Programme .js qui effectue une variété de tâches, écoute sur un port TCP pour les commandes, code certaines images, peu importe. Avec cinq lignes de code, vous pouvez ajouter un portail de gestion Web basé sur HTTP qui indique le statut 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");

Maintenant, vous pouvez frapper 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, "lancer un portail de gestion" n'est pas vraiment simple.

Mais JavaScript n'est-il pas lent/mauvais/diabolique/diabolique? JavaScript a quelques bizarreries bizarres, 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 considèrent comme un livre et des talents de classe mondiale se font concurrence pour produire les moteurs JavaScript les plus avancés. En raison du rôle de JavaScript dans le navigateur, un énorme effort d'ingénierie est en cours pour rendre JavaScript extrêmement rapide. V8 est le dernier et meilleur moteur javascript, au moins pour ce mois-ci. Cela efface les autres langages de script en termes d'efficacité ET de stabilité (en vous regardant, Ruby). Et cela ne pourra que s'améliorer avec d'énormes équipes travaillant sur le problème chez Microsoft, Google et Mozilla, rivalisant pour créer le meilleur moteur JavaScript (ce n'est plus un "interprète" JavaScript comme le font tous les moteurs modernes JIT compiler sous le capot avec interprétation uniquement comme solution de secours pour le code execute-once). Oui, nous souhaitons tous pouvoir résoudre quelques-uns des choix de langage JavaScript les plus étranges, mais ce n'est vraiment pas si grave. Et le langage est tellement souple 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. De toute façon, pour créer des applications Web, vous devez de toute façon connaître JavaScript, de sorte que le codage avec celui-ci sur le serveur crée une sorte de synergie de compétences. Cela ne m'a pas effrayé d'écrire du code client.

En outre, si vous détestez VRAIMENT JavaScript, vous pouvez utiliser un sucre syntaxique tel que CoffeeScript . Ou tout ce qui crée du code JavaScript, comme Google Web Toolkit ​​(GWT).

En parlant de JavaScript, qu'est-ce qu'une "fermeture"? - Une façon plutôt élégante de dire que vous conserver les variables à portée lexicale dans 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 simplement utiliser "myData" sans rien faire d'inconvénient, comme de le cacher dans un objet? Et contrairement à Java, la variable "myData" ne doit pas nécessairement être en lecture seule. Cette fonctionnalité de langage puissant rend la programmation asynchrone beaucoup moins bavarde et moins douloureuse.

L'écriture de code asynchrone sera toujours plus complexe que d'écrire un simple script à un seul thread, mais avec Node.js, ce n'est pas si difficile et vous obtenez beaucoup d'avantages en plus de l'efficacité et de l'évolutivité de milliers de connexions simultanées. ..

619
Dave Dopson

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 la V8 qui effectue des E/S événementées. Ce concept est un peu plus compliqué à expliquer, et je suis sûr que quelqu'un répondra avec une meilleure explication que moi ... L’essentiel est que plutôt que de faire une entrée ou une sortie et d’attendre que cela se produise, vous venez N'attendez pas qu'il se termine. Ainsi, par exemple, demandez la dernière heure de modification d'un fichier:

// Pseudo code
stat( 'somefile' )

Cela peut prendre quelques millisecondes ou quelques secondes. Avec evented I/O , vous lancez simplement la demande et, au lieu d'attendre, vous attachez un rappel qui est exécuté à la fin de la demande:

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

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

Pour plus d'informations, vous devriez consulter l'article Node.js est vraiment excitant qui était mon introduction à la bibliothèque/plateforme ... Je l'ai trouvé assez bon.

85
rfunduk

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

Le JavaScript est exécuté par V8 , un moteur JavaScript développé par Google et utilisé dans le navigateur Chrome . 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 parallèles.

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

Voici quelques bons articles sur le sujet.

35
Asif Mushtaq

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

Cela signifie que vous pouvez définir des variables, puis lancer une fonction non bloquante I/O 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, c'est la fermeture.

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

13
Fire Crow

Deux bons exemples concernent la gestion des modèles et l’utilisation d’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:

Choisissez n'importe quelle langue et essayez de vous rappeler comment gérer vos modèles de fichiers HTML et ce que vous avez dû faire pour mettre à jour un seul nom de classe CSS dans votre DOM structure (par exemple, un utilisateur a cliqué sur un élément de menu et vous souhaitez le marquer comme "sélectionné" et mettre à jour le contenu de la page).

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

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

8
Renato

Il existe une très bonne analogie avec la restauration rapide qui explique le mieux le modèle événementiel de Node.js, voir l'article complet Node.js, cabinets de médecin et restaurants de restauration rapide - Comprendre la programmation événementielle

Voici un résumé:

Si le fast-food suivait un modèle traditionnel à base de fil, vous commanderiez votre nourriture et attendriez en ligne jusqu'à ce que vous la receviez. La personne derrière vous ne pourrait pas commander avant que votre commande soit terminée. Dans un modèle axé sur les événements, vous commandez votre nourriture et attendez ensuite. Tout le monde est alors libre de commander.

Node.js est basé sur les événements, mais la plupart des serveurs Web sont basés sur des threads.

  • Vous utilisez votre navigateur Web pour demander "/about.html" sur un serveur Web Node.js.

  • Le serveur Node.js accepte votre demande et appelle une fonction pour extraire ce fichier du disque.

  • Pendant que le serveur Node.js attend la récupération du fichier, il traite la demande Web suivante.

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

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

7
adeleinr

N'oubliez pas non plus que le V8 de Google est TRÈS rapide. En fait, il convertit 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
Quinton Pike

Eh bien, je comprends cela

  • L'objectif de Node est de fournir un moyen simple de créer des programmes réseau évolutifs.
  • Node est similaire dans sa conception et influencé par des systèmes tels que Ruby's Event Machine ou Python's Twisted.
  • Evented I/O pour V8 en javascript.

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

6
nes1983

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

Correct. Il utilise des rappels, de sorte que toute demande d'accès au système de fichiers entraîne l'envoi d'une demande au système de fichiers, puis Node.js commence à traiter sa demande suivante. Cela ne concernerait que la demande d'E/S une fois que le système de fichiers aura renvoyé une réponse; à ce moment, le code de rappel sera exécuté. Cependant, il est possible de faire des demandes d'E/S synchrones (c'est-à-dire des demandes de blocage). Il appartient au développeur de choisir entre asynchrone (rappels) et synchrone (en attente).

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 de rechercher un cadre tel que http://www.easynodejs.com/ - fourni avec une documentation complète en ligne et un exemple d'application.

3
Charles