Большая передняя дорога Pony — предварительное исследование Node.js

Добро пожаловать в команду веб-разработчиков Futu

Уже поздний вечер, ты уже признался любимой девушке в День смеха? Ха-ха. . .

Я хотел бы поздравить вас всех здесь.

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

Недавно была статья про модуль (modular) и babel, но в ней не разобрались. Давайте начнем с разминки node.js. Многие вещи, описанные в этой статье, все еще используются во внешнем интерфейсе Futu, и всем должно быть полезно понять интерфейс Futu.

Хорошей новостью является то, что внешний фреймворк Futu постепенно заменяется vue (исходный использовал JQ, angular.js). Слой доступа node.js также находится в разработке, а внешние сервисы не за горами. Я считаю, что друзья, которым нравятся vue.js и node.js, уже готовы к переезду.

Верно, Xiaobian является одним из промоутеров сервиса Futu node.js.

Чтобы быть фронтендом в Futu, нужно не только фронтенд написать, но и сервис node.js написать, особо думать об этом не нужно.

Возвращаясь к теме: как вы, как первый редактор, поевший крабов, научились использовать node.js в работе?

Примечание. Внешний фреймворк Futu теперь перенесен на vue.js. Но это не повлияет на понимание каждого.

Оригинальная статья взята из блога Futu WEB:Оригинальная ссылка

текст

Случайно мне посчастливилось преодолеть пробел в браузере и по-настоящему испытать Node.js.

Прежде всего, я хотел бы сказать: «Для меня большая честь, что после 2 месяцев напряженной работы появился первый проект Node.js». Весь проект был выполнен достаточно гладко.

Все просто: то, что делает Node.js, — это уровень доступа.

Это произошло по причине

Технологические инновации переднего плана меняются с каждым днем, и разработка переднего плана неотделима от Node.js. Большинство проектов теперь используют отдельные интерфейсную и серверную архитектуру: серверная часть предоставляет интерфейс, а клиентская часть отрисовывает данные через данные интерфейса. Но сейчас логика фронтенд-кода становится все сложнее, а сценариев — все больше. Стоит подумать, подходит ли эта архитектура для всех сценариев приложений. Появление большого передка — всего лишь попытка. Попытка справиться с различными сценариями приложений через доступ к Node.js.

Будь то отдельный человек или команда, технологические инновации просто необходимы. Это проблема, с которой сейчас сталкивается наша команда, поэтому кто-то должен сделать этот шаг. И мне также очень повезло быть первым, кто съел крабов.

инициатор

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

Руководитель группы сказал: «Разве команда не будет проводить технический отбор? Возможно ли использовать Node.js в качестве уровня доступа для этого проекта?».

После тщательного рассмотрения я ответил: «Все в порядке». (Не беспокойтесь о 3721, давайте поговорим об этом. 😄)

Возьмем фразу моего босса: «Если технология не работает, бесполезно об этом говорить».

Предыстория: на самом деле команда всегда уделяла большое внимание Node.js, включая меня. Раньше я интерпретировал и исследовал исходный код Node.js. Группа инфраструктуры также проводила исследования технической среды Node.js, надеясь создать интегрированную структуру проекта, подходящую для командной разработки.

Поэтому я верю: возможность всегда позаботится о подготовленных.

Вот так и начался мой путь в Node.js.

Все начинания трудны

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

Я примерно перечислил несколько крупных направлений:

1. Какова общая архитектура уровня доступа Node.js?
2. Для чего используется фронтенд-технология?
3. Как заниматься фронтенд-инжинирингом?
4. Как работает проект в разных средах (общие среды: разработка, тестирование, производство)?
5. Как сделать фронтенд-автоматизацию?
6. Модульное тестирование?
7. Стиль кодирования?
8. Как Node.js подключается к серверу?
9. Что мне делать для ведения журналов, отчетов, доступа к службе входа в систему, проверки разрешений и т. д.?
10. Как проект будет выпущен онлайн?
11. Как обеспечить стабильность сервиса, когда он онлайн?
12. Как отладить проблему?

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

Но в любом случае запустите новый репозиторий git.

Как получить правильную архитектуру проекта

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

Итак, вопрос в том, делаю ли я предварительный дизайн или код?

Здесь я решил сначала закодировать, а затем реконструировать.

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

Вы можете подумать, что все же необходимо предварительное проектирование?

Говорят, что основное внимание уделяется другому: основное внимание уделяется реализации кода, запуску проекта, а затем поиску подходящей архитектуры проекта посредством рефакторинга.

Что касается вопроса о кодировании или дизайне, я позаимствовал предложение из рефакторинга:

«Рефакторинг изменяет роль предварительного дизайна. Без рефакторинга вы должны убедиться, что готовый дизайн правильный, а это слишком большое давление. Это означает, что если вам нужно будет внести какие-либо изменения в исходный дизайн в будущем , стоимость будет очень высокой. Поэтому вам нужно больше сосредоточиться на предварительном проектировании, чтобы избежать будущих изменений. Если вы решите провести рефакторинг, фокус проблемы изменится. Вы по-прежнему выполняете предварительный дизайн, но вам не нужно Выяснить В настоящий момент вам нужно только найти разумное решение.

Насколько сложно преобразовать простое решение в гибкое? Ответ: «довольно легко». --Выдержка из "Рефакторинг - улучшение дизайна существующего кода"

Я действительно не понимаю. Я рекомендую вам проверить это.«Рефакторинг — улучшение дизайна существующего кода»Эта книга.

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

Соображения по выбору технической основы

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

В первую очередь хочу сказать: «Неважно, какой фреймворк используется для фронтенда или бэкенда, я считаю, что этот вопрос нужно рассматривать с точки зрения команды. Ведь это не личный проект. Нельзя сказать, что никто не может поддерживать этот проект, когда меня нет».

Серверная часть Node.js

koa2. Почему не используются такие фреймворки, как koa или express, или почему команда не разрабатывает их самостоятельно.

Node.js v8LTS почти готов. koa был обновлен до версии koa2, нет необходимости использовать слишком старый экспресс. koa2 показал себя за последние два года.На данном этапе команде не нужно тратить много сил на разработку набора собственного фреймворка.Он может изменить свое мышление и сделать интегрированный фреймворк пригодным для командных проектов на основа коа2.

Основываясь на этой инфраструктуре, на данном этапе команде наиболее целесообразно использовать koa2 в качестве основного фреймворка. Особенно в нативной поддержке Node.js v7.6+.asyncиawaitграмматика.

внешний фреймворк

Династия jQuery постепенно распалась. Наступила эра триады angular.js, react и vue. Опять же, исходя из текущей ситуации в команде, был выбран наиболее выгодный angular.js v1.x.

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

Например, когда проект требует от нас рассмотреть вопрос об ускорении рендеринга страницы, мы должны рассмотреть возможность рендеринга сервера; когда сервер находится под большой нагрузкой, мы должны рассмотреть возможность разделения фронтенда и бекенда. Изоморфизм — наиболее подходящий метод кодирования, и react, и vue — хороший выбор.

В рамках нет правильного или неправильного, есть только неуместное.

Как популярный жареный цыпленок, webpack2 также является для меня приоритетом. Что касается того, почему вы не выбрали webpack3. . .

На самом деле это так, я также фактически использовал webpack3 для тестирования, который является этим проектом. Моя мера заключается в том, что сжатие меньше, чем сейчас. В итоге ожидаемого эффекта достигнуто не было, поэтому слияние не производилось.

Обработка рабочего процесса gulp, без проблем. Здесь может быть некоторая путаница, зачем использовать gulp при использовании webpack2? Зачем использовать оба?

На самом деле для этих двух компонентов они не являются абсолютно противоположными. Здесь они дополняют друг друга.

Общая структура интерфейса: angular.js v1.x + webpack2 + gulp.

Babel используется для компиляции внешнего кода.

Основной фреймворк, используемый проектом, как показано на рисунке:

Фронтенд-инжиниринг

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

Затем следует первый вопрос.

Куда поместить исходный код написанной вами части anglaur.js

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

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

webpack

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

Как сделать контроль версий

Существует два типа контроля версий: на основе файлов и на основе хэшей.

На основе файлов это похоже на файл с другим именем файла каждый раз, когда он упакован. Функция, полезная для запуска нескольких версий онлайн.

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

Здесь есть проблема: файловый контроль версий, сложность заключается в упакованном.jsили.cssИмя файла не поддается контролю, поэтому путь к импортированному файлу js или css нельзя жестко закодировать в файле шаблона html. Поэтому при упаковке через веб-пакет мне нужно указать, какой файл шаблона, и завершить введение путей к файлам js или css через подключаемый модуль внедрения файла шаблона веб-пакета.

Другие способы: путем сохранения хеш-параметра возвращаемого значения после упаковки веб-пакета. Это также позволяет управлять версиями на основе файлов.

рабочий процесс глотка

Применение gulp в сочетании с webpack похоже на утку в воде.Задача упаковки webpack является наиболее важной частью потока задач gulp. С учетом упаковки и компиляции все это передается в webpack. Все, что нужно сделать gulp, — это обеспечить правильное выполнение каждой внешней задачи. В том числе, когда выполнять объединение веб-пакетов и что делать после завершения объединения.

Фронтенд-автоматизация

Автоматизация здесь может противоречить тому, что вы могли бы назвать автоматизацией в другом месте. Автоматизация внешнего интерфейса здесь в основном относится к тому, как автоматизировать упаковку и компиляцию кода внешнего интерфейса. На самом деле, есть много процессов, которые можно автоматизировать в проекте.jenkins, в основном используется для автоматического завершения внешней упаковки и компиляции, а затем для упаковки всех файлов, упакованных и скомпилированных webpack, в команду zip..zipдокумент. Потому что упакованные файлы не хранятся в библиотеке.

Здесь нормально сомневаться. Прежде всего, почему бы не включить файлы, сгенерированные упаковкой webpack, в репозиторий git?

Причина очень проста: если какой-либо файл в репозитории git изменится, будет сгенерирован следующий номер версии. Каждый раз, когда webpack упаковывается и компилируется, файлы должны изменяться.Если упакованный файл включен в репозиторий, файл должен быть отправлен для создания номера версии. То есть после того, как я отправлю код в библиотеку git локально, jenkins упакует его, а затем упакованный файл должен быть отправлен обратно в библиотеку git, что эквивалентно тому, будет ли 2 записи отправки для каждой отправки кода. (один для моей собственной отправки, коммит после того, как Дженкинс завершит автоматическую упаковку.). Таким образом, чтобы предотвратить отправку файлов jenkins в кодовую базу git после упаковки, все, что вам нужно сделать, это удалить файлы, сгенерированные webpack, из репозитория.

Но проблема не так проста.Упаковка Webpack не включена в репозиторий.При публикации как публиковать файлы сгенерированные этой упаковкой webpack. Решение здесь состоит в том, чтобы упаковать все файлы, связанные с упаковкой webpack, в один с помощью команды zip.${commitId}.zipПакет (commitId — параметр каждого коммита git можно получить с помощью bash:commitId=$(git rev-parse HEAD)). Таким образом, его можно найти по commitId, когда он будет выпущен.${commitId}.zipЭтот сжатый пакет, а затем распакуйте его в указанное место.

Почему существует 2 задачи по упаковке?

Первый раз — это упаковка веб-пакета, интерфейсный код необходимо упаковать и скомпилировать. Второй раз — упаковка файлов, необходимая для публикации, причина — решение для упаковки файлов webpack, которые не хранятся в библиотеке.

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

Репозиторий git поддерживает добавление хуков. Таким образом, вы можете добавить триггерные события в репозиторий git. Пусть jenkins сделает упаковку автоматически.

Если однажды, когда мне нужно будет написать модульные тесты, я также могу попытаться позволить jenkins помочь мне запустить автоматические тесты. Считает ли это, что я отвечаю на вопрос модульного теста? Ха-ха-ха-ха-ха-ха. . . . . .

Проблема с интерфейсом в основном решена, и теперь проблема переброшена на сервер.

Конфигурация среды выполнения сервера Node.js

Напишите проект, его очень просто запустить, мой файл входа в проектserver/index.js. Его можно запустить, выполнив следующую команду:

node server/index.js

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

Доступ к сервису уровня доступа Node.js, проверка разрешений

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

Доступ к http-сервису

Инициируйте запрос requset через модуль http. На самом деле, в начале я тоже был в недоумении, как запрашивать внутренние службы на уровне доступа, возможно, это то, что я никогда раньше не рассматривал в качестве внешнего интерфейса. Оглядываясь назад сейчас, это то, что произошло. О некоторых вещах может быть очень сложно думать, но, похоже, есть реальный способ сделать это:山重水复疑无路，柳暗花明又一春。ощущение.

Простая реализация кода серверной службы запроса уровня доступа Node.js:

exports.example = async (ctx)=>{
  let options = {
    port: 80,
    hostname: 'www.test.com',
    method:'GET',
    path:'/api/getuser?token=document.cookie.token'
  };
  let getData = function (){
    return new Promise((resolve , reject)=>{
      let request = http.request(options , (socket)=>{
        let data = '';
        console.log('status: ' , socket.statusCode , socket.headers);
        socket.on('data' , (chunk)=>{
          data += chunk;
        });
        socket.on('end' , ()=>{
          console.log('server call back get data: ' , data);
          return resolve(data);
        });
        socket.on('error' , (e)=>{
          return reject(data);
        });
      });
      request.end();
    });
  }
  ctx.body = await getData();
}

Я не рассматривал способ https здесь, потому что https построен на SSL/TLS, то есть требуется закрытый ключ, открытый ключ и сертификат CA. Хотя сертификат ЦС может быть выдан сам по себе, он должен быть установлен на компьютере, чтобы он работал. Если вы заинтересованы в выпуске собственного сертификата CA для https, вы можете прочитать эту статью:Самозаверяющий сертификат ЦС HTTPS.

Что нужно сделать внутреннему серверу (PHP/JAVA...), так это проверить, есть ли у вызывающей стороны разрешение на использование функции в зависимости от того, являются ли параметры запроса законными и полными. Таких случаев предостаточно, например, использование сторонних сервисов.

Проверка от малого к числу

Вполне возможно, что простейшая проверка параметра не умеет его проверять. Это связано с языком javascript и образом мышления внешнего интерфейса. Когда я начинал, было то же самое, и мне было странно писать код.

На самом деле это простой пример, чтобы проверить допустимость значения типа Number во внешнем интерфейсе, я обычно передаю:

num = typeof num === 'number' && num === num && num !== Infinity ? num : 0;

Нет проблем с таким мышлением и логикой во внешнем интерфейсе, но неудобно писать это на уровне доступа Node.js. Итак, чтобы изменить мой образ мышления:

num = Number.isFinite(num) ? num : 0;

Как бы мала ни была проверка параметра, я должен серьезно об этом подумать. Пришло время изменить свое мышление и принять во внимание, что гораздо лучше использовать нативный JavaScript, чем писать его самостоятельно.

проверка разрешений

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

Управление разрешениями здесь чрезвычайно важно. Лучше всего обслуживать функции, связанные с разрешениями.

Ощущение миссии только началось! ! ! ! !

Развертывание проекта идет онлайн

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

pm2

После того, как проект разработан очень качественно, по сути, настоящая миссия проекта только началась, как обеспечить стабильную работу сервиса онлайн и обеспечить высокую доступность. Делать это нужно с помощью других компонентов. использоватьpm2Управление действительно хорошее решение.

сначала черезnpm install -g pm2установить.
После завершения установки вы можете настроить pm2 в проекте.

Случай:

//test.config.js
'use strict';
//pm2配置文件
module.exports = {
    apps:[{
        name : 'test',
        script: './server/index.js',//应用入口
        cwd: './',
        instances : 1,
        watch : ['server'],
        env: {
            'NODE_ENV': 'development',
        },
        env_production: {
            'NODE_ENV': 'production',
        },
        exec_mode : 'cluster',
        source_map_support : true,
        max_memory_restart : '1G',
        //日志地址
        error_file : '/data/logs/pm2/test_error.log',
        out_file : '/data/logs/pm2/test_access.log',
        listen_timeout : 8000,
        kill_timeout : 2000,
        restart_delay : 10000, //异常情况
        max_restarts : 10
    }]
};

Затем вы можете запустить его с помощью команды:

pm2 start test.config.js

nginx

Nginx — это очень легкий HTTP-сервер, написанный русскими, Nginx, который произносится как «engine X», — это высокопроизводительный HTTP-сервер и обратный прокси-сервер. настройка nginx также важна,80Есть только один порт, поэтому мне нужен nginx для его переадресации.

Например следующий случай:

upstream test_upstream {
    server 127.0.0.1:6666;
    keepalive 64;
}
server{
    listen 80;
    server_name www.test.com;
    client_max_body_size 10M;
    
    index index.html index.htm;
    error_log /data/nginx/log/error_www.test.com.log;
    access_log /data/nginx/log/access_www.test.com.log combined;
 
    location / {
        proxy_store off;
        proxy_redirect off;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Remote-Host $remote_addr;
        proxy_set_header X-Nginx-Proxy true;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_http_version 1.1;
        proxy_pass http://test_upstream/;
        proxy_read_timeout 60s;
    }
}

Порт, на котором запускается проект, является родным6666порт, но я не могу сказать доступwww.test.comОн также имеет номер порта сзади. В это время, когда nginx вступает в игру, имя домена доступа без порта по умолчанию использует порт 80, а nginx используется в качестве обратного прокси-сервера для обслуживания меня.6666порт.

вот немногоpostпо запросуclient_max_body_sizeНастройка параметра напрямую влияет наdataразмер.

Журнал, отчет, эксплуатация и техническое обслуживание

Состояние проекта будет отражено в журнале и отчете. Мне просто нужно каждый день заглядывать в лог и видеть представление, чтобы получить общее представление о том, как работает проект в этот день. Без этих вспомогательных функций глаза будут чернеть, и вы не будете знать, что произойдет.

стиль кодирования

Стиль кодирования соответствует стандартам синтаксиса eslint. используя последниеasync/awaitиimportграмматика.

код отладки

Node.js уже поддерживает отладку кода Node.js прямо в chrome, просто добавьте его при запуске проекта--inspactпараметр.

node --inspect server/index.js

Скопируйте URL-ссылку в красном поле выше, чтобы открыть ее в Chrome, затем нажмитеstartПосле этого зайдите на страницу еще раз, можно нажать, когда нужно сделать паузуstop, чтобы выполнить анализ кода.

Суммировать

Как новичок, я могу только сказать, что Node.js действительно может быть утиной в воде на уровне доступа, и ключевым моментом является возможность. Если не считать уровня доступа Node.js, полностью возможен интерфейсный инжиниринг. Однако добиться изоморфного рендеринга на сервере невозможно, если только он не взаимодействует с одноклассниками бэкенда; используя слой доступа Node.js, фронтенд сможет с легкостью справиться с некоторыми сложными проблемами, а бэкенд конечная служба получит более глубокий уровень.Защита не означает, что серверная служба сталкивается с прямыми атаками, потому что впереди есть дополнительный слой уровня доступа Node.js.