Dans quels cas doit on préfèrent utiliser Node.js seulement comme un serveur de déploiement réel ?
Quand on ne veux pas utiliser Node.js seulement, ce qui joue mieux avec Node.js ? Apache ou Nginx ?
Réponses
Trop de publicités?
Il y a plusieurs bonnes raisons de coller un autre serveur en face de Node.js:
- Ne pas avoir à vous soucier de privilèges/setuid pour l'Node.js processus. Seul root peut se lier à port 80 en général. Si vous laissez nginx/Apache soucier de départ en tant que root, la liaison vers le port 80, puis renonce à ses privilèges de root, cela signifie que votre Nœud de l'application n'ont pas à s'inquiéter à ce sujet.
- Servir les fichiers statiques (images, css, js et html. Le nœud peut être moins efficace par rapport à l'utilisation correcte d'un fichier statique serveur web (Nœud peut également être plus rapide de sélectionner les scénarios, mais il est peu probable d'être la norme). Sur le haut de fichiers de servir plus efficacement, vous n'aurez pas à vous inquiéter au sujet de la manipulation eTags ou cache-têtes de contrôle de la manière que vous le feriez si vous étiez portions des choses hors de Nœud. Certains cadres peuvent gérer cela pour vous, mais vous voulez être sûr. Quel que soit, encore probablement plus lent.
- Comme Matt Sergent mentionné dans sa réponse, vous pouvez plus facilement l'affichage d'erreur significatif de pages ou de retomber sur un site statique si votre nœud de service tombe en panne. Sinon, les utilisateurs peuvent tout simplement obtenir un temps de connexion.
- L'exécution d'un autre serveur web en face de Nœud peut aider à atténuer les failles de sécurité et les attaques par déni de service contre Nœud. Pour un exemple réel, CVE-2013-4450 est empêché par l'exécution de quelque chose comme Nginx en face de Nœud.
Je vais avertissement au deuxième point, en disant: vous devez sans doute être au service de tous vos fichiers statiques via un CDN, ou de derrière un serveur de mise en cache comme un Vernis. Si vous faites cela, il n'a pas vraiment d'importance si l'origine est le Nœud ou Nginx ou Apache.
Mise en garde avec nginx particulier: si vous êtes à utiliser les websockets, assurez-vous d'utiliser une version récente de nginx (>= 1.3.13), étant donné qu'il vient d'ajouter le support pour la mise à niveau de la connexion à utiliser les websockets.
Matt Sergeant
Points
843
Juste pour ajouter une raison de plus pour la réponse de pauljz, j’utilise un serveur frontal pour qu’il peut faire des pages d’erreur 502 lorsque je suis en redémarrant le serveur back-end ou il tombe en panne pour une raison quelconque. Cela permet aux utilisateurs de passer jamais une erreur sujet incapable d’établir une connexion.
Tom Dworzanski
Points
887
Il est ma conviction que l'aide d'un Noeud de servir les fichiers statiques est très bien, en toutes circonstances, aussi longtemps que vous savez ce que vous faites. C'est certainement un nouveau paradigme pour utiliser le serveur d'applications pour servir les fichiers statiques comme beaucoup (tous?) les technologies concurrentes (PHP, Ruby, Python, etc) ont besoin d'un serveur web comme HTTPD ou Nginx en frontal du serveur d'application(s).
Chaque objectif de la raison pour laquelle je n'ai jamais lu à l'encontre de servir les fichiers statiques avec Nœud tourne autour de l'idée de l'utilisation de ce que vous connaissez le mieux ou à l'aide de ce qui est perçu comme mieux-testé / plus stable. Ce sont des raisons très valables, pratiquement parlant, mais ont peu d'ordre purement technique de la pertinence.
À moins de trouver une fonction qui est possible avec un classique serveur web qui n'est pas possible avec le Noeud (et je doute que vous), choisissez ce que vous connaissez le mieux ou ce que vous préférez travailler avec une ou l'autre approche est très bien.
Comme pour Nginx vs Apache -- ils vont "jouer" avec Nœud sur le même. Vous devriez les comparer, sans égard à Nœud.
