Y a-t-il une bonne raison d'éviter node.js pour les applications Web non en temps réel?

29

J'ai beaucoup parlé de la façon dont Node.js est génial pour les applications Web en temps réel - des choses qui nécessitent des sockets, des communications Comet, AJAX, etc. Je sais que son modèle basé sur les événements, asynchrone et basé sur les threads est également bon pour la concurrence avec une faible surcharge.

J'ai également vu des didacticiels Node.js pour des applications plus simples, «traditionnelles» et non temps réel (par exemple, l'exemple de blog standard, qui semble être le «Hello World» standard pour les personnes qui apprennent le développement d'applications). Et je sais aussi que node-static vous permet de servir des actifs statiques.

Ma question est: y a-t-il une bonne raison d' éviter Node.js pour les applications Web traditionnelles, comme les petites annonces, les forums, l'exemple de blog susmentionné ou le type d'applications CRUD que vous créez pour les applications métier internes? Juste parce qu'il excelle dans tous les trucs funky en temps réel, cela le contre-indique-t-il pour des utilisations plus staid?

La seule chose à laquelle je peux penser, au départ, est le manque de bibliothèques matures (bien que cela change).

(La raison pour laquelle je demande est que j'envisage d'abandonner PHP pour Node.js, principalement pour surmonter le décalage d'impédance de la commutation entre les langues, mais aussi pour que je puisse réutiliser le code de validation et ainsi de suite. Mon surmoi me recommande de choisir le meilleur outil pour le travail ; cependant, je n'ai pas beaucoup de temps pour apprendre quinze langues et toutes leurs bibliothèques utilisateur juste pour avoir un arsenal complet. Il est également rassurant que Node.js pourrait me donner un chemin d'optimisation plus facile que PHP / Apache à l'avenir quand je devrai commencer à penser à un trafic intense.)

[EDIT] Merci pour les réponses jusqu'à présent, les amis; Je veux juste voir si quelqu'un d'autre interviendra avant de choisir une réponse. La réponse de @Raynos confirme un peu ce que je pense, et les liens des commentateurs ont donné matière à réflexion, mais je veux voir si quelqu'un d'autre a des réponses spécifiques aux nœuds, comme 'N'UTILISEZ PAS NODE POUR LE PROBLÈME X '. (Outre les tâches à processeur élevé, je le sais déjà :-)

Paul d'Aoust
la source
1
@ default.kramer: Merci pour le lien, j'ai vraiment apprécié!
Zach
1
Hou la la! Un gars plutôt opiniâtre, hein? Dans l'article de suivi, il semble dire que, pour les applications à E / S élevées et à faible processeur, les systèmes événementiels et filetés sont à peu près à la hauteur, et que le problème réside avec les programmeurs débutants qui ne savent pas quand abandonner les événements et générer un nouveau fil. Mais l'ignorance du programmeur ne signifie pas que l'outil est mauvais, n'est-ce pas? Je suis d'accord que l'utilisation d'un environnement dont le forté est des boucles d'événements pour des tâches gourmandes en CPU est un peu bizarre, mais est-ce mal?
Paul d'Aoust
1
Sa haine de JavaScript semble également être un problème important, qui, je le crains, pourrait être en partie responsable de l'énergie derrière son argument.
Paul d'Aoust
@Paul - Vous devriez probablement le prendre avec un grain de sel. Je ne connais pas grand-chose à Node.js; Je pensais juste que c'était humoristique. (comme la plupart de ses écrits)
default.kramer
@ default.kramer merci pour le rappel; J'ai tendance à considérer les opinions des gens comme un évangile. Sa principale critique valable semble être que vous ne devriez pas utiliser Node.js pour des tâches gourmandes en CPU. Je suis confus quant à sa critique des processus de travail; y a-t-il un gros problème avec la création de travailleurs séparés pour des tâches spécifiques?
Paul d'Aoust

Réponses:

13

existe-t-il une bonne raison d'éviter Node.js pour les applications Web traditionnelles

Oui, si vous avez N ans sur la plate-forme Web X, vous pouvez clairement développer une application sur la plate-forme X plus rapidement.

Si vous voulez faire Y et que la plateforme X a une solution pré-faite Y qui fait X alors faites-le.

Toutes les raisons génériques pour lesquelles vous devriez utiliser une plateforme plutôt qu'une autre.

le type d'applications CRUD que vous créez pour les applications métier internes?

Oui, il existe d'autres plates-formes qui vous permettent d'écrire une application générique plus rapidement, Ruby on rails vient à l'esprit.

Cela dit, cependant. J'ai de l'expérience avec le nœud et je ne peux pas prétendre que je choisirais une autre plate-forme que le nœud à moins qu'il ne fasse pour moi une énorme quantité de fonctionnalités.

Fondamentalement, c'est une simple question de

Existe-t-il un outil qui fait tout cela pour moi? Non, choisissez la plate-forme la plus pratique pour écrire l'outil.

Il n'y a aucune raison solide pour laquelle node.js est une plate-forme gênante (autre que "je déteste le javascript")

Raynos
la source
Vous pensez donc que des principes pragmatiques comme la familiarité, la disponibilité des bibliothèques, etc., sont des arguments solides pour une certaine plate-forme, hein? Ce sont de bonnes pensées, et ce sont certainement des choses que j'envisage. (Je suis surpris que vous plaidiez pour des solutions prêtes à l'emploi; je pensais que vous étiez un gars un peu roll-your-own!)
Paul d'Aoust
@ Pauld'Aoust Je suis un gars un peu roll-your-own. Cependant, je ne fais rien et je n'ai pas de délais.
Raynos
heh, merci pour la mise en garde. Je me souviens de vos commentaires sur le chat node.js à propos de l'utilisation des bibliothèques de modèles d'autres personnes (Backbone.js, etc.) et du fait que je passais trop de temps à apprendre Backbone.js et pas assez de temps à simplement profiter (et apprendre) de JavaScript mécanisme d'héritage prototypique. Bon conseil; Je me sens beaucoup plus détendu maintenant.
Paul d'Aoust
4
-1 vague. 1) Ce n'est pas parce que vous avez N ans d'expérience en X - que vous devez éviter Node.JS. Proposez-vous une ignorance volontaire basée sur l'expérience? Et quelles sont les "raisons génériques"? 2) «d'autres applications qui vous permettent d'écrire une application générique plus rapidement» - est purement subjectif. 3) 'autre * que "* je déteste * JavaScript' - est également subjectif et n'est pas une raison valable pour éviter une technologie florissante. * Orthographe.
Jack Stone
@ClintNash certaines de vos raisons ne sont pas différentes des siennes. «Ressources humaines» vs «N années d'expérience» sont exactement les mêmes. "NodeJS n'est pas aussi mature que les frameworks traditionnels" vs "Oui, il existe d'autres plates-formes qui vous permettent d'écrire une application générique plus rapidement, Ruby on rails vient à l'esprit." sont également les mêmes. Non seulement ils sont les mêmes, mais les vôtres ne sont pas plus mesurables (objectifs) que les siens.
aaaaaa
6

Après avoir travaillé avec node pendant quelques semaines, je dirais que oui, c'est très cool. Mais pas nécessairement quelque chose que vous voudriez utiliser pour remplacer vos applications Web courantes par ... ni, imo, ce n'est pas prévu.

N'oubliez pas que le nœud est son propre serveur. Cela introduit des complexités si vous souhaitez exécuter plus que votre seule application node.js. c'est-à-dire, si vous avez plus d'un site / domaine hébergé sur une machine. Ce n'est pas comme une pile LAMP, où vous pouvez avoir une douzaine d'applications PHP pour une demi-douzaine de domaines différents fonctionnant sur le même serveur (sur le port 80, au moins). Il existe des cadres pour les nœuds qui le rendent probablement possible, mais c'est une complexité supplémentaire dont vous n'avez tout simplement pas besoin si vous vous en tenez aux plates-formes Web traditionnelles. (Vous pouvez, bien sûr, également configurer des proxys en plaçant un serveur Web devant le nœud, mais cela annule l'avantage d'utiliser le nœud).

imo, Node est parfait pour travailler en conjonction avec un serveur Web traditionnel. La façon dont j'ai organisé les choses maintenant est de servir les images statiques html / js / via apache, et de gérer les besoins de données «en temps réel» en interrogeant longuement l'application de nœud.

GrandmasterB
la source
+1 La facilité d'utilisation dans la configuration de plusieurs hôtes vaut vraiment la peine d'être considérée.
Paul d'Aoust
Il est assez simple de placer des applications de nœud derrière un serveur Apache httpd ou nginx et de router les demandes avec la signature URI de cette application vers le ou les ports de nœud.
TomG
+1 - la notion de node.js en tant que proxy côté serveur (`` en conjonction avec un serveur Web traditionnel '') a gagné du terrain plus tôt cette année et mérite d'être étudiée - surtout si vous avez une grande architecture traditionnelle à gérer. Il s'agit d'un modèle de conception qui semble avoir du sens pour l'entreprise. Mais, il convient de noter - ce n'est pas une raison pour ÉVITER Node.js mais une raison de l'utiliser à des fins spécifiques.
Jack Stone
4
-1 - Mettre un proxy (comme nginx) devant le nœud est un cas d'utilisation parfait et est en réalité beaucoup plus sûr et performant dans certains cas que de ne pas en avoir du tout. Il ne vainc aucun avantage du nœud. J'ai tendance à exécuter mes applications de nœud sur des sockets de domaine Unix, puis à faire agir nginx en tant que contrôleur d'accès.
Scott Anderson
3

Une bonne raison d'avoir quelques secondes sur le nœud n'est pas technique - c'est génial et étonnant dans ce qu'il fait.

Ce sont des entreprises et en particulier du capital humain, c'est-à-dire des programmeurs qui le savent, combien ils coûtent et leur disponibilité. Ce n'est pas si difficile à apprendre, mais comme avec toute nouvelle technologie, le nombre de personnes qui la connaissent bien (ou qui veulent) est un sous-ensemble des plus grands bassins de travailleurs.

Michael Durrant
la source
vous pensez donc qu'il n'y a pas grand-chose contre l'utilisation de Node à la place des piles d'applications plus traditionnelles; les problèmes sont davantage liés aux préoccupations du monde réel?
Paul d'Aoust
+1. Les ressources humaines - et la réticence de certains à apprendre JavaScript - est une vérité qui dérange. Cette réponse le dit bien. Mais éviter Node "parce que les gens détestent JavaScript" n'est pas non plus la progression logique. Où serions-nous techniquement si nous évitions toute innovation - que quelqu'un d'autre détestait? Nulle part. Le défi avec le nœud est A) Trouver de nouveaux talents, ou B) Former des talents traditionnels à de nouveaux talents. À ce point - nous voyons des écoles de code JavaScript apparaître partout depuis la clairvoyance de John Resig en fondant la Khan Academy. Bref, c'est la voie des choses. +1. Bien dit.
Jack Stone
3

C'est une très bonne question, qu'il faut se poser, pour trop faire avancer l'état de l'art.

J'étais très curieux de savoir (comme Paul d'Aoust) où existent les limites de Node.JS. Malheureusement, de nombreuses réponses sont PLEINES de biais subjectifs et de justification temporairement pertinente.

Je me suis demandé: POUVONS-NOUS FILTRER LES BIENS SUBJECTIFS ET OBTENIR DES RÉPONSES SOLIDES À CETTE QUESTION PERTINENTE?

Les points restants semblent être:

1. NodeJS n'est pas aussi mature que les frameworks traditionnels. Comme le suggère Paul d'Aoust, ce n'est qu'une raison temporairement pertinente, non pas pour l'évitement complet - mais plutôt pour un examen et une diligence raisonnable. Nous devons faire nos devoirs en tant que professionnels du Web, et c'est notre travail de déterminer la meilleure adaptation de la technologie à l'organisation, à leurs besoins, à leur avenir, à l'équipe (et non à nous). La maturité est un besoin de clarification et un jugement d'appétit pour le risque, mais pas d'évitement.

2. NodeJS en tant que serveur proxy. Une sage suggestion, de discussion préalable, qui mérite examen et considération. C'est l'idée d'utiliser Node en corrélation avec les technologies existantes comme modèle de conception de proxy d'interface frontale. Mais aussi, ce n'est pas une raison pour ÉVITER d'utiliser le nœud, mais plutôt une raison pour éviter de l'utiliser en remplacement complet. Opter plutôt pour une approche corollaire.

3. Nœud de débogage. Dans la conversation avec les développeurs de nœuds principaux de Joyent, il y a beaucoup de complications entourant le débogage et la recherche de la cause première des problèmes résultant du noyau (basée sur l'exécution d'un seul thread et l'incapacité de voir dans les threads précédents). Cela vaut la peine d'être considéré et évalué - mais (encore une fois) probablement pas une aversion pour une utilisation courante uniquement des cas marginaux qui peuvent pousser l'enveloppe. Peut-être que vos besoins spécifiques tomberaient dans cette catégorie et peut-être qu'ils ne le seront pas.

4. Ressources humaines. C'est la meilleure raison pour ÉVITER d'utiliser JS sur cette page, et à mon humble avis, c'est une vérité austère et incommode. Cela soulève la question: votre entreprise dispose-t-elle des bons professionnels talentueux pour mener le projet à travers son cycle de vie complet? Sinon, il ne fait aucun doute que vous devez éviter NodeJS. Ou pensez plutôt à A) trouver le bon talent, ou B) Éduquer le talent existant.

Plaintes: Mon observation des plaintes sur JavaScript est que beaucoup résultent plus d'une erreur utilisateur que de défaillances cohérentes de la langue. Nous avons démystifié de nombreuses réclamations contre "The Hate JavaScript Diatribe" et nous continuerons à démystifier encore plus. Des problèmes tels que - la documentation n'est pas assez bonne, elle n'est pas assez sexy, mais les gens ne l'aiment pas, c'est le cancer, c'est le diable, ou elle est trop "sujette aux fautes de frappe" (-CRichardson), est subjective et plaintes biaisées qui doivent être éliminées pour une prise de décision précise de l'entreprise.

En fin de compte, la bonne réponse peut être - il n'y a pas de bonnes raisons pour ÉVITER NodeJS . C'est peut-être pour cela qu'il connaît une croissance, une adoption et une contribution rapides. Mais pour nous tous, la réponse ici est peut-être de continuer à évaluer, rechercher et mieux comprendre NodeJS - et à rechercher des aversions concrètes. Dans le but d'être ouvert à comprendre exactement où Node.JS est immature - nous trouvons exactement où nous devons l'améliorer. Et c'est une bénédiction.

Bonne question. Pour ma part, je reste curieux de voir quelqu'un proposer une meilleure raison d'éviter NodeJS - que celles-ci.

Jack Stone
la source
-1

Y a-t-il un avantage à utiliser node over X pour les applications non temps réel:

  • Mise à l'échelle : le nœud a de bonnes performances, mais d'autres plates-formes aussi; PHP, Ruby, Python et Java toutes échelles. Vous pouvez trouver de gros noms avec des millions d'utilisateurs qui les utilisent.
  • Un langage pour le frontend et le backend : c'est une blague, tout comme Java "Write once run Anywhere"
  • Chaud et sexy : le seul point valable. Mais personne ne se soucie que votre site Web utilise une technologie avant-gardiste!

Avantage d'utiliser X over Node pour les applications non temps réel:

  • Meilleure pratique : Parce que Node est nouveau, il a moins de meilleures pratiques que les autres plates-formes, spécialement pour les applications Web CRUD.
  • Langage Javascript : les gens n'aiment pas Javascript. Alors que Node.js est chaud, Javascript ne l'est pas. C'est pourquoi les gens ont créé Coffeescript pour éviter d'écrire Javascript même pour le client.
  • Développer la vitesse : les cadres anciens et ennuyeux, y compris et sans s'y limiter, Rails et Django sont bien testés et améliorés au fil des ans pour les sites Web CRUD. Bien que vous puissiez implémenter des applications similaires dans Node, c'est simplement plus facile à faire dans le cadre de votre grand-père.
  • Stabilité : les infrastructures Web de Node s'améliorent à un rythme plus rapide. Cela signifie qu'ils changent et auront plus d'incompatibilité API dans un proche avenir.
  • Bibliothèques et outils : les technologies plus anciennes avec plus d'utilisateurs ont plus de bibliothèques et d'outils.

Ma réponse ne sera certainement pas valable en 2015. En 2014, ignorez Node pour les applications Web non temps réel, mais gardez un œil dessus.

Chaque framework web a un point fort. Vous serez heureux pendant que vous l'utilisez pour ce point. Les applications Web non temps réel ne sont pas le point fort des frameworks Web de Node.

Hossein
la source
2
-1. Je suis d'accord que cette réponse ne sera pas valable en 2015. Mais c'est aussi le raisonnement pour downvote.En substance - les décisions d'aujourd'hui SONT les décisions de demain. Cela annule les 8 points ci-dessus - si nous pouvons voir qu'ils ne sont que temporairement pertinents. 1) Mise à l'échelle - Les balances Walmart Mobile, ce n'est pas une raison pour éviter Node. 2) JS isomorphe n'est pas une blague. Pas une raison. 3) Sexyness du serveur? La plupart des utilisateurs ne connaissent que l'ux. 4) La meilleure pratique est subjective, 5) Pas chaude? -objectif 6) Plus facile? -subjectif. 7) La stabilité est un point temporairement pertinent. 8) Le MNP devrait dépasser Maven en 2014. Aucune raison ici. Downvote.
Jack Stone
-1

Node.js est une plate-forme très populaire et possède de nombreuses fonctionnalités intéressantes bla bla bla, mais l'utilisation d'un outil est une préférence personnelle. J'ai donné quatre fois à Node.js et je n'étais pas content. Voici mes raisons. Veuillez garder à l'esprit que certaines de ces raisons sont dépassées ou simplement personnelles: P

  • J'ai préféré une langue / syntaxe différente (j'aime Python, Scala, ma langue préférée est Prolog alors oui).
  • La qualité de la documentation pour les frameworks et les bibliothèques que j'ai utilisés n'est pas aussi bonne pour les bibliothèques Java, Scala, Python.
  • Les concepteurs des nodejs sont très obsédés par les rappels au lieu du modèle d'événement, de l'observateur ou des futurs.
  • Il y a des sollicitations prêtes pour ce que je veux faire en Ruby, Python, Java développé en 2005, j'ai juste besoin d'éditer le fichier de configuration.
David Sergey
la source
2
-1 - Points subjectifs. «Syntaxe préférée», «Documentation moins bonne», «Rappels obsessionnels» et «Déjà fait dans ma langue» - sont tous vagues et subjectifs. Nous en avons déjà entendu parler. Ils sont démystifiés. Aucune raison d'éviter Node.JS ici. Downvote.
Jack Stone
1
Tous les points sont ma préférence personnelle que j'ai déclarée ouvertement. Aussi comment démystifiez-vous vos préférences personnelles?
David Sergey
-9

HTTP est sans état, donc il n'y a en fait pas d'application Web non temps réel et donc aucune raison pour laquelle vous ne pouvez pas utiliser le nœud pour tout.

Cela dit, le nœud est mieux adapté à un type particulier d'architecture d'application. PHP est des fichiers html contenant un peu de code. Le nœud est un code contenant éventuellement un peu de code html.

Cela signifie que si votre application est constituée de formulaires html standard sans script côté client, PHP sera plus facile. Node possède des outils de création de modèles, mais évidemment pas aussi mature que quelque chose comme PHP.

Si vous avez beaucoup de scripts côté client et enregistrez les données avec ajax, vous vous retrouvez avec un client html statique appelant des fonctions sur le serveur. C'est exactement ce que le nœud est bon. Bien que ce ne soit pas la façon dont les applications CRUD sont généralement construites, vous pouvez produire quelque chose d'assez agréable avec le bon cadre.

Tom Clarkson
la source
Point pris sur le fait que HTTP soit sans état et en temps réel; cependant, je suis plus intéressé par les préoccupations pragmatiques concernant la définition typique du temps réel: des volumes élevés de demandes de faible poids. Il semble un peu exagéré de faire tourner une nouvelle instance PHP juste pour cracher parfois trois ou quatre lignes de JSON. Ai-je raison ou suis-je simplement atteint du syndrome du perroquet?
Paul d'Aoust
Si vous ne chargez pas PHP, vous chargez javascript, et il existe différents types de mise en cache impliqués, donc la différence ne sera pas suffisante. La grande différence réside dans le style de codage et donc la maintenabilité - les deux plates-formes peuvent produire du HTML ou du JSON, mais PHP a été conçu pour les personnes habituées à éditer des fichiers html statiques, tandis que le nœud a été conçu pour les personnes habituées à la programmation javascript moderne.
Tom Clarkson
Je sais que je dois charger un interprète un certain temps, mais je vois un avantage à avoir une instance de l'interprète en cours d'exécution tout le temps (pour les applications à faible CPU, bien sûr) comme dans Node.js plutôt que de faire tourner les interprètes et terminer avec chaque demande, comme en PHP.
Paul d'Aoust
Oui, et je m'attendrais également à ce que js ait de meilleures performances au niveau d'une demande individuelle compte tenu de la quantité de concurrence dans cet espace récemment. Cependant, je pense que c'est une partie relativement mineure de la différence - Avec le nœud, vous avez un contrôle direct et exactement la quantité de code nécessaire pour répondre à la demande, tandis que tout système basé sur un modèle qui suppose que vous servez des pages ajoutera une surcharge et une complexité inutiles dans d'autres scénarios.
Tom Clarkson