Serveur basé sur Node.js ou quelque chose comme le serveur HTTP Apache

Question

J'ai été étudiant Node.js récemment et suis tombé sur quelques documents sur l'écriture simple Node.js les serveurs. Par exemple...

var express = require("express"),
http = require("http"), app;

// Create our Express-powered HTTP server
// and have it listen on port 3000
app = express();
http.createServer(app).listen(3000);

// set up our routes
app.get("/hello", function (req, res) {
    res.send("Hello World!");
});

app.get("/goodbye", function (req, res) {
    res.send("Goodbye World!");
});

... Maintenant, même si j'ai l'air de comprendre ce qu'il se passe dans le code... je suis un peu confus par la terminologie.... parce que quand j'entends le terme de serveur, je pense à des trucs comme Apache ou Nginx. Je suis habitué à la pensée de l'être comme un conteneur qui peut contenir mes applications web. Comment Node.js serveur diffèrent de Nginx/Apache serveur? N'est-il pas vrai qu'un Node.js en fonction de serveur (c'est à dire le code) peuvent toujours être placée à l'intérieur de quelque chose comme Nginx courir? Alors pourquoi tous les deux sont appelés "serveurs", bien que le Node.js code semble être l'application qui peut être mis en place et servis à l'aide de Nginx.

Answer 1

C'est un serveur, oui.

Un node.js une application web est un véritable serveur web juste comme Nginx ou Apache.

En effet, vous pouvez servir votre node.js application sans l'aide de tout autre serveur web. Il suffit de changer votre code:

app = express();
http.createServer(app).listen(80); // serve HTTP directly

En effet, certains projets utilisent des node.js comme le front-end d'équilibrage de la charge pour les autres serveurs (y compris Apache).

Notez que node.js n'est pas la seule pile de développement pour ce faire. Web de développement des cadres à l'Aller, Java et Swift aussi le faire.

Pourquoi?

Au commencement était le CGI. CGI a été beaux et travaillé sur OK. Apache voudrais obtenir une demande, de trouver que l'url doit exécuter une application CGI, l'exécution de cette application CGI et de transmettre des données comme des variables d'environnement, lire le stdout et de servir les données vers le navigateur.

Le problème est qu'il est lent. C'est OK lorsque le CGI app est un petit programme C compilé statiquement, mais un groupe de petites compilé statiquement les programmes en C est devenu difficile à maintenir. Donc, les gens ont commencé à écrire dans les langages de script. Alors, qui est devenu difficile à maintenir et les gens ont commencé en développement orienté objet, MVC, frameworks. Maintenant, nous avons commencé à avoir de la difficulté à CHAQUE DEMANDE doit compiler toutes ces classes et de créer tous ces objets juste pour servir le code HTML, même si il n'y a rien de dynamique pour servir (parce que le cadre doit comprendre qu'il n'y a rien de dynamique de servir).

Et si nous n'avons pas besoin de créer tous ces objets à chaque demande?

C'était ce que les gens pensaient. Et d'essayer de résoudre ce problème est venu plusieurs stratégies. L'un des premiers a été d'incorporer les interprètes directement dans les serveurs web, comme mod_php de Apache. Compilé les classes et les objets peuvent être stockées dans des variables globales et par conséquent mis en cache. Une autre stratégie a été de faire de pré-compilation. Et pourtant, une autre stratégie a été de lancer l'application régulière d'un processus de serveur et de parler avec le serveur web à l'aide d'un protocole personnalisé comme FastCGI.

Ensuite, certains développeurs ont commencé tout simplement à l'aide de HTTP comme leur app->serveur de protocole. En effet, l'application est également un serveur HTTP. L'avantage, c'est que vous n'avez pas besoin de mettre en œuvre de nouvelles, éventuellement, buggy, peut-être pas testé le protocole et vous pouvez déboguer votre application directement à l'aide d'un navigateur web (ou aussi souvent, curl). Et vous n'avez pas besoin d'une modification de serveur web à l'appui de votre application, il suffit de n'importe quel serveur web qui peuvent faire des proxy inverse ou les redirections.

Pourquoi utiliser Apache/Nginx?

Lorsque vous servez d'un node.js application note que vous êtes l'auteur de votre propre serveur web. Tout bug potentiel de votre application est directement exploitable bug sur l'internet. Certaines personnes sont (à juste titre) de ne pas à l'aise avec cela.

L'ajout d'une couche d'Apache ou Nginx en face de votre node.js app signifie que vous avez une bataille testés, à la sécurité trempé un morceau de logiciel sur le live internet comme interface de votre application. Il ajoute un petit peu de latence (le proxy inverse), mais la plupart considèrent qu'il vaut.

Cette habitude d'être la norme des conseils dans les premiers jours de node.js. Mais ces jours, il ya aussi des sites web et des services qui expose node.js directement à internet. L' http.Server module est maintenant assez bien de bataille testés sur internet pour être digne de confiance.

Answer 2

NodeJs crée son propre serveur. Comme vous pouvez le voir, la terminologie est assez clair:

http.createServer(app).listen(3000);

Créer un serveur et d'écouter les requêtes http sur le port 3000.

Nous avons utilisé nginx dans l'un de nos projets, mais c'était plus comme un loadbalancer pour plusieurs nodejs instances.

Disons que vous avez deux nodejs les instances en cours d'exécution sur le port 3000 et 3001, Maintenant, vous pouvez toujours utiliser nginx comme un serveur pour écouter votre effectif http des appels sur port 80, et peut être l'envie de rediriger votre demande à l' nodejs serveur ou peut-être un autre serveur, plus comme un loadbalancer. Vous pouvez toujours utiliser quelle que soit nginx fournit nodejs.

Une bonne question déjà posée ici.

Answer 3

Supposons qu'il existe un hôtel nommé Apache Hôtel qui a un serveur pour chaque client.

Dès que le client commande une salade, le garçon va à la chef et lui dit. Pendant que le chef prépare la nourriture, le serveur attend. Ici,

Chef => File System,

Waiter => Thread,

Customer => Event.

Même lorsque le client commande de l'eau le garçon apporte seulement après avoir servi la salade. Le garçon continue à attendre jusqu'à ce que la salade est préparé par le chef. Cet état est appelé état de blocage. Même si l'hôtel grandit chaque client sont différents serveurs pour servir. Cela augmente le blocage de threads(les serveurs).

Maintenant, venir à un Nœud de l'Hôtel il y a un seul garçon pour tous les clients. Si les premières commandes des clients de la soupe le garçon dit le chef et va à la deuxième client. Après le repas est prêt, le serveur offre pour le client. Ici, le client n'aura pas à attendre. Cet état est désigné comme le Non-état de Blocage. Le seul garçon(Thread) les serveurs de tous les clients et les rend heureux.

Ainsi, le Nœud qui est un seul thread de l'application est très rapide.