В эпоху веб-разработки 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 г.