Комментарии 15
"… с реляционными БД, такими как *SQL и Mongo..."
Вероятно, всё-таки с нереляционными. Собственно, в этом и ответ: сложности именно из-за того, что они нереляционные.
Вероятно, всё-таки с нереляционными. Собственно, в этом и ответ: сложности именно из-за того, что они нереляционные.
Спасибо, поправил — пропустил "осфордскую запятую".
На самом деле склонен не согласиться. Сложность использования того же mongoose (с кучкой плагинов) примерно равна massive или sequelize. Дело именно в том, что асинхронность (а значит — необходимость делать действительно много синхронизации и невозможность задавать сколько-либо глобальные переменные) ломает многие принципы, которые переносятся из работы с БД в других языках.
На самом деле склонен не согласиться. Сложность использования того же mongoose (с кучкой плагинов) примерно равна massive или sequelize. Дело именно в том, что асинхронность (а значит — необходимость делать действительно много синхронизации и невозможность задавать сколько-либо глобальные переменные) ломает многие принципы, которые переносятся из работы с БД в других языках.
Как только я стал писать на koa через функции-геренаторы, то отношение к программированию на nodejs улучшилось в разы. Код пишется так, как-будто все функции работают синхронно. А с учетом того, что на многие пакеты есть promise обертки, которые позволяют работать с кодом также как с синхронным (в koa это сопрограммы кажется называется, но могу ошибаться), программировать на nodejs теперь намного проще.
Скорее всего есть orm/odm пакеты с промисами.
Скорее всего есть orm/odm пакеты с промисами.
Да нет, многие ORM/ODM поддерживают promise-ы. Вопрос в другом — они все равно пытаются нести практики из других языков, в которых эти практики работают в рамках потока. К тому же эти библиотеки пытаются скрыть очень много логики внутри большого количества фабрик, генерирующих свои внутренние объекты и выставляющие наружу сложный API.
Так, например, в каком-нибудь ruby при попытке получить массив по отношению (например author.posts) — синхронно отработается внутренний запрос к БД. Решения в JS же пытаются придумать синтаксис для предварительной подгрузки этих данных (т.к. надо делать асинхронный запрос, синхронные-то недоступны), или пытаются это решить каким-то другим образом, тоже не очень очевидным. Вместо того, чтобы использовать преимущества JS — они пытаются сгладить его недостатки огромным API.
Так, например, в каком-нибудь ruby при попытке получить массив по отношению (например author.posts) — синхронно отработается внутренний запрос к БД. Решения в JS же пытаются придумать синтаксис для предварительной подгрузки этих данных (т.к. надо делать асинхронный запрос, синхронные-то недоступны), или пытаются это решить каким-то другим образом, тоже не очень очевидным. Вместо того, чтобы использовать преимущества JS — они пытаются сгладить его недостатки огромным API.
Так с промисами работа получается с точки зрения кода почти синхронной:
Вот что я имел ввиду, мы работаем не с колбеками, или ветками .then(), а из асинхронной функции получаем результат, как бы синхронно с точки зрения скрипта.
var posts = yield odm.findAllAsync(); // findAllAsync return Promise
var posts2 = odm.findAllSync();Вот что я имел ввиду, мы работаем не с колбеками, или ветками .then(), а из асинхронной функции получаем результат, как бы синхронно с точки зрения скрипта.
Зачем вы используете odm? Вам действительно удобней?
Eternalko, Тут вопрос не в odm или драйвере, а как их использовать, с "callback адом" или с yield как "синхронный flow".
Львиная доля сложности может уйти и при работе с odm, если изменить flow с асинхронного на синхронный.
Львиная доля сложности может уйти и при работе с odm, если изменить flow с асинхронного на синхронный.
и львиная доля перфоманса Node.js заодно
Использую koajs где все так построено, проблем с performance не испытываю. Можете информацией поделится, откуда вы это взяли?
Так, вы меня запутали. Вы используете синхронный флоу или корутины/файберы для того, чтобы убрать колбэки? Есть разница. Указанный в примере выше odm.findAllSync займет весь поток выполнения JS и не даст обрабатываться другим запросам.
В JS в условиях файберов/асинхронного выполнения нужно понимать, как все работает, чтобы не словить deadlock или мутирование внутреннего состояния, это не синхронный флоу.
В JS в условиях файберов/асинхронного выполнения нужно понимать, как все работает, чтобы не словить deadlock или мутирование внутреннего состояния, это не синхронный флоу.
AlexPTS я про odm и драйвер спрашивал)
Просто нативные драйвера настолько хороши в node что использовать odm не вижу смысла.
В разговор об асинхронных паттернах вдаваться не буду. Тема избитая(:
Просто нативные драйвера настолько хороши в node что использовать odm не вижу смысла.
В разговор об асинхронных паттернах вдаваться не буду. Тема избитая(:
А я использовал mysql и mongoose как в мелких, так и в крупных проектах. И бед не знал. И мне всегда было глубоко пофигу неважно что на кросс-sql-ность (sqlite, mysql, pgsql, ...), что на кросс-nosql-ность (mongo, couchdb, redis, ...). В некоторых проектах даже использовал для разных данных оба модуля mysql и mongoose одновременно.
Собственно, простота реализации, модернизации и оптимизации!
Собственно, простота реализации, модернизации и оптимизации!
Так я и не понял до конца. Судя по всему — вам же обычный query builder нужен. knex пробовали? Если да — чем не устраивает?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Агрегат для node.js