Ответ 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]
теперь достаточно хорошо проверен в Интернете, чтобы ему доверяли.