В эпоху веб-разработки Node.js наиболее широко используется в качестве серверной среды, Node.js — это среда ввода-вывода, управляемая событиями, построенная на основе движка JavaScript V8, она позволяет выполнять Javascript на стороне сервера и использует невероятно быстрый движок V8, разработанный Google для браузера Chrome.

Основная философия node.js:

  • Неблокирующий ввод-вывод — каждый вызов ввода-вывода должен принимать обратный вызов, который будет выполнен, как только придет ответ, будь то получение информации с диска, сети или другого процесса.
  • Встроенная поддержка наиболее важных протоколов — HTTP, DNS, TLS.
  • Низкий уровень: не удаляйте функции, присутствующие на уровне POSIX. Например, поддерживайте полузакрытые соединения TCP.
  • Потоковая передача всего — никогда не применяйте принудительную буферизацию данных.

Node.js отличается от клиентского Javascript тем, что он удаляет определенные вещи, такие как манипулирование DOM, и добавляет поддержку событийного ввода-вывода, процессов, потоков, HTTP, SSL, DNS, обработки строк и буферов, а также дополнений C/C++.

Давайте пропустим скучное общее введение в бинго и перейдем к сути дела — сравнению двух популярных фреймворков Node.js?

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

  • Лучшие практики и шаблоны: независимо от того, является ли фреймворк самодельным или предоставляет четкие шаблоны для использования.
  • Конфигурация: насколько легко настроить фреймворк.
  • Соглашение: существует ли соглашение, которому следует следовать, если это предпочтительный маршрут?
  • Горизонтальное масштабирование: насколько легко масштабировать приложения, созданные с помощью этой платформы.
  • Тестирование: Как протестировать приложение.
  • Скаффолдинг: сколько разработчикам приходится писать код вручную по сравнению с использованием встроенных генераторов кода.
  • Мониторинг: Как контролировать приложение
  • Послужной список: насколько проверена структура, т. Е. Кто ее поддерживает и насколько хорошо она поддерживается.
  • Интеграция: насколько богата экосистема плагинов/коннекторов.
  • ORM/ODM: есть ли объектно-реляционный/документный сопоставитель.

Хотя производительность важна, она зависит от требований и бизнес-логики конкретного проекта. Выполнение полноценных эталонных тестов — нетривиальная задача.

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

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

Хапи.js

Hapi (для HTTP API-сервера) поддерживается Walmart Labs, поэтому он явно имеет подтвержденный опыт обслуживания большого трафика в производственной среде (#nodebf- Node Black Friday ).

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

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

Другие плюсы включают в себя:

  • Архитектура на основе плагинов: выбирайте модули для масштабирования вашего приложения.
  • Кэширование: повышение производительности
  • Ориентация на конфигурацию: используйте файлы конфигурации
  • Богатая функциональность веб-сервера: ускорьте разработку
  • Подробная документация по API: быстро изучите фреймворк
  • Проверенный послужной список и поддержка: получите поддержку от сообщества и участников
  • Поддерживает микросервисы: улучшите разделение бизнес-логики и масштабируемости с помощью Seneca и плагина Chairo.

Некоторые из недостатков Hapi включают в себя:

  • Разработчики должны самостоятельно разобраться со структурой кода
  • «Привязывает» разработчиков к использованию модулей и плагинов, специфичных для hapi, таких как catbox, joi, boom, tv, good, travelogue и yar; и которые не совместимы с Express/Connect
  • Конечные точки создаются вручную
  • Рефакторинг выполняется вручную
  • Конечные точки тестируются вручную

Отсутствие встроенного ORM/ODM само по себе не является минусом, поскольку не всем корпоративным приложениям нужна база данных. Например, уровень оркестрации, который извлекает данные из устаревшей службы SOAP, не нуждается в драйвере MongoDB с моделями и схемами, поскольку он получает данные из служб и может кэшировать данные в Redis.

Что касается кода, то Hapi отличается от других фреймворков в этой статье, потому что он не был построен поверх Express. Эта архитектура требует дополнительного обучения для разработчиков, знакомых с Express (как и большинство из нас), потому что они могут применить свои навыки Express.js в Hapi.

Простой сервер Hapi с двумя маршрутами GET / и GET /name будет выглядеть так:

'use strict'; 
const Hapi = require('hapi'); 
// Create a server with a host and port 
const server = Hapi.server({ host:'localhost', port:8000 }); 
// Add the route 
server.route({ 
  method:'GET', 
  path:'/hello', 
  handler: (request,h) => { 
    return 'hello world'; 
  }}); 
// Start the server 
async function start() { 
  try { 
    await server.start(); 
  } catch (err) { 
   console.log(err); 
   process.exit(1); 
} 
console.log('Server running at:', server.info.uri); 
}; 
start();

Для начала просто установите Hapi с npm, как и любую другую зависимость:

npm install hapi --save

Социальное доказательство для Hapi составляет 9 207 звезд GitHub и 722 014 загрузок npm за последний месяц на момент написания этой статьи (март 2018 г.).

Сайт: http://hapijs.com

GitHub: http://github.com/hapijs/hapi

нпм: https://www.npmjs.org/package/hapi

Паруса.js

Sails.js был построен поверх Express.js; поэтому его легче изучать людям, уже знакомым с Express.js.

Sails.js имеет богатую структуру. Вспомните Ruby on Rails (отсюда и название «паруса»). Это позволяет разработчикам создавать конечные точки RESTful API без написания кода. Автоматически сгенерированный код можно позже настроить в соответствии с конкретными потребностями бизнеса.
Sails.js — это среда MVC, которая поставляется с базой данных ORM/ODM Waterline, которая поддерживает различные базы данных.

Sails.js также поставляется со встроенной поддержкой WebSockets с Socket.io и инструментом активов (Grunt). Однако Sails.js позволяет вам выбрать интерфейсный уровень, который часто реализуется с помощью Angular.js, Backbone.js или любого другого внешнего интерфейса.

Хорошие идеи Sails.js:

  • Обеспечивает хорошую организацию кода и чертежи
  • Встроенная поддержка WebSockets
  • Поддерживает различные базы данных
  • Проверка достоверности данных
  • Автоматически сгенерированный код для контроллеров, моделей и маршрутов
  • Множество готовых функций безопасности, например, CSRF и совместимость с Lusca.
  • Встроенная библиотека загрузки файлов
  • Хорошая документация
  • Гибкая и модульная архитектура с хуками и плагинами

Некоторые минусы, такие как:

  • Крутая кривая обучения
  • самоуверенный

Вот пример определения маршрутов в файле config/routes.js проекта Sails.js:

module.exports.routes = { 
 'get /signup': { view: 'conversion/signup' }, 
 'post /signup': 'AuthController.processSignup', 
 'get /login': { view: 'portal/login' }, 
 'post /login': 'AuthController.processLogin', 
 '/logout': 'AuthController.logout', 
 'get /me': 'UserController.profile' 
}

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

Чтобы начать работу с Sails.js, установите его как инструмент командной строки с помощью npm и запустите генератор:

npm -g install sails
Sails.js new sails-test
cd sails-test
Sails.js lift

Результирующий каркасный проект будет иметь следующие папки:

/api : вся логика на стороне сервера, такая как контроллеры, модели, политики, ответы (обработчики запросов) и службы (компоненты многократного использования)
/assets : статические ресурсы, такие как изображения, интерфейсный JavaScript, стили и т. д.
/config : параметры конфигурации, такие как среды, локали, промежуточное ПО
/tasks : задачи сборки Grunt
/views : серверные шаблоны

Социальное доказательство: Sails.js имеет 18 553 звезды GitHub и 79 352 загрузки npm за последний месяц на момент написания этой статьи (март 2018 г.).

Сайт: http://sailsjs.org

GitHub: https://github.com/balderdashy/sails/

нпм: https://www.npmjs.org/package/sails

Вердикт

Я намеренно исключил выбор по умолчанию для создания приложений Node.js/Io.js, Express.js, потому что было бы слишком легко выбрать его из-за отсутствия генераторов кода, организации и встроенной поддержки базы данных. Однако не стоит сбрасывать со счетов Express.js. Это может быть лучшим выбором для быстрого прототипирования или высокоспециализированных проектов. Количество модулей промежуточного программного обеспечения Express.js/Connect огромно. Вот почему вы можете выбрать Sails.js. Они совместимы с промежуточным ПО Express.js.

На данный момент (март 2018 г.) он определенно имеет большой вес в пространстве фреймворка Node.js. В них встроены ORM/ODM и богатые шаблоны, которые сэкономят время разработчиков.

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

Hapi стоит особняком, потому что его архитектура отличается от Express.js по дизайну. Это позволяет более детально контролировать жизненный цикл запросов и ответов.

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

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

Любой вопрос или отзыв? Пожалуйста, оставьте комментарий ниже или свяжитесь со мной в твиттере здесь.

Если вам нравится эта статья. Не забудьте похлопать статье

Подпишитесь на Shailesh Shekhawat, чтобы получать уведомления о моих новых публикациях.

Первоначально опубликовано на сайте shaileshshekhawat.com 18 марта 2018 г.