Начинаем серию статей, которая позволит увеличить скорость и качество разработки приложений. Данная серия статей будет содержать как переводы статей других пользователей сети, так и мои собственные изыскания в этом направлении. Прошу относиться к ним скептически и не принимать на веру безоговорочно, так как жить с этим потом Вам.
Первой статьёй этого цикла я выбрал статью John Vandivier, которая повествует нам о том что такое ORM, какую ORM выбрать в 2018 году на Javascript, и почему это важно. Давайте посмотрим что он пишет и попробуем понять, как это поможет нам приблизиться к цели.
Что такое ORM и почему это так важно?
В этой статье мы рассмотрим ORM (Object-Relational Mapping) решения на JavaScript и попытаемся найти идеальное решение, которое подходит нашим требованиям.
ORM решения полезны для облегчения разработки API (application programming interface). У пользователя есть конкретные потребности, которые определяют модель данных. Когда-то давно, архитектура данных реализовывалась и управлялась при помощи языков сценария самой базы данных, таких как SQL, PL/SQL, Transact-SQL и других. Следующим звеном такой архитектуры являлась дополнительная библиотека, которая позволяет выполнять CRUD | https://ru.wikipedia.org/wiki/CRUD действия над базой данных.
ORM работает как API верхнего уровня для выполнения CRUD, и на сегодня качественные ORM позволяют нам инициализировать архитектуру данных непосредственно кодом приложения. Так же предоставляет возможность в коде приложения легко использовать сложную обработку данных, очистку и прочие операции. Хотя существуют специальные инструменты извлечения, преобразования и загрузки ETL, те же самые задачи ETL могут быть легко реализованы средствами ORM.
Реализация ETL задач кодом, позволяет системе легче интегрировать данные из самых разных источников. Базы данных SQL разных типов, данные NoSQL, данные файловой системы и данные сторонних производителей могут быть интегрированы на одном языке с помощью JavaScript ORM»
Наконец, ориентированный на код контроль данных также позволяет системе реализовывать использование данных во время выполнения или в процессе сборки и гибко адаптировать использование в процессе разработки по мере необходимости.
Иными словами, ORM повышают производительность труда разработчиков, предоставляя высокоуровневый API на одном языке с функциональностью, которая традиционно требует нескольких различных инструментов и наборов навыков. Меньшие потребности в навыках, инструментах и часах способствуют увеличению прибыли проекта. Непредвиденные требования и сроки проекта лучше подготовлены благодаря гибкой настройке данных сборки и времени выполнения.
Сразу бросаются в глаза слабые доводы в пользу ORM. Честно говоря, после прочтения вообще возникает ощущение, что ты пошёл не в ту сторону. Но нет друг мой, мы идём верным путём, просто у человека странное представление о ETL задачах, ETL инструментах и областях их применения. Хочется всё же дать более точную мотивацию для Вас, что бы не отпугнуть от исследований в этом направлении.
Где же профит ORM, если не в ETL?
Модели данных
Обычно архитектурная цепочка клиент-серверного приложения баз данных выглядит так:
На каждом из этих архитектурных узлов есть модель данных и нам необходимо выполнять над ней различные операции добавлять, удалять, получать аналитические выборки, архивировать, связывать с другими моделями данных и прочее и так далее. Из-за особенностей каждого узла, мы имеем зоопарк инструментов для выполнения всех этих операций. К примеру, значение по умолчанию можно задать как при создании таблицы базы данных, используя возможности базы данных, так и при определённой операции CRUD. Это увеличивает сложность, модели данных меняются непредсказуемым образом, реализовываются не очевидные схемы их взаимодействия и прочие радости разработки, которые особенно остро проявляются при разделении зон ответственности. Наличие архитектуры данных в одной голове более или менее сглаживает острые углы, но если разработчик не имеет внутреннего позыва создавать стройные решения, это всё превращается в гАвно, которое крайне сложно поддерживать.
База данных
«У нас новый заказчик, и нам нужно реализовать такое же приложение, только в качестве базы данных использовать …..» Это слышать просто больно. Особенно если один из разработчиков возомнил себя экспертом той или иной базы данных. Так как именно он в полной мере использует все возможности базы данных. Какой там переехать на другую базу данных, на версию бы ниже без проблем накатить. Конечно, не стоит забывать, что есть 5% приложений, которые ну вот никак не могут работать на другой базе данных ввиду определённых особенностей, но тут и у заказчика нет возможности выбора.
API
Как часто вы ловили себя на мыслях, что пишите по сути одно и тоже API каждый божий раз и при этом меняется только Name? Если вы один из этих, то добро пожаловать в клуб. Каждый из нас, рано или поздно, пытается написать свою систему генерации API, но как правило всё это заканчивается только на уровне заготовки кода или недоделанного фреймворка со своими женщинами с низкой социальной ответственностью самого паршивого пошива.
Подобьём итог по профиту
На мой взгляд, пункты указанные выше, и служат причиной появления ORM фреймворков вообще. Если сформулировать их ёмко и в стиле революционных слоганов, то звучать эти пункты будут так:
- «Даёшь одну модель данных во всех архитектурных узлах с описанием связей»
- «Свободу модели данных от марки базы данных»
- «Даешь возможность генерации базовых API каждой модели данных»
Надеюсь теперь стало понятнее. Давайте продолжим изучение статьи.
Предпочтительные возможности ORM
Конкретный контекст проекта, приводящий к этому обзору ORM, требует реализации передового универсального JavaScript-приложения, подобного CMS.
Ультрасовременные универсальные JavaScript-фреймворки в основном представлены в трех вариантах: Angular, React и Vue. То есть Angular Universal, Next и Nuxt.
Node изначально поддерживает операции с файловой системой, поэтому требования к данным системы управления контентом составляют предпочтение широкой поддержке баз данных. Всего учитываются следующие требования:
1) Поддержка Mongo и MySQL, с предпочтением поддержки дополнительных опций
2) Интеграция с Webpack
3) Интеграция с Express
4) Минимальный удар по производительности во время выполнения
5) Интуитивно понятный синтаксис
6) Дополнительные функции
7) Высокое соотношение Github звёзд к рейтингу вопросов
8) Активно поддерживается без сбоев сборки или устаревших зависимостей
Добавим только:
- Генерация базовых API
- Поддержка Oracle, MsSql, Postgresql
Далее мы пропустим блок анализа от John Vandivier и сразу пойдём к источнику, который он использовал. Думаю сложностей, что бы разобраться «what is what», не будет.
Заключение
Итоги отражают общую полезность каждого решения. Лучшие 5 результатов были:
Loopback Waterline Mongoose TypeORM Sequelize
Комбинация специфических потребностей проекта, опущенных факторов и личных предпочтений приводят к трем лучшим выборам. Waterline тесно интегрирован с платформой Sails, а Mongoose поддерживает только MongoDB. Sequelize и NodeORM2 ограничены SQL и им не хватает генерации API. Благодаря синтаксису TypeScript TypeORM прекрасно интегрируется с проектом Angular.
Как разработчик, я рекомендую создавать прототипы более чем одного решения, чтобы определить настоящего победителя. Лучшие 3 решения, которые все являются кандидатами на прототипирование: Loopback TypeORM Caminte
Я представил эту информацию другим разработчикам проекта, и как команда мы решили сначала попробовать TypeORM. Перепроверьте позже для ретроспективы!
Что вы думаете об этом результате? Оставьте комментарий или поделитесь своими мыслями с этим сравнением Slant.
Этот вывод справедлив и для нас. Правда мы не будем рассматривать camintejs, так как проект плохо развивается.
Остаются:
- Loopback
- TypeORM
Если вы читали статью в оригинале, то уже прочитали и продолжение, а если нет, прочитайте.
Что дальше?
Внедрение ORM в стек технологий, которые используется в разработке, вероятно даст достаточно хороших прирост по скорости и качеству. Следующие статьи будут посвящены реализации простого проекта с использованием Loopback. К TypeORM мы всё же вернёмся, но чуть позже.