19 идей для node.js-разработчиков, которые стремятся вырасти над собой в 2019 году

Модули

Последнее обновление: 15.11.2018

Node.js использует модульную систему. То есть вся встроенная функциональность разбита на отдельные пакеты или модули. Модуль представляет блок кода,
который может использоваться повторно в других модулях.

Для загрузки модулей применяется функция , в которую передается название модуля. К примеру, в первом приложении из предыдущей темы для получения и обработки запроса
был необходим модуль http:

const http = require("http");

const os = require("os");
// получим имя текущего пользователя
let userName = os.userInfo().username;

console.log(userName);

Мы не ограничены встроенными модулями и при необходимости можем создать свои. Так, в прошлой теме проект состоял из файла app.js, в котором создавался сервер, обрабатывающий
запросы. Добавим в тот же каталог новый файл greeting.js и определим в нем следующий код:

console.log("greeting module");

В файле app.js подключим наш модуль:

const greeting = require("./greeting");

В отличие от встроенных модулей для подключения своих модулей надо передать в функцию require относительный путь с именем файла (расширение файла необязательно):

const greeting = require("./greeting");

Запустим приложение:

На консоль выводится та строка, которая определена в файле greeting.js.

Теперь изменим файл greeting.js:

let currentDate = new Date();
module.exports.date = currentDate;

module.exports.getMessage = function(name){
	let hour = currentDate.getHours();
	if(hour > 16)
		return "Добрый вечер, " + name;
	else if(hour > 10)
		return "Добрый день, " + name;
	else
		return "Доброе утро, " + name;
}

Здесь определена переменная . Однако из вне она недоступна. Она доступна только в пределах данного модуля. Чтобы какие переменные или функции
модуля были доступны, необходимо определить их в объекте module.exports. Объект — это то, что возвращает функция при получении модуля.

В частности, здесь определяется свойство и метод , который принимает некоторый параметр.

Далее изменим файл app.js:

const os = require("os");
const greeting = require("./greeting");

// получим имя текущего пользователя
let userName = os.userInfo().username;


console.log(`Дата запроса: ${greeting.date}`);
console.log(greeting.getMessage(userName));

Все экспортированные методы и свойства модуля доступны по имени: и .

Перезапустим приложение:

Определение конструкторов и объектов в модуле

Кроме определения простейших функций или свойств в модуле могут определяться сложные объекты или функции конструкторов, которые затем используются для создания объектов.
Так, добавим в папку проекта новый файл user.js:

function User(name, age){
	
	this.name = name;
	this.age = age;
	this.displayInfo = function(){
		
		console.log(`Имя: ${this.name}	Возраст: ${this.age}`);
	}
}
User.prototype.sayHi = function() {
    console.log(`Привет, меня зовут ${this.name}`);
};

module.exports = User;

Здесь определена стандартная функция конструктора User, которая принимает два параметра. При этом весь модуль теперь указывает на эту функцию конструктора:

module.exports = User;

Подключим и используем этот модуль в файле app.js:

const User = require("./user.js");

let eugene = new User("Eugene", 32);
eugene.sayHi();

Запустим приложение:

НазадВперед

Характерные особенности JS

JavaScript обычно используется в веб-разработке. Он был первоначально разработан Netscape как средство для добавления динамических и интерактивных элементов на веб-сайты. Хотя JavaScript зависит от Java, синтаксис больше похож на C и основан на ECMAScript — языке сценариев, разработанном Sun Microsystems.

JavaScript — это язык сценариев на стороне клиента. Это означает, что исходный код обрабатывается веб-браузером клиента, а не веб-сервером. Функции могут запускаться после загрузки веб-страницы без связи с сервером. Например, функция JavaScript может проверять веб-форму перед отправкой, чтобы убедиться, что все необходимые поля заполнены. Код может выдать сообщение об ошибке, прежде чем какая-либо информация будет фактически передана на сервер.

Подобно серверным скриптовым языкам, таким как PHP и ASP, код JavaScript может быть вставлен в любом месте HTML-страницы в веб. Однако в HTML отображается только вывод серверного кода, а код JavaScript остается полностью видимым в источнике веб-страницы. Его также можно найти в отдельном файле .JS, который также можно просмотреть в браузере.

Обнаружение лиц в Node.js с использованием Rust и WebAssembly

Перевод

В последней статье мы рассказывали, как вызывать функции Rust из Node.js. Сегодня мы расскажем, как написать приложение AIaaS (англ. Artificial Intelligence as a Service — «искусственный интеллект как услуга») на базе Node.js.

Большинство приложений с искусственным интеллектом сейчас разрабатываются на языке Python, а главным языком программирования для веб-разработки является JavaScript. Для того чтобы реализовать возможности ИИ в вебе, нужно обернуть алгоритмы ИИ в JavaScript, а именно в Node.js.

Однако ни Python, ни JavaScript сами по себе не подходят для разработки ИИ-приложений с большим объемом вычислений. Это высокоуровневые, медленные языки со сложной средой выполнения, в которых удобство использования достигается за счет снижения производительности. Для решения этой проблемы блоки интеллектуальных вычислений в Python оборачиваются в нативные C/C++-модули. Точно так же можно сделать и в Node.js, но мы нашли решение получше — WebAssembly.

Виртуальные машины WebAssembly поддерживают тесную интеграцию с Node.js и другими средами выполнения JavaScript-кода. Они отличаются высокой производительностью, безопасны с точки зрения доступа к памяти, изначально защищены и совместимы с разными операционными системами. В нашем подходе сочетаются лучшие возможности WebAssembly и нативного кода.

Перфоманс фронтенда как современное искусство: графики, код, кулстори

Всем привет. В предыдущих статьях мы говорили о базовых вещах оптимизации: раз и два. Сегодня я предлагаю с разбега окунуться в одну часть из тех задач, которыми занимается команда архитектуры фронтенда в hh.ru.

Я работаю в команде архитектуры. Мы не только перекладываем файлики из одной папки в другую, но и занимаемся кучей других вещей:

• Перфоманс приложения
• Инфраструктура: сборка, тесты, пайплайны, раскатка на продакшене, инструменты для разработчика (например бабель-плагины, кастомные eslint правила)
• Дизайн-система (UIKit)
• Переезд на новые технологии

Если покопаться, можно найти много интересного.

Поэтому, давайте поговорим о перфомансе. Команда фронтенд архитектуры ответственна как за клиентскую часть, так и серверную (SSR).

Я предлагаю посмотреть на метрики и разобраться, как мы реагируем на различные триггеры. Статья будет разбита на 2 составляющие. Серверную и клиентскую. Графики, код и кулстори прилагаются.

Задачи¶

Давайте проанализируем наше приложение. Что нужно, чтобы его реализовать:

У нас — онлайн веб-приложение, поэтому нам нужен HTTP-сервер;
Нашему серверу необходимо обслуживать различные запросы в зависимости от URL, по которому был сделан запрос. Для этого нам нужен какой-нибудь роутер (маршрутизатор), чтобы иметь возможность направлять запросы определенным обработчикам;
Для выполнения запросов, пришедших на сервер и направляемые роутером, нам нужны действующие обработчики запросов;
Роутер, вероятно, должен иметь дело с разными входящими POST-данными и передавать их обработчикам запросов в удобной форме

Для этого нам нужен какой-нибудь обработчик входных данных;
Мы хотим не только обрабатывать запросы, но и показывать пользователю контент по запрошенным URL-адресам, поэтому нам нужна некая логика отображения для обработчиков запросов, чтобы иметь возможность отправлять контент пользовательскому браузеру;
Последнее, но не менее важное — пользователь сможет загружать картинки, поэтому нам нужен какой-нибудь обработчик загрузки, который возьмёт на себя заботу о деталях.

Давайте подумаем о том, как бы мы реализовали это на PHP. Скорее всего, типичное решение будет на HTTP-сервере Apache с установленным mod_php5.

Это относится к первому пункту наших задач, то есть, «принимать HTTP-запросы и отправлять готовые веб-странички пользователю» — вещи, которые PHP сам не делает.

С Node.js — немного иначе. Потому что в Node.js мы не только создаем наше приложение, мы также реализуем полноценный HTTP-сервер. Действительно, наше веб-приложение и веб-сервер — в сущности, одно и тоже.

Может показаться, что это приведет к лишней работе, но сейчас вы увидите, что с Node.js это не так.

Давайте просто начнём реализовывать нашу первую задачу — HTTP-сервер.

Салют от Сбера в Яндекс.Облаке

Tutorial

В сентябре 2020 г. Сбербанк переименовал себя просто в Сбер (т.н. ребрендинг), и на радостях запустил собственную платформу голосовых ассистентов под названием Салют. Особенностью Салюта является наличие сразу трёх голосовых ассистентов на выбор пользователей: Сбер — мужчина, стиль обращения на «вы», Афина — женщина, обращается также на «вы», и Джой — девушка с дружеским «ты».Сбер (банк, не его тёзка — голосовой ассистент) открыл эту платформу для сторонних разработчиков, пригласив их делать для неё приложения, т.н. смартапы — аналог навыков голосовой помощницы Алисы, и учредив для них с весьма щедрым призовым фондом. В этом туториале мы рассмотрим как сделать смартап на Node.js, разместить его код в Яндекс.Облаке (используя функции), и, наконец, создать проект в Салюте, пройти там модерацию, и опубликовать наш смартап, чтобы он стал общедоступным.

Вебсокеты: боевое применение

Вебсокеты — это прогрессивный стандарт полнодуплексной (двусторонней) связи с сервером по TCP-соединению, совместимый с HTTP. Он позволяет организовывать живой обмен сообщениями между браузером и веб-сервером в реальном времени, причем совершенно иным способом, нежели привычная схема «запрос URL — ответ». Когда два года назад я присматривался к этому стандарту, он был еще в зачаточном состоянии. Существовал лишь неутвержденный набросок черновика и экспериментальная поддержка некоторыми браузерами и веб-серверами, причем в Файрфоксе он был по умолчанию отключен из-за проблем с безопасностью. Однако теперь ситуация изменилась. Стандарт приобрел несколько ревизий (в том числе без обратной совместимости), получил статус RFC () и избавился от детских болезней. Во всех современных браузерах, включая IE10, заявлена поддержка одной из версий протокола, и есть вполне готовые к промышленному использованию веб-серверы.
Я решил, что настало время попробовать это на живом проекте. И теперь делюсь, что из этого вышло.

Лёгкое программирование: канбан-доска для GitLab за один рабочий день

В жизни начинающего тимлида рано или поздно настаёт момент, когда он понимает, что его команде нужна канбан-доска. Она снимает беспокойство по поводу контроля процесса разработки и даёт уверенность в завтрашнем дне. Обычно эта проблема решается нижайшей просьбой к завхозу купить магнитную доску, набор разноцветных стикеров и пару-тройку маркеров для доски. Ну или использованием сервисов вроде Jira. Но в нашей команде один разработчик на удалёнке, а гитлаб в закрытом контуре (недоступен из интернетов по соображениям информационной безопасности), поэтому выбирать пришлось наиболее простое из двух возможных решений:
а) создание механической руки и контроллера к ней, который позволит удалённо переклеивать стикеры на доске, при этом, чтобы не усложнять решение, писать на стикерах нам придётся за нашего недосягаемого коллегу, что несправедливо;
б) реализация программной канбан-доски, которая собирала бы все задачи с нашего гитлаба.
Конечно, душа лежала к ламповой физической доске. Я даже начал размышлять об использовании DualShock 4 в качестве контроллера механической руки, но я сам себе обозначил дедлайн утром следующего дня, поэтому пришлось обойтись бездушным программным решением.

Работа с потоками в Node.js

stream

▍О сильных сторонах использования потоков

• Эффективное использование памяти. Работа с потоком не предполагает хранения в памяти больших объёмов данных, загружаемых туда заранее, до того, как появится возможность их обработать.
• Экономия времени. Данные, получаемые из потока, можно начать обрабатывать гораздо быстрее, чем в случае, когда для того, чтобы приступить к их обработке, приходится ждать их полной загрузки.

▍API Node.js, в которых используются потоки

• — возвращает поток, подключённый к .
• — возвращает поток, подключённый к .
• — возвращает поток, подключённый к .
• — создаёт читаемый поток для работы с файлом.
• — создаёт записываемый поток для работы с файлом.
• — инициирует соединение, основанное на потоке.
• — возвращает экземпляр класса , предоставляющий доступ к записываемому потоку.
• — сжимает данные с использованием алгоритма и отправляет их в поток.
• — выполняет декомпрессию -потока.
• — сжимает данные с использованием алгоритма и отправляет их в поток.
• — выполняет декомпрессию -потока.

▍Разные типы потоков

• Поток для чтения () — это поток, из которого можно читать данные. Записывать данные в такой поток нельзя. Когда в такой поток поступают данные, они буферизуются до того момента пока потребитель данных не приступит к их чтению.
• Поток для записи () — это поток, в который можно отправлять данные. Читать из него данные нельзя.
• Дуплексный поток () — в такой поток можно и отправлять данные и читать их из него. По существу это — комбинация потока для чтения и потока для записи.
• Трансформирующий поток () — такие потоки похожи на дуплексные потоки, разница заключается в том, что то, что поступает на вход этих потоков, преобразует то, что из них можно прочитать.

Deno v1.0: Безопасная среда выполнения для JavaScript и TypeScript. Обзор возможностей

1. Вступление
2. Установка
3. Как это выглядит внутри
4. Функциональность
5. WASM, RUST, Плагины
6. Debugging, IDE
7. Тестирование
8. Compiler API
9. CI
10. Разное

Вступление

Если вы уже оказались за чтением этой статьи, то наверняка уже слышали про выступление Ryan Dahl, создателя NodeJS, на JSConf, где он выступил с докладом и рассказал о ключевых ошибках, которые были сделаны при проектировании NodeJS. В этом же докладе он обьявил о новом проекте: Deno, в котором будут учтены ошибки предыдущего проектирования.

Вдохновившись этим анонсом, я внимательно стал следить за проектом и пробовать реализовывать на нем различные проекты.

Как уберечь свои данные от воровства, перепить Левелорда и построить карьеру в IT, если у вас шиза

За фото благодарим imater На самом деле, на КДПВ не рабочее место на балконе, это обман зрения. Там пляж, шашлычки на природе и вот это все…
Привет, Хабр! На июнь мы подготовили для вас целых 5 новых спикеров, будем говорить:

• Об утечках данных с Ашотом Оганесяном
• О фронтенде Яндекс.Денег с тимлидом Ильей Кашлаковым
• О том, как отучить целую страну качать фильмы с торрентов с CTO Okko Алексеем Голубевым
• Как строить карьеру в IT, если у вас психическое расстройство с маркетологом RUVDS Санией Галимовой

Есть и супербонус: вы сможете сыграть на выпивание с Ричардом Левелордом Греем на zoom-посиделке и попытаться его обыграть.

Телепортация тонн данных в PostgreSQL

Сегодня я поделюсь некоторыми полезными архитектурными решениями, которые возникли в процессе развития нашего инструмента массового анализа производительности серверов PostgeSQL, и которые помогают нам сейчас «умещать» полноценный мониторинг и анализ более тысячи хостов в то же «железо», которого сначала едва хватало для одной сотни.

Intro

Напомню некоторые вводные:

• мы строим сервис, который получает информацию из логов серверов PostgreSQL
• собирая логи, мы хотим что-то с ними делать (парсить, анализировать, запрашивать дополнительную информацию) в режиме онлайн
• все собранное и «наанализированное» надо куда-то сохранить

Именно про последний пункт — как все это можно доставить в PostgreSQL-хранилище, и поговорим. В нашем случае таких данных кратно больше, чем исходных — статистика нагрузки в разрезе конкретного приложения и шаблона плана, потребление ресурсов и вычисление производных проблем с точностью до отдельного узла плана, мониторинг блокировок и многое другое.

Formidable, Busboy, Multer или Multiparty? Выбор npm-пакета для обработки файлов, выгружаемых на сервер

Перевод

Существует немало npm-пакетов, предназначенных для разбора и обработки multipart/form-data-запросов на Node.js-сервере. Каждый из них спроектирован по-особенному. Некоторые предназначены для использования с Express.js, другие рассчитаны на автономное применение. Некоторые хранят промежуточные файлы на жёстком диске или в памяти, а некоторые — нет. Исследование всех этих пакетов и выбор того, который подойдёт именно вам, может занять определённое время. Материал, перевод которого мы публикуем сегодня, представляет собой руководство, воспользовавшись которым можно выбрать подходящую библиотеку для организации выгрузки файлов на сервер. Тому, кто подбирает подобную библиотеку, автор этого материала рекомендует сначала ответить на следующие вопросы:

1. Нужен ли вам Express.js?
2. Устроит ли вас сохранение где-либо промежуточных данных, или вы хотите использовать потоковую передачу данных?
3. Если сохранение промежуточных данных вас устроит, предпочтёте ли вы, чтобы они хранились бы в памяти, или на жёстком диске?

9 лет в монолите на Node.JS

Неделю назад я выступал на митапе по Node.JS, и многим обещал выложить запись выступления. Уже потом я понял, что мне не удалось вместить в регламентированные полчаса некоторые интересные факты. Да и сам я больше люблю читать, а не смотреть и слушать, поэтому решил выложить выступление в формате статьи. Впрочем, видео тоже будет в конце поста в разделе ссылок.

Рассказать я решил про набившую оскомину тему — жизнь в монолите. Об этом на хабре уже есть сотни статей, тысячи копий сломаны в комментах, истина давно погибла в спорах, но… Дело в том, что у нас в OneTwoTrip есть весьма специфический опыт, в отличие от многих людей, которые пишут про некие архитектурные паттерны в вакууме:

• Во-первых, нашему монолиту уже 9 лет.
• Во-вторых, всю жизнь он провёл под хайлоадом (сейчас это 23 млн запросов в час).
• А в NaN-ых, мы пишем наш монолит на Node.JS, который за эти 9 лет изменился до неузнаваемости. Да, мы начинали писать на ноде в 2010, безумству храбрых поём мы песню!

Так что всякой специфики и реального опыта у нас довольно много. Интересно? Поехали!

Как и почему Яндекс переехал с собственного npm-репозитория на Verdaccio

Всем привет. Меня зовут Андрей Фримучков, я работаю в команде инфраструктуры разработки интерфейсов Яндекса. Последние несколько месяцев участвовал в запуске нового хранилища пакетов. Около года назад мы упёрлись в ограничения собственного решения и после череды экспериментов пришли к выводу, что дальше масштабироваться под растущие нагрузки не получится.
Нужно было искать что-то новое. Выбор пал на опенсорсное решение под названием Verdaccio. Это может показаться странным, потому что им чаще пользуются небольшие компании. Скажу честно, настроить работу оптимально и внести необходимые доработки было непросто, но интересно. И стоило того. А теперь — обо всём по порядку.

Как пакеты хранились раньше?

Хорошая практика при разработке на JS — хранить внутренние пакеты в собственном репозитории и сохранять копии внешних пакетов. Это снижает зависимость от внешнего npm и позволяет ограничить выходы во внешнюю сеть в системах сборки. Исторически Яндекс использовал своё решение для хранения внутренних пакетов. Долгое время оно всех устраивало, но компания росла. Росли нагрузки, репозиторий стало сложно масштабировать и поддерживать. Например, при регламентных работах в датацентрах приходилось вручную переключать мастер у CouchDB. Схема выглядела следующим образом:

Преимущества и важные нюансы

Одним из основных преимуществ Node.js, по словам его создателя Райана Даля, является то, что он не блокирует ввод/вывод (I/O). Некоторые разработчики очень критично относятся к Node.js и отмечают, что если для одного процесса требуется значительное количество циклов процессора, приложение блокируется. Это может привести к сбою. Сторонники модели Node.js утверждают, что время обработки процессора меньше беспокоит из-за большого числа небольших процессов, на которых основан код узла.

Популярность приложений JavaScript стремительно растет в последние несколько лет, а Node.js определенно способствует этому росту. Если мы посмотрим на статистические данные, то увидим, что в мире больше пакетов Node, чем аналогичных данных Ruby. Второй фактор: пакеты Node растут быстрее, чем Ruby, Python и Java.

Что делает более популярным, чем Rails и другие альтернативы Node.JS? С чего начать изучение? Node сам по себе является асинхронной платформой, основанной на событиях, построенной на базе движка JavaScript Chrome и предназначенной для создания масштабируемых сетевых приложений. Иными словами, Node.js — это JavaScript плюс C/C ++ в совокупности с файловой системой, запуском HTTP или TCP-серверов.

Node однопоточен и использует модель параллелизма, основанную на цикле событий. Он не блокирует процессы и не заставляет программу ждать, но регистрирует обратный вызов и позволяет приложению продолжить работу. Это означает, что платформа может обрабатывать параллельные операции без нескольких потоков выполнения и эффективно масштабируется.

Между последовательными языками и Node.js существуют большие различия:

• Node позволяет выполнять другие задачи, ожидая уведомления, когда ответ будет доступен;

• приложение не буферизует данные в память, а вместо этого выводит его фрагментарно.

Хотя существуют другие системы циклов событий (например, библиотека EventMachine в Ruby или Twisted на Python), между ними и Node существует значительная разница.

В Node.JS все библиотеки были разработаны с нуля, чтобы быть неблокируемыми, чего нельзя сказать о других.

Пример: веб-сервер на Node.js

Как рабо­та­ет обыч­ный веб-сервер

Рань­ше была такая проблема:

1. На стра­ни­це нуж­но, напри­мер, пока­зать ава­тар­ку и ник­нейм пользователя.
2. Для это­го сер­вер делал запрос к базе дан­ных, что­бы полу­чить отту­да эту информацию.
3. Пока база не отве­тит, сер­вер ниче­го не может сде­лать — он тер­пе­ли­во ждёт.
4. Сер­вер ждёт.
5. Когда от базы при­хо­дит ответ с кар­тин­кой и ник­ней­мом, сер­вер сно­ва ожи­ва­ет, про­дол­жа­ет загру­жать стра­ни­цу и в самом кон­це запра­ши­ва­ет у базы фоно­вую кар­тин­ку для сайта.
6. Сер­вер ждёт
7. Стра­ни­ца тоже пока не рабо­та­ет, пото­му что не загру­зи­лась до кон­ца. Поло­ви­на скрип­тов тоже не рабо­та­ют, пото­му что они ждут пол­ной загруз­ки стра­ни­цы. Все ждут, пока база ответит.
8. На каж­дый такой запрос нуж­ны ресур­сы, что­бы дер­жать соеди­не­ние с базой.
9. Если таких запро­сов мно­го, ресур­сы на сер­ве­ре быст­ро закан­чи­ва­ют­ся, и тогда сайт начи­на­ет тор­мо­зить у всех сразу.
10. Сер­вер начи­на­ет тупить и ино­гда выва­ли­ва­ет­ся с ошиб­кой. Стра­ни­цы пада­ют, поль­зо­ва­те­ли психу­ют и ухо­дят на дру­гой сайт.

Реализация технологии SSO на базе Node.js

Перевод

Веб-приложения создают с использованием клиент-серверной архитектуры, применяя в качестве коммуникационного протокола HTTP. HTTP — это протокол без сохранения состояния. Каждый раз, когда браузер отправляет серверу запрос, сервер обрабатывает этот запрос независимо от других запросов и не связывает его с предыдущими или последующими запросами того же самого браузера. Это, кроме прочего, означает, что получить доступ к серверным ресурсам, которые никак не защищены, может кто угодно. Если нужно защитить от посторонних некие серверные ресурсы, это значит, что нужно как-то ограничить то, что может запрашивать у сервера браузер. То есть — нужно аутентифицировать запросы и отвечать только на те из них, которые прошли проверку, игнорируя те, которые проверку не прошли. Для аутентификации запросов нужно владеть некими сведениями о запросах, хранящимися на стороне браузера. Так как протокол HTTP не хранит состояние запросов, нам для этого нужны некие дополнительные механизмы, которые позволяют серверу и браузеру совместно управлять состоянием соединений. Среди таких механизмов можно отметить использование куки-файлов, сессий, JWT.
Если речь идёт о каком-то одном веб-проекте, то сведения о состоянии конкретного сеанса взаимодействия клиента и сервера легко поддерживать с применением аутентификации пользователя при его входе в систему. Но если такая вот самостоятельная система эволюционирует, превращаясь в несколько систем, перед разработчиком встаёт вопрос о поддержании сведений о состоянии каждой из этих отдельных систем. На практике этот вопрос выглядит так: «Придётся ли пользователю этих систем входить в каждую из них по-отдельности и так же из них выходить?».

Первое приложение на Node.js

Последнее обновление: 14.11.2018

Напишем первое простейшее приложение для NodeJS. Для создания приложений можно использовать практически все стандартные конструкции языка JavaScript.
Исключением является работа с DOM, так как приложение будет запускаться на сервере, а не в браузере, поэтому DOM и такие объекты как или
в данном случае нам будут недоступны.

Для этого вначале создадим для приложения каталог на жестком диске. К примеру, я создал каталог
C:\node\helloapp. В этом каталоге создадим файл app.js.

Определим в файле app.js следующий код:

const http = require("http");
http.createServer(function(request,response){
	
	response.end("Hello NodeJS!");
	
}).listen(3000, "127.0.0.1",function(){
	console.log("Сервер начал прослушивание запросов на порту 3000");
});

Вкратце разберем этот код.

На первой строке мы получаем модуль http, который необходим для создания сервера. Это встроенный модуль, и для его загрузки необходимо применить функцию :

const http = require("http");

Далее с помощью метода создается новый сервер для прослушивания входящих подключений и обработки запросов. В качестве параметра
этот метод принимает функцию, которая имеет два параметра. Первый параметр request хранит всю информацию о запросе, а второй параметр response используется
для отправки ответа. В данном случае ответ представляет простую строку «Hello NodeJS!» и отправляется с помощью метода .

Но метод только создает сервер. Чтобы сервер начал прослушивать входящие подключения у него надо вызвать метод :

.listen(3000, "127.0.0.1",function(){
	console.log("Сервер начал прослушивание запросов на порту 3000");
});

Этот метод принимает три параметра. Первый параметр указывает на локальный порт, по которому запускается сервер. Второй параметр указывает
на локальный адрес. То есть в данном случае сервер будет запускаться по адресу 127.0.0.1 или localhost на порту 3000.

Третий параметр представляет функцию, которая запускается при начале прослушивания подключений. Здесь эта функция просто выводит диагностическое сообщение на консоль.

Теперь запустим сервер. Для этого откроем терминал (в OS X или Linux) или командную строку (в Windows). С помощью команды cd
перейдем к каталогу приложения:

cd C:\node\helloapp

Затем вызовем следующую команду:

node app.js

Она запускает сервер:

Далее откроем браузер и введем в адресную стоку адрес http://localhost:3000/:

И нам отобразится то сообщение, которое было послано в методе .

НазадВперед