Comment décider quand utiliser Node.js?

Question

Je suis nouveau dans ce genre de choses, mais dernièrement, j’ai beaucoup entendu parler de la qualité 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 grand moteur JavaScript V8
est très bon quand vous devez 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 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 immédiatement sur EC2 d'Amazon , j'essaie de comprendre quel type de problèmes nécessite Node.js par opposition à aucun des puissants rois il comme PHP , Python et Ruby . Je comprends que cela dépend vraiment de l’expertise d’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?

Benson · Accepted Answer

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 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 à noter que Ruby et Python ont tous deux des outils pour faire ce genre de choses ( eventmachine et twisted , respectivement), mais ce Node.js le fait exceptionnellement bien, et à partir de la terre. 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 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 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 .

fisherwebdev · Answer

Je pense que Node.js est le mieux adapté aux applications en temps réel: jeux en ligne, outils de collaboration, salles de chat 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 n'importe quelle situation où le code pourrait bloquer en raison de threads peut être mieux traitée avec Node.js. 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 très 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.

joeytwiddle · Answer

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 du formulaire ou le rendu vues à chaque extrémité.)
Le système single-threaded piloté par les événements est rapide , même lorsque vous gérez de nombreuses demandes à la fois , et aussi simple, comparé aux frameworks traditionnels multi-thread Java ou ROR.
Le pool sans cesse croissant de packages accessible via NPM , y compris les bibliothèques/modules côté client et serveur, ainsi que la commande outils en ligne 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! C'est bien d'avoir tout 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 exécuter les outils liés à Javascript et d’autres outils liés au Web , y compris les coureurs de tâches, les minifiers, les beautifiers, les linters, les préprocesseurs, les bundlers et les processeurs d'analyse.
Cela semble tout à fait adapté au prototypage, au développement agile et à l'itération rapide du produit .

Raisons pas d'utiliser NodeJS:

Il utilise Javascript, qui n'a pas de vérification de type à la compilation. Pour les grands systèmes complexes liés à la sécurité , ou les projets incluant la collaboration entre différentes organisations, langage qui encourage les interfaces contractuelles et fournit une vérification de type statique peut vous faire économiser du temps de débogage (et des explosions ) à long terme. (Bien que la machine virtuelle Java soit bloquée avec null, veuillez utiliser Haskell pour vos réacteurs nucléaires.)
Ajoutés à cela, beaucoup de paquets dans NPM sont un peu bruts , 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 à présent très stables . Npmjs.org n'a pas de mécanisme pour évaluer les paquets , ce qui a entraîné une prolifération de paquets qui font 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 apparaître un projet NodeJS 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 Node. Comparez cela avec un développeur de Rails rejoignant un projet existant: il devrait être en mesure de se familiariser assez rapidement avec l'application, car tous Rails les applications sont encouragées à utiliser une structure similaire .
Traiter des fichiers peut être un peu pénible. Les choses triviales dans d'autres langues, telles que la lecture d'une ligne à partir d'un fichier texte, sont assez bizarre à faire avec Node.js qu'il existe une question StackOverflow à ce sujet avec plus de 80 votes positifs en amont. Il 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 ... :)

stewe · Answer

Pour faire court:

Node.js est bien adapté aux applications qui ont beaucoup de connexions simultanées et chaque requête n'a besoin que de très peu de cycles de processeur, car 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 Node.js est Le blog technique de Mixu: Comprendre la boucle d'événement node.js .

Joonas · Answer

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 compteur 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 à partir d'une base de données Redis , augmentez le compteur lorsque l'article est vendu et transmettez la valeur du compteur aux utilisateurs via le API .

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

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.
Le compteur est vraiment facile à faire pour être en temps réel.
Node.js était facile à configurer.
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.

Tony O&#39;Hagan · Answer

Les principales raisons de démarrer votre prochain projet avec Node ...

Tous les mecs les plus cools sont dedans ... donc ça doit être amusant.
Vous pouvez passer du temps à la glacière et vivre de nombreuses aventures Node].
Vous ne payez que très peu pour les coûts d'hébergement dans le cloud.
Ça y est fait avec Rails
Vous détestez les déploiements IIS
Votre ancien poste informatique devient plutôt ennuyeux et vous souhaiteriez être dans une toute nouvelle Start Up.

Quoi attendre ...

Qui l'utilise?

Paypal, Netflix, Wal-Mart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
Voici pourquoi ils sont passés au noeud .

ajay · Answer

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

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.
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

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

Prise en compte de l'évolutivité avec Node.JS

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 polyvertité et une meilleure évolutivité.

BoxerBucks · Answer

Une autre grande chose que je pense personne n’a mentionné Node.js, c’est l’étonnante communauté, le système de gestion des paquets (npm) et la quantité de modules existants que vous pouvez inclure en les incluant simplement dans votre fichier package.json.

shash7 · Answer

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. En fait, 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!

Éditer

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 discussion en ligne 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 simultanéité et la rapidité.

Sockets uniquement les serveurs comme les applications de discussion, les applications 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 un REST seulement api.

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.

Vinayak Bevinakatti · Answer

Il peut être utilisé où

Applications fortement liées aux événements et fortement liées aux E/S
Applications gérant un grand nombre de connexions à d'autres systèmes
Applications en temps réel (Node.js a été conçu pour le temps réel et pour être facile à utiliser.)
Des applications qui jonglent avec une foule d'informations en continu et en provenance d'autres sources
Trafic élevé, applications évolutives
Des applications mobiles qui doivent communiquer avec la plate-forme API et la base de données, sans avoir à faire beaucoup d'analyse de données
Construire des applications en réseau
Applications qui ont besoin de parler très souvent au serveur

Sur le marché mobile, les sociétés aux heures de grande écoute se sont appuyées sur Node.js pour leurs solutions mobiles. Découvrez pourquoi?

LinkedIn est un utilisateur connu. Toute leur pile mobile est construite sur Node.js. Ils sont passés de 15 serveurs avec 15 instances sur chaque machine physique à seulement 4 instances, capables de gérer le double du trafic!

eBay a lancé ql.io, un langage de requête Web pour les API HTTP, qui utilise Node.js comme pile d'exécution. Ils ont pu configurer une station de travail Ubuntu de qualité développeur pour gérer plus de 120 000 connexions actives par processus node.js, chaque connexion consommant environ 2 ko de mémoire!

Walmart a repensé son application mobile pour utiliser Node.js et a transmis son traitement JavaScript au serveur.

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

Anshul · Answer

Noeud idéal pour la gestion des requêtes 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 de l’arrière nous fournissent des API écrites en Java, python (on s’en fiche) et nous écrivons simplement un appel AJAX, obtenons 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 nos 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 le résoudre. 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 traditionnel d’API de repos, qui repose soit sur une opération de blocage, soit sur un thread. 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. Waiting Way: Notre serveur commence à servir la requête r1 et attend la réponse à la requête. une fois que r1 est terminé, 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. Mode de thread: Notre serveur créera deux threads pour les deux requêtes r1 et r2 et servira leur objectif après avoir interrogé la base de données afin de la refroidir rapidement. vous pouvez voir que nous avons démarré deux threads et que le problème augmente lorsque les deux requêtes interrogent les mêmes données, vous devez alors faire face à un type de blocage. 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 avance, il n'attend pas la réponse à une requête pour une requête particulière.Alors lorsque r1 requête vient ensuite la boucle d'événement du nœud (oui, il existe une boucle d'événement dans ce nœud.) enregistre un événement avec sa fonction de rappel, avance pour servir la demande 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.

Sean Zhao · Answer

Mon une 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 peut y avoir IDE basé sur le cloud pour d'autres langages ou plateformes (Cloud 9 IDE ajoute également des supports pour d'autres langages), mais utiliser Cloud 9 pour le développement de Node.js est vraiment une excellente expérience pour moi.

I_Debug_Everything · Answer

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), n’affectant donc pas le processus principal. exécuter 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 tels que Express.js et le nouveau Koajs (qui a supprimé l'en-tête de rappel) ont rendu le travail sur les nœuds encore plus facile.

Christos Hayward · Answer

Enfiler de l'amiante longjohns ...

Hier, mon titre avec Packt Publications, Programmation réactive avec JavaScript . Ce n'est pas vraiment un titre centré sur Node.js; Les premiers chapitres sont destinés à couvrir la théorie, et plus tard, les chapitres lourds de code couvrent la pratique. Parce que je ne pensais pas vraiment qu'il serait approprié de ne pas donner aux lecteurs un serveur Web, Node.js semblait de loin le choix évident. L'affaire était close avant même d'être ouverte.

J'aurais pu donner une vue très optimiste de mon expérience avec Node.js. Au lieu de cela, j'ai été honnête à propos des points positifs et des points négatifs que j'ai rencontrés.

Permettez-moi d'inclure quelques citations pertinentes ici:

Attention: Node.js et son écosystème sont très chauds - assez chauds pour vous brûler gravement!

Lorsque j'étais assistant enseignant en mathématiques, l'une des suggestions non évidentes qui m'avait été dite était de ne pas dire à un élève que quelque chose était "facile". La raison en était quelque peu évidente rétrospectivement: si vous dites ne voit pas de solution qui pourrait finir par se sentir (encore plus) stupide, car non seulement ils ne savent pas comment résoudre le problème, mais le problème qu’ils sont trop stupides pour comprendre est facile!

Il ya des pièges qui ne font pas que gêner les gens venant de Python/Django, qui recharge immédiatement la source si vous changez quelque chose. Avec Node.js, le comportement par défaut est que si vous effectuez une modification, l'ancienne version reste active jusqu'à la fin de la période ou jusqu'à ce que vous arrêtiez et redémarriez le serveur manuellement. Ce comportement inapproprié ne gêne pas uniquement les Pythonistes; cela irrite également les utilisateurs natifs de Node.js qui fournissent diverses solutions de contournement. La question StackOverflow “Rechargement automatique des fichiers dans Node.js” a, au moment de la rédaction de cet article, plus de 200 votes positifs et 19 réponses; une modification dirige l'utilisateur vers un script de nounou, nœud-superviseur, dont la page d'accueil est située à l'emplacement http://tinyurl.com/reactjs-node-supervisor . Ce problème offre aux nouveaux utilisateurs une grande opportunité de se sentir stupide car ils pensaient avoir résolu le problème, mais l'ancien comportement de buggy est totalement inchangé. Et il est facile d’oublier de faire rebondir le serveur; Je l'ai fait plusieurs fois. Et le message que je voudrais transmettre est le suivant: "Non, vous n’êtes pas stupide, car ce comportement de Node.js vous a mordu dans le dos; c'est juste que les concepteurs de Node.js n'ont vu aucune raison de fournir un comportement approprié ici. Essayez de vous en sortir, peut-être en prenant un peu d’aide de la part du superviseur de nœud ou d’une autre solution, mais veuillez ne pas vous écarter du sentiment que vous êtes stupide. Ce n’est pas vous qui avez le problème; le problème est dans le comportement par défaut de Node.js. ”

Cette section, après quelques débats, a été laissée là, précisément parce que je ne voulais pas donner l'impression "c'est facile". Je me suis coupé les mains à plusieurs reprises tout en faisant fonctionner les choses, et je ne voulais pas atténuer les difficultés et vous préparer à croire que faire fonctionner Node.js et son écosystème est une tâche simple et que si ce n'est pas simple pour vous aussi, vous ne savez pas ce que vous faites. Si vous n’éprouvez pas de difficultés désagréables avec Node.js, c’est merveilleux. Si vous le faites, j'espère que vous ne vous en tirerez pas en pensant: "Je suis stupide, il doit y avoir quelque chose qui ne va pas avec moi." Vous n'êtes pas stupide si vous rencontrez de mauvaises surprises avec Node.js. Ce n'est pas toi! C’est Node.js et son écosystème!

L'annexe, que je ne voulais pas vraiment après la montée du crescendo dans les derniers chapitres et la conclusion, parle de ce que j'ai pu trouver dans l'écosystème et fournit une solution de contournement pour un littéralisme débile:

Une autre base de données qui semblait parfaitement adaptée et qui peut encore être échangée est une implémentation côté serveur du magasin de clés-valeurs HTML5. Cette approche présente l’avantage capital d’une API que la plupart des bons développeurs frontaux comprennent suffisamment bien. En outre, c’est aussi une API que la plupart des développeurs front-end pas très bons comprennent assez bien. Mais avec le package node-localstorage, bien que l'accès avec la syntaxe de dictionnaire ne soit pas offert (vous souhaitez utiliser localStorage.setItem (clé, valeur) ou localStorage.getItem (clé), pas localStorage [clé]), la sémantique complète de localStorage est implémentée. , y compris un quota par défaut de 5 Mo - POURQUOI? Les développeurs JavaScript côté serveur doivent-ils être protégés contre eux-mêmes?

Pour les capacités de base de données côté client, un quota de 5 Mo par site Web constitue une marge de manœuvre généreuse et utile pour permettre aux développeurs de l'utiliser. Vous pouvez définir un quota beaucoup plus bas tout en offrant aux développeurs une amélioration incommensurable par rapport à la gestion des cookies. Une limite de 5 Mo ne se prête pas très rapidement au traitement Big Data côté client, mais il existe une allocation vraiment très généreuse que les développeurs ingénieux peuvent utiliser pour faire beaucoup. Mais, d’autre part, 5 Mo ne représentent pas une part particulièrement importante de la plupart des disques achetés récemment, ce qui signifie que si vous et un site Web n’êtes pas d’accord sur une utilisation raisonnable de l’espace disque, ou si certains sites sont tout simplement gigantesques, cela ne coûte pas vraiment cher. et vous ne risquez pas d’avoir un disque dur saturé à moins que votre disque dur ne soit déjà trop plein. Nous serions peut-être mieux si l’équilibre était un peu moins ou un peu plus, mais dans l’ensemble, c’est une solution décente pour remédier à la tension intrinsèque dans un contexte côté client.

Cependant, il est à noter que lorsque vous écrivez du code pour votre serveur, vous n’avez pas besoin de protection supplémentaire pour créer une base de données d’une taille supérieure à 5 Mo. La plupart des développeurs n'auront ni besoin ni envie d'outils jouant le rôle de nourrice et les empêchant de stocker plus de 5 Mo de données côté serveur. Et le quota de 5 Mo qui constitue un bon équilibrage côté client est plutôt idiot sur un serveur Node.js. (Et, pour une base de données pour plusieurs utilisateurs telle que celle décrite dans cette annexe, il peut être souligné, légèrement douloureusement, qu'il ne s'agit pas de 5 Mo par compte d'utilisateur, sauf si vous créez une base de données distincte sur le disque pour chaque compte d'utilisateur. Cela pourrait devenir pénible si vous devenez viral!) La documentation indique que le quota est personnalisable, mais un courrier électronique a été envoyé il y a une semaine au développeur pour lui demander comment changer le le quota est sans réponse, de même que la question de StackOverflow lui demandant la même chose. La seule réponse que j'ai pu trouver est dans le source Github CoffeeScript, où il est répertorié comme un second argument entier optionnel à un constructeur. C’est donc assez simple et vous pouvez spécifier un quota égal à la taille d’un disque ou d’une partition. Mais en plus du portage d’une fonctionnalité qui n’a pas de sens, l’auteur de l’outil n’a pas complètement respecté la convention très standard selon laquelle 0 signifie "illimité" pour une variable ou une fonction où un entier doit spécifier une limite maximale pour une utilisation des ressources. La meilleure chose à faire avec ce problème est probablement de spécifier que le quota est Infinity:

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

Échanger deux commentaires dans l'ordre:

Les gens se tiraient une balle dans le pied en utilisant constamment JavaScript dans son ensemble, et une partie de ce langage devenait un langage respectable, disait Douglas Crockford: "JavaScript en tant que langage a de très bonnes parties et de très mauvaises parties. Voici les bonnes parties. Oubliez simplement qu’il n’ya rien d’autre. "Peut-être que l’écosystème Node.js connaîtra une croissance propre " Douglas Crockford ", qui dira" Le nœud L’écosystème .js est un Wild West codant, mais il existe de véritables joyaux. Voici une feuille de route. Voici les domaines à éviter à tout prix. Voici les zones avec les rémunérations les plus riches que l'on puisse trouver dans TOUT langage ou environnement. "

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

Et étant donné le degré d’enthousiasme et le peu d’heures de travail consacrées à tous les projets, il sera peut-être justifié, dans un an, deux ou trois ans, de tempérer de manière radicale toute remarque faite au sujet d’un écosystème immature au moment de la rédaction de ce document. Dans cinq ans, il peut être logique de dire: "L’écosystème 2015 de Node.js comptait plusieurs champs de mines. L’écosystème 2020 de Node.js comporte de nombreux paradis. ”

matanster · Answer

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, en particulier si vous souhaitez obtenir le maximum d’évolutivité, ou si votre langue principale 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 votre effectif soit orienté javascript.

Au-delà d’un certain seuil, vous ne pouvez pas redimensionner votre code sans de terribles piratages qui forcent 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 calculs dans votre application, faites attention à ne choisir que (noeud) node.js. Peut-être que http://koajs.com/ ou d’autres nouveautés soulagent ces aspects initialement épineux, par rapport à la situation où j’avais utilisé node.js ou écrit ceci à l’origine.