QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

Универсальные ORM для Node.js — ваш опыт

Я занимаюсь разработкой REST API на Node.js и на самом начальном этапе столкнулся с такой дилеммой: нужно использовать пару баз данных — MySQL либо PostreSQL, и MongoDB, и хочется, чтобы интерфейс работы с моделями был человеческий. Другими словами, нужен ОРМ.

В списке модулей Joyent есть несколько таки «универсальных» ОРМ-ов с драйверами под разные БД. Вопрос — пользовался ли ими кто-либо из вас, и какие есть рекомендации. По ходу скажу, что я начал сам писать под себя подобие ОРМ (по крайней мере похожий интерфейс get, set, save, destroy и т.п., и драйвер под MongoDB с CRUD-методами + find / findAll и т.п.) Но пока писал, подумал, что возможно изначально выбрал неправильный путь, и лучше взять одну из готовых. Поэтому и задаю этот вопрос.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Можешь посмотреть light-orm: github.com/...knyga/light-orm
Очень много чего не умеет, но простой.

А что насчет Mongoose ? кто-нибудь юзал?

да, удобная и приятная, никаких нареканий. помогает держать схему в строгости :)

Приятная пока не нужно сделать что-то посложнее, чем CRUD

Join, group, и много всего. Но понятно, что это не входит в понятие ORM.

Стоит упомянуть, что mongoose это ОРМ для монги, в которой нет join/group, но тем не менее эта ОРМ позволяет удобно использовать aggregation фреймворк и писать запросы любой сложности в монгу при необходимости

Я смотрел на нее. Собираюсь потестировать.

@Alexander — а у вас опыт есть с этой библиотекой?

Да. Для моих целей был вполне приемлемый выбор.

+1 за juggling
но, имхо в ноде это лишнее... да и вообще любые имхо реляционные БД не для её предметной области

А при чем тут реляционные или не реляционные БД? Для Нода то в чем огромная разница?

По ходу скажу, что я начал сам писать под себя подобие ОРМ (по крайней мере похожий интерфейс get, set, save, destroy и т.п., и драйвер под MongoDB с CRUD-методами + find / findAll и т.п.)
От я бы попробовал подкрутить backbone.js, как бы уже известный и простой интерфейс. По ходу, переписать только 1 метод, а не всю обвязку.
«универсальных» ОРМ-ов с драйверами под разные БД.
Я бы поостерегся. Универсально (правильно для разных БД) == медленно.

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

Нет необходимости, по-моему.
по крайней мере похожий интерфейс get, set, save, destroy и т.п.
?
Мне не нужен дополнительный фреймворк, мне нужна просто качественная библиотека.
Для чего?
Если для:
чтобы интерфейс работы с моделями был человеческий.
то бэкбон самое оно. Если вам надо именно для работы с моделями (ОРМ), то есть упростить бизнес-логику.
Но у меня есть подозрение, что вам надо скорее «persistence framework», тогда бэкбон таки немного не в ту сторону.

Нет, именно ОРМ. С примерно описанным интерфейсом.

Использую sequelize — после джанговского, конечно, бедно (

Я его пробовал, очень бедно, согласен. Просто до невозможности неудобно. Было это с год назад, но не думаю, что что-то сильно изменилось.

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

Универсальная в очень ограниченном понимании, естественно. Один интерфейс для MongoDB и MySQL и/или Postgres.

Так что мешает сделать по одному адаптеру для каждой БД реализуя единый интерфейс?

Насчет Node.js не знаю, а на Java юзаю уже лет 10 собственный ORM. И мне пофиг Hibernate и прочие козлища.

Только велосипеды, только хардкор

Велосипеды полезны для здоровья. Почти притча: много лет назад (в моем детстве) у нас во дворе работал сапожник-виртуоз. У него был набор каких-то хитрых инструментов, которые он делал себе сам. Думаю, если бы ему случилось попасть работать на сапожную фабрику, он бы умер через неделю.

У него был набор каких-то хитрых инструментов, которые он делал себе сам. Думаю, если бы ему случилось попасть работать на сапожную фабрику, он бы умер через неделю.
1) Ну если не предпологается что его инструментами будут пользоваться другие, то в общем пофик. Перевод: Если вы в одиночку говняете сайтики, то проблем нет. Но если с вами работает комманда в которую приходят новые люди, то вы тратите их время на обучение и не известно насколько хорошый/удобный интерфейс вы придумали.
2) Хибер и прочий шлак поддержывают (фиксят баги и __оптимизируют__) довольно большие коммюнити, а ваш кошерный ОРМ кто?

Та я ж не против! Нельзя в одной технологии строить собачьи будки и небоскребы. Это просто чтоб молодежь думала головой и выбирала адекватные решения самостоятельно. Лично мне важно получить кайф от работы вдобавок к деньгам. На своем инструментарии я его получаю, на нев***бенных фреймворках — нет. Вот и все. Кстати, сайтики не говняю, не мой профиль вообще.

Нельзя в одной технологии строить собачьи будки и небоскребы. Это просто чтоб молодежь думала головой и выбирала адекватные решения самостоятельно.
Ну допустим № 1 проскочили. Что с пунктом № 2?

>Рыбы покрыты чешуей, но вот если бы они были покрыты шерстью, то у них бы были блохи, а блохи — это насекомые... © анекдот

А что подробней? Язык с динамической типизацией. Подключаешь модуль общения с БД — например, node-mysql. И пишешь что-то вроде:

query(’select * from users where email = ?’, email, function (err, results) {
console.log(results[0].name);
});

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

Удобство для инженеров, главным образом. Потому что писать нативный код как в вашем примере — можно в такие дебри в итоге залезть...

Спорно. Я не знаю, откуда пошла такая боязнь SQL, которая появилась где-то в начале 2000х и культивируется в отдельных сообществах до сих пор. SQL — декларативный язык, причем это самый успешный из всех декларативных языков, созданных за последние 50 лет. Возьмите тот же Riak или CouchDB и попробуйте сделать какую-то выборку с помощью MapReduce. Конечно, у вас получится, и чем больше практики, тем легче вам будет их писать. Но переключитесь в Mongo, и окажется, что две строчки на их языке запросов заменят вам 20-30 строк кода на JS и Erlang.

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

Но это лирика. Для вашего конкретного вопроса я бы дал такой совет: я бы определился с конкретным хранилищем и писал бы для него. Если это Mongo, используйте что-то вроде Mongouse, для MySQL — node-mysql, и т.д. То есть то, чем пользуется большинство. Формально Mongouse — ORM, но на деле это просто красивый враппер над их драйвером. Пересесть с одного стораджа на другой всегда успеете, и переписывание запросов будет для вас наименьшей проблемой, поверьте мне.

Есть несколько проектов «универсальных ORM», но промышленного применения они почти не находят. Обычно их пишут ребята, приходящие из мира Ruby, Java, Python и т.д. Они смотрят — о, для NodeJS нет универсального ORM, сейчас я напишу один и стану клевым популярным парнем вроде DHH и тоже буду на спорткарах кататься" Сами понимаете, дальше домашних игрушек у таких товарищей дело не доходит.

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

stackoverflow.com/...8043841/1346222

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

под обычный SQL формат некоторых данных совсем не подходит.

Да, не дописал. Короче, ближе к реальности. Наша компания занимается хардвером. И приложение, которым я занимаюсь (и кстати, ищу сотрудников на Украине), это централизованная панель управления нашими девайсами. Так вот. Все данные о настройках хранятся в девайсах в каком-то неизвестном мне формате, но обмен происходит в JSON. И у каждого девайса дохрена этих настроек. JSON конечно можно хранить в Postgres как соотв. data type, но так сложилось, что тут используют MongoDB.

С другой стороны, есть разнообразные другие данные, которые удобнее хранить в реляционных базах. К примеру, данные ок клиентах, юзерах, billing data. Отсюда и «зоопарк БД». Зоопарк, но хоть не Ноев ковчег...

дык это разные модели, можно же для разных моделей разные орм использовать

Ну собсно, как и говорил.
Чтобы вам посоветовать, что-то надо с ORM-кой помучаться с годик, словить все грабли, исправить все грабли в своем форке, прислать это все в мейн.
Так что проще свой велосипед сделать облепить тестами и жить припеваючи, чем словить непонятную сложноповторяемую багу на продакшене, после сдачи проекта.

Подписаться на комментарии