Предисловие

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

Как и все веб-фреймворки, Node предоставляет самое необходимое для приложения - объекты запросов и ответов, методы для управления HTTP-запросами, возможность взаимодействия с базой данных с помощью популярных инструментов ORM, надежные библиотеки развертывания в производственной среде и многое другое. «Чистые» Node-приложения потрясающе быстры, но им не хватает вспомогательного программного обеспечения промежуточного слоя, маршрутизации и подключаемых модулей, которые сокращают объем кода, необходимый для современного веб-приложения.

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

Что такое hapi.js?

hapi.js (сокращенно от Http-API, произносится как happy и также известен как hapi) - это платформа с открытым исходным кодом для разработки масштабируемых веб-приложений. . Один из основных вариантов использования hapi - создание REST API. Вы можете создавать серверы интерфейса прикладного программирования (API), веб-сайты и прокси-приложения HTTP с помощью hapi.js.

Он был создан мобильной командой в Walmart Labs во главе с Эраном Хаммером для обработки трафика на такие мероприятия, как Черная пятница, один из самых загруженных дней для покупок в Интернете в США. календарь.

Почему так много шума вокруг хапи?

Чтобы дать вам представление о том, почему сообщество разработчиков считает hapi настолько надежным и надежным, он смог успешно управлять миллионами торговых транзакций, возвратом и многим другим в Walmart во время Черной пятницы, возможно, самого загруженного дня розничных покупок в году. в США

hapi смогла обработать весь мобильный трафик Walmart в Черную пятницу с помощью примерно 10 ядер ЦП и 28 ГБ ОЗУ (конечно, мы использовали больше, но большую часть времени они простаивали при нагрузке 0,75%). Это потрясающий трафик, проходящий через ОЧЕНЬ мало ресурсов. - Эран Хаммер

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

Вот список некоторых великих имен, которые сегодня используют hapi в производстве:

Строительные блоки

На протяжении всего пути Walmart по перестройке уровня своих мобильных сервисов и работе с другими фреймворками они осознали, что определенные ценности имеют жизненно важное значение для создания приложений на Node, чтобы код оставался интуитивно понятным, поддерживаемым и масштабируемым. В результате команда разработчиков hapi сосредоточилась на следующих концепциях:

  1. Строительная ценность, а не инфраструктура
  2. Конфигурация лучше кода
  3. Отделение бизнес-логики от транспортного уровня
  4. Открытый исходный код и ориентированный на сообщество
  5. Экосистема (Мнения, плагины)
  6. Маленькие модули

Плагины

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

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

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

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

Экспресс против хапи

И Express, и hapi стремятся быть очень гибкими, простыми и расширяемыми. Это сходство означает, что у обоих есть простые в использовании API, они имеют модульную структуру и могут поддерживать ваше приложение, когда оно потенциально становится очень большим. Кривая обучения этим фреймворкам, поскольку они довольно просты, невелика, в отличие от более самоуверенных фреймворков, таких как Meteor. Если вы переходите с Express, вы сможете быстро забрать Hapi, и наоборот.

Однако между этими двумя концепциями есть некоторые философские различия.

  • Hapi.js по умолчанию включает больше «батареек», чем Express. Например, при синтаксическом разборе полезной нагрузки из форм в запросы «POST» в Express вы должны включить body-parser промежуточное ПО. Затем вы используете это для анализа полезной нагрузки POST и использования данных от пользователя. С другой стороны, с Hapi вам не понадобится промежуточное ПО. Полезная нагрузка анализируется за вас самой фреймворком, и вы можете получить доступ к полезной нагрузке непосредственно в объекте запроса. Таких маленьких удобств на Хапи предостаточно.
  • «Промежуточное ПО» - это имя, данное программным модулям, которые последовательно обрабатывают HTTP-запросы, прежде чем конечный результат будет возвращен пользователю в ответе. Express позволяет подключать промежуточное ПО для обработки каждого запроса. Однако Hapi работает с плагинами, которые обеспечивают функциональность промежуточного программного обеспечения.
  • Обслуживание статических файлов в Hapi и Express очень похоже. Hapi использует плагин Inert, тогда как Express использует встроенное промежуточное ПО express.static.

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

Жизненный цикл запроса

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

Чтобы продемонстрировать этот процесс в действии, рассмотрим типичный жизненный цикл запроса hapi:

Здесь вы можете видеть, что разработчику предоставляются хуки в виде обработчиков и расширений для реализации логики. хапи в основном остается вне того, что попадает в эти крючки. По мере роста сложности проекта растет и потребность в разделении функциональности и распределении нагрузки. Сервер Hapi становится внешним интерфейсом (посредством API или пользовательского интерфейса), в то же время используя широкий спектр других технологий для разбивки монолитов бизнес-логики на более мелкие части (которыми, в свою очередь, может управлять Hapi). ).

хапи 16 v 17

быстрое примечание о том, какую версию вам следует использовать. Произошел существенный сдвиг в структуре с 16 на 17 (последняя версия - v18.x), где она перешла от использования обратных вызовов к async / await. В этом и следующем блоге (со стартовым набором) будет использоваться hapi v18.

Простой сервер

Простой сервер api на основе hapi может быть закодирован в несколько строк кода следующим образом:

Сохраните это как server.js и запустите сервер с помощью команды:

node server.js

Теперь вы обнаружите, что если вы зайдете на http: // localhost: 3000 в своем браузере, вы увидите текст Hello, world!, а если вы зайдете на http: / / localhost: 3000 / node вы увидите Привет, узел! .

Часть 2

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

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

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

Знаете ли вы, что можете дать до 50 хлопков в ладоши?