Противостояние «легкому» бэкэнду nodejs

На домашней странице hapipal.com мы стараемся произвести незабываемое первое впечатление, когда мы активно поднимаем тему, которая, как мы знаем, вас интересует: облегчит ли мне этот инструмент?

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

«Легко» - это не совсем то, что мы хотим.

Это не значит, что мы думаем, что приятеля трудно научиться - как раз наоборот! (Насколько мы можем судить, люди находят это восхитительным.) Мы просто признаем, что мы вероятно не решили все самые сложные проблемы, которые стоят перед вами, когда вы приступаете к созданию своей следующей веб-службы. . Вам придется иметь дело с бесчисленным множеством проблем - иногда с серьезными сквозными проблемами всего вашего приложения, - которые среда JS / инструментарий имеет привычку группировать в широкие термины: «производительность», «безопасность», «в реальном времени» « бизнес-требования". И мы не можем легко называть эти вещи.

Фактически, мы разработали hapi pal таким образом, чтобы признать трудности, которые ждут вас впереди: в основном, приятель готов уйти с вашего пути, когда придет время для тяжелой работы. Давайте объясним!

«Создайте готовую к работе серверную часть в реальном времени за считанные дни»

Мы привыкли видеть утверждения, подобные этой (👆), как тезисы для сообщений в блогах и учебных пособий, как зацепки на домашних страницах фреймворков, в сообщениях в Twitter, в спорных комментариях Hacker News и т.д. беспокойство по поводу выбора правильного инструмента для работы, поскольку мы кружимся в иногда головокружительном море инструментов и фреймворков JS.

Если я опробую этот фреймворк, и на создание приложения у меня уйдет больше недели, это потому, что я делаю что-то не так? 😓

Будьте уверены: если на заполнение вашего приложения уходит больше дней, это не обязательно означает, что что-то не так с выбранными вами технологиями или подходом. В зависимости от внутренней сложности проблемы, которую вы обслуживаете, гарантий согласованности данных, требований безопасности вашего бизнеса / страны / отрасли, соглашений об уровне обслуживания, которые ваш API должен соблюдать в отношении доступности и скорости реагирования, вашего бюджета операций, количества ожидаемых одновременных пользователей и масштабов притока трафика, размера вашей команды и т. д. было бы совсем не странно, если бы проект длился месяцами или дольше в любой структуре. И если термин «готовый к производству» не включает в себя обширный перечень проблем, приведенных выше, о чем мы вообще говорим?

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

Утечки абстракции

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

Общее определение для этого вы найдете в википедии: дырявая абстракция - это абстракция, которая раскрывает подробности и ограничения своей базовой реализации для своих пользователей, которые в идеале должны быть скрыты. Я бы предпочел исправить это, потому что я думаю, что эти утечки идут в обоих направлениях. Если библиотека требует изменений в своей реализации, чтобы код приложения мог обойти ее ограничения, это тоже утечка. Например, сколько раз вы пытались использовать какую-либо конкретную функцию MySQL или PostgreSQL только для того, чтобы обнаружить, что она вам полностью запрещена, пока она не будет реализована в выбранной вами ORM? Это не ORM с отсутствующими функциями - это утечка абстракции.

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

Здесь необходимо найти баланс между жесткой абстракцией с минимальными утечками, которая не представляет особой ценности, и массивной, но неплотной абстракцией, которая обеспечивает большую ценность только в пределах своих возможностей. Библиотеки, которые утверждают, что делают вашу жизнь «легкой» или «быстрой», имеют тенденцию заканчиваться одной из этих «массивных, но протекающих» абстракций. Причина здесь не столь спорна: простая оптимизация подразумевает наличие разнообразия функций, а не возможности настройки и точной настройки. Излишне говорить, что мы были как бы одержимы этим балансирующим действием при создании хапи-пала, и мы кое-что узнали на этом пути.

Как приятель занимает позицию

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

  • haute-couture - это не сам по себе плагин hapi. Мы хотим, чтобы вы могли использовать haute-couture для создания ваших плагинов hapi из файлов, но также хотим, чтобы вы могли свободно писать и запускать любой другой код плагина, который может вам понадобиться - например, если hapi вводит новую функцию, которую haute-couture не поддерживает сразу. Поэтому мы позаботились о том, чтобы haute-couture можно было использовать в качестве подпрограммы любого плагина, и вы могли написать весь необходимый код!
  • ORM возражений на самом деле просто великолепный конструктор SQL-запросов. Выбирая для себя уровень доступа к данным, мы хотели отойти от массивных абстракций, которые традиционно вводят ORM. Возражение обеспечивает замечательный баланс, в котором основное внимание уделяется первоклассной поддержке функций хранилищ данных SQL (прозрачное составление с помощью конструктора запросов knex), а не попыткам создания универсального интерфейса для работы с записями. Это позволяет нам перейти к деталям и работать в тесном контакте со всеми необходимыми сложными вещами, такими как транзакции, типы столбцов со специализированными индексами (например, tsvectors, JSONB и геопространственные типы), агрегации, семантика соединения. и т.д. Возражение делает работу с отношениями модель / таблица, и эти важные функции нашей СУБД кажутся органичными.
  • Schwifty подключает модели к соединениям с базами данных для вас… если вы не сделаете это в первую очередь. Schwifty - это плагин hapi, интегрирующий Objection ORM в качестве уровня модели для вашего приложения. Он учитывает границы плагинов hapi, позволяя настраивать различные соединения с базами данных для ваших моделей для каждого плагина, например чтобы справиться с ситуацией, когда вы составляете несколько плагинов hapi-приложений в одно развертывание. Мы считаем это очень гибким, но мы также признаем, что могут быть более сложные варианты использования: что, если у кого-то есть одна устаревшая users таблица, которая живет в базе данных, отличной от всех других его моделей? В этом случае не беспокойтесь - schwifty разработан, чтобы уйти с вашего пути, если он видит, что вы вручную подключаете db-соединения к данной модели.
  • содержимое файлов шаблонов, созданных с помощью hpal CLI, полностью настраивается. В интерфейсе командной строки hpal есть команда hpal make, которая позволяет создавать файлы шаблонов для новых маршрутов, моделей, сервисов, стратегий аутентификации и т. д. имеют разумное содержимое по умолчанию для этих файлов, но, возможно, вы захотите добавить немного изящества или сделать его более соответствующим вашему стилю кодирования. Содержимое файла можно настроить, просто добавив в .hc.js файл поправки от кутюр со свойством example, что означает, что вы можете заставить hpal make вести себя так, как вам нравится! Аналогичным образом вы можете использовать поправки от кутюр, чтобы изменить значение каталогов в вашем проекте: возможно, вы хотите, чтобы models/ содержал модели Mongoose, а не модели возражений, например. Мы будем рады помочь вам, чтобы вы могли работать в соответствии со своими требованиями.

Во вселенной друзей есть еще множество примеров, но это несколько важных, которые приходят на ум. Выше упомянуты несколько модулей / библиотек. Все эти библиотеки также предназначены для работы и имеют смысл полностью сами по себе, но если вы ищете более интегрированный опыт, мы настоятельно рекомендуем проверить шаблон приятеля, который устанавливается для авторских приложений hapi с помощью первоклассные инструменты отладки hapi , набор тестов и линтер, стратегия конфигурации и развертывания, а также множество разновидностей , например для интеграции schwifty и Objection ORM, пользовательского интерфейса Swagger, шаблонных представлений и т. д. Не говоря уже об очень гостеприимном сообществе хапи-час (найдите нас в #hapipal!). Мы будем рады видеть вас.

Ваши друзья,

Девин (@devinivy) и дружная команда

Важно P.S.!

Мы хотим прояснить, что хапи-приятель здесь не для того, чтобы указывать пальцем! Никакое содержание этого сообщения не должно использоваться для того, чтобы пристыдить разработчиков ПО с открытым исходным кодом за их «дырявые абстракции» или бессовестное продвижение «быстрого и легкого». Вы всегда обязаны понимать абстракции, подходы и ограничения зависимостей, которые вы вводите в свое приложение. Большое сообщество JavaScript имеет давнюю традицию рекламировать библиотеки как быстрые / простые решения сложных проблем, и мы одновременно подвержены шумихе, беспокойству по поводу инструментов, «усталости от JS», поскольку мы сами являемся инструментами этого. Мы просто надеемся признать эти проблемы, систематически противостоять им и написать несколько замечательных инструментов hapijs, пока мы этим занимаемся. 💞