web-dev-qa-db-fra.com

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

J'étudiais Node.js récemment et je suis tombé sur du matériel pour écrire des serveurs simples basés sur Node.js. 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, bien que je semble comprendre ce qui se passe dans le code ... je suis un peu confus par la terminologie ... parce que quand j'entends le terme serveur, je pense à des choses comme Apache ou Nginx. J'ai l'habitude de penser à eux comme à un conteneur pouvant contenir mes applications Web. Quelle est la différence entre le serveur Node.js et le serveur Nginx/Apache? N'est-il pas vrai qu'un serveur basé sur Node.js (c'est-à-dire du code) peut toujours être placé dans quelque chose comme Nginx pour fonctionner? Alors, pourquoi s’appelle-t-on "serveurs", bien que le code Node.js semble être l’application pouvant être placée et servie à l’aide de Nginx.

javascriptnode.jsapachenginx
51
Grateful

C'est un serveur, oui.

Une application Web node.js est un serveur Web à part entière, tout comme Nginx ou Apache.

Vous pouvez en effet servir votre application node.js sans utiliser d’autre serveur Web. Il suffit de changer votre code pour:

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

En effet, certains projets utilisent node.js comme équilibreur de charge front-end pour d’autres serveurs (y compris Apache).

Notez que node.js n'est pas la seule pile de développement à effectuer cela. Les infrastructures de développement Web de Go, Java et Swift le font également.

Pourquoi?

Au début était le CGI. CGI était bien et a bien fonctionné. Apache recevait une requête, trouvait que l'URL devait exécuter une application CGI, exécutait cette application CGI, transmettait des données en tant que variables d'environnement, lisait la sortie standard et transmettait les données au navigateur.

Le problème est que c'est lent. C'est bien quand l'application CGI était un petit programme C compilé statiquement, mais un groupe de petits programmes C compilés statiquement est devenu difficile à maintenir. Les gens ont donc commencé à écrire dans des langages de script. Cela est ensuite devenu difficile à maintenir et les gens ont commencé à développer des frameworks MVC orientés objet. Maintenant, nous avons commencé à avoir des problèmes - CHAQUE DEMANDE doit compiler toutes ces classes et créer tous ces objets uniquement pour servir du HTML, même s'il n'y a rien de dynamique à servir (car le cadre doit comprendre qu'il n'y a rien de dynamique à servir).

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

C'était ce que les gens pensaient. Et pour tenter de résoudre ce problème, plusieurs stratégies sont apparues. L'un des premiers était d'intégrer directement des interprètes dans des serveurs Web, comme mod_php dans Apache. Les classes et objets compilés peuvent être stockés dans des variables globales et donc mis en cache. Une autre stratégie consistait à effectuer une pré-compilation. Une autre stratégie consistait à exécuter l'application en tant que processus serveur normal et à dialoguer avec le serveur Web à l'aide d'un protocole personnalisé tel que FastCGI.

Certains développeurs ont ensuite commencé à utiliser simplement HTTP comme protocole app-> serveur. En effet, l'application est aussi un serveur HTTP. L'avantage de cela est qu'il n'est pas nécessaire d'implémenter un nouveau protocole, éventuellement bogué, éventuellement non testé, et que vous pouvez déboguer votre application directement à l'aide d'un navigateur Web (ou aussi, généralement, curl). Et vous n'avez pas besoin d'un serveur Web modifié pour prendre en charge votre application, mais simplement de tout serveur Web capable d'effectuer des transferts inversés ou des redirections.

Pourquoi utiliser Apache/Nginx?

Lorsque vous desservez une application node.js, notez que vous êtes l'auteur de votre propre serveur Web. Tout bug potentiel dans votre application est un bug directement exploitable sur Internet. Certaines personnes ne sont (à juste titre) pas à l'aise avec cela.

L'ajout d'une couche d'Apache ou de Nginx devant votre application node.js signifie que vous disposez d'un logiciel éprouvé et éprouvé en matière de sécurité sur Internet en direct comme interface avec votre application. Il ajoute un tout petit peu de latence (le proxy inverse), mais la plupart estiment que cela en vaut la peine.

Auparavant, c'était le conseil standard de node.js. Mais ces jours-ci, il existe également des sites et des services Web qui exposent node.js directement à Internet. Le module http.Server est maintenant assez bien testé sur Internet pour faire confiance.

73
slebetman

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

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

Créez un serveur et écoutez les requêtes http sur le port 3000.

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

Supposons que deux instances de nodejs s'exécutent sur les ports 3000 et 3001, Vous pouvez maintenant utiliser nginx comme serveur pour écouter vos appels http actuels sur port 80 et rediriger votre demande vers le serveur nodejs ou un autre serveur , plus comme un loadbalancer. Vous pouvez donc toujours utiliser tout ce que nginx fournit avec nodejs.

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

10
Naeem Shaikh

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

Dès que le client commande une salade, le serveur se rend chez le chef pour le prévenir. 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 serveur ne l'apporte qu'après avoir servi la salade ..__ Le serveur continue d'attendre que le chef prépare la salade. Cet état est appelé état bloquant. Même si l'hôtel s'agrandit, chaque client devrait avoir des serveurs différents à servir. Cela augmente le blocage des threads (serveurs).

Maintenant, venant à Node Hotel, il n'y a qu'un seul serveur pour tous les clients. Si le premier client commande de la soupe, le serveur en informe le chef et passe au deuxième client. Une fois la nourriture prête, le serveur livre au client. Ici, le client n'attendra pas. Cet état est appelé état non bloquant. Le serveur unique (Thread) sert tous les clients et les rend heureux.

Ainsi, Node, qui est une application à un seul thread, est très rapide.

1
Vamshi Krishna