Сервер Node.js против чего-то вроде HTTP-сервера Apache

Недавно я изучал Node.js и наткнулся на некоторые материалы по написанию простых серверов на базе Node.js. Например...

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!");
});

... Теперь, хотя я, кажется, понимаю, что происходит в коде... Я немного смущен терминологией.... потому что, когда я слышу термин сервер, я думаю о таких вещах, как Apache или Nginx. Я привык думать, что они похожи на контейнер, который может содержать мои веб-приложения. Как сервер Node.js отличается от сервера Nginx/Apache? Не правда ли, что сервер Node.js (т.е. код) все еще может быть помещен в нечто вроде Nginx для запуска? Итак, почему оба называются "серверами", хотя код Node.js, по-видимому, является приложением, которое можно разместить и обслуживать с помощью Nginx.

Ответ 1

Это сервер, да.

Веб-приложение node.js является полнофункциональным веб-сервером, как Nginx или Apache.

Вы действительно можете обслуживать приложение node.js без использования какого-либо другого веб-сервера. Просто измените свой код на:

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

В самом деле, некоторые проекты используют node.js в качестве front-end load balancer для других серверов (включая Apache).

Обратите внимание, что node.js не является единственным стеком разработки для этого. Рамки веб-разработки в Go, Java и Swift также делают это.

Зачем?

Вначале был CGI. CGI был в порядке и работал нормально. Apache получит запрос, найдет, что URL-адрес должен выполнить приложение CGI, выполнить это приложение CGI и передать данные в качестве переменных среды, прочитать stdout и вернуть данные в браузер.

Проблема в том, что она медленная. Это нормально, когда приложение CGI было небольшой статически скомпилированной программой на C, но группа небольших статически скомпилированных программ на C стала трудно поддерживать. Поэтому люди начали писать на языках сценариев. Затем это стало трудно поддерживать, и люди начали разрабатывать объектно-ориентированные структуры MVC. Теперь у нас возникли проблемы - КАЖДЫЙ ЗАПРОС должен скомпилировать все эти классы и создать все эти объекты только для того, чтобы обслуживать какой-то HTML, даже если нет ничего динамичного для обслуживания (потому что в структуре необходимо выяснить, что нет ничего динамичного для обслуживания).

Что делать, если нам не нужно создавать все эти объекты в каждом запросе?

Это то, что люди думали. И от попыток решить эту проблему возникло несколько стратегий. Одним из первых было встроить интерпретаторы непосредственно в веб-серверы, такие как mod_php в Apache. Скомпилированные классы и объекты могут храниться в глобальных переменных и поэтому кэшироваться. Другая стратегия заключалась в том, чтобы сделать предварительную компиляцию. И еще одна стратегия заключалась в том, чтобы запустить приложение как обычный серверный процесс и поговорить с веб-сервером, используя специальный протокол, например FastCGI.

Затем некоторые разработчики начали просто использовать HTTP в качестве своего app-> серверного протокола. Фактически, приложение также является HTTP-сервером. Преимущество этого заключается в том, что вам не нужно внедрять какой-либо новый, возможно, глючный, возможно, не проверенный протокол, и вы можете отлаживать приложение напрямую с помощью веб-браузера (или, как правило, curl). И вам не нужен модифицированный веб-сервер для поддержки вашего приложения, а также любой веб-сервер, который может выполнять обратное проксирование или перенаправление.

Зачем использовать Apache/Nginx?

Когда вы обслуживаете приложение node.js, обратите внимание, что вы являетесь автором собственного веб-сервера. Любая потенциальная ошибка в вашем приложении является прямой эксплуатационной ошибкой в Интернете. Некоторые люди (по праву) не устраивают это.

Добавление слоя Apache или Nginx перед вашим приложением node.js означает, что у вас есть проверенное сражение, защищенное от копирования программное обеспечение в реальном времени в Интернете в качестве интерфейса к вашему приложению. Он добавляет крошечную задержку (обратное проксирование), но большинство считают, что это того стоит.

Раньше это был стандартный совет в первые дни node.js. Но в наши дни есть также сайты и веб-службы, которые предоставляют node.js прямо в Интернет. Модуль [http.Server][1] теперь достаточно хорошо проверен в Интернете, чтобы ему доверяли.

Ответ 2

NodeJs создает собственный сервер. Как вы можете видеть, терминология совершенно ясна:

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

Создайте сервер и прослушайте HTTP-запросы на порту 3000.

Мы использовали nginx в одном из наших проектов, но он был больше похож на loadbalancer для нескольких экземпляров nodejs.

Допустим, у вас есть два экземпляра nodejs, запущенных на портах 3000 и 3001. Теперь вы можете использовать nginx в качестве сервера для прослушивания ваших фактических http вызовов на port 80 и можете перенаправить ваш запрос на сервер nodejs или, возможно, на другой сервер, более как loadbalancer. Таким образом, вы все равно можете использовать все, что nginx предоставляет с помощью nodejs.

Хороший вопрос уже задавал здесь.