В эпоху веб-разработки 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? Компромисс - это увеличение времени и более сложная ремонтопригодность, потому что, когда команда выбирает проект с открытым исходным кодом, они могут использовать других участников для обслуживания. Это не тот случай, когда одна и та же команда выбирает внутреннюю систему с закрытым исходным кодом, которая поддерживается только этой компанией.
В конце концов, вам нужно думать самостоятельно и принимать собственные решения. Ваше целевое приложение может фокусироваться и / или нуждаться в разных вещах. В этой статье можно выделить только определенные факты. И даже это, скорее всего, субъективно, как и почти все, что написано или сказано человеком. 😉
Hapi.js
Хапи (для сервера 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
npm: https://www.npmjs.org/package/hapi
Sails.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'
}
Как видите, абстракция - то есть логика маршрутов находится где-то еще - сохраняет файл routes.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 загрузок в минуту за последний месяц на момент написания этой статьи (март 2018 г.).
Сайт: http://sailsjs.org
GitHub: https://github.com/balderdashy/sails/
npm: 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 за прошлый месяц в качестве индикатора тенденций, относитесь к социальному доказательству с долей скептицизма. Это не всегда точно, потому что чем дольше фреймворк существует и чем лучше он продвигается, тем больше будет статистика. И наоборот, статистика улучшенной библиотеки может быть ниже только потому, что этот модуль новее.
Я не собираюсь защищать какую-либо конкретную структуру. Очевидно, что они лучше, чем написание и поддержка ваших собственных библиотек или использование в большинстве случаев простого Express.js. Я рекомендую использовать их, исходя из их плюсов и минусов, так, как это подходит для вашего конкретного проекта.
Не стесняйтесь хлопать в ладоши, если считаете, что это стоит прочитать!
Первоначально опубликовано на 101node.io.
✉️ Подпишитесь на рассылку еженедельно Email Blast 🐦 Подпишитесь на CodeBurst на Twitter , просмотрите 🗺️ План развития веб-разработчиков на 2018 год и 🕸️ Изучите веб-разработку с полным стеком .