если proxy.web(req, res, { target: 'http://localhost:3000' }); переместить после запроса к бд, то ошибки не будет, но придется второй раз загружать страницу, чтобы вытащить данные из бд(он получается сначала редиректит тебя, а потом результаты из бд достает)

зачем это делать на ноде, я бы не стал)

Повторю вопрос: Привет. У меня вопрос по qiwi api. Можно ли переводить деньги с одного кошелька на другой без смс-подтверждения? Или такое только через эмулятор пользователя в браузере сделать можно?

Всем привет. Что думаете про фреймворк loopback? Юзает кто-нибудь?

Ну такое... Скажем так, попытка большой и страшной IBM запихнуть ручки в наш хипстерский мир (а на самом деле продать нам хостинг по цене крыла от Боинга). Если не хотите брать надоевшие Express и Koa, то есть вроде бы неплохой Hapi.

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

Не то что надоевшие. Я, так скажем, пришёл из мира python и django. Сейчас пришёл к мысли, что, странно писать на разных языках для фронтэнда и бэкенда, поэтому надо бы потихоньку осваивать что-нибудь на ноде. И на глаза попался как раз этот loopback. И на первый взгляд прям идеально подходит под то, что я ищу: целостный фреймворк (не куски, которые надо собрать воедино), заточенный под написание API, без какого-либо рендеринга страниц, ORM из коробки. Loopback чем-то плох? Или есть какие-то альтернативы, более-менее подходящие под такие условия?

Неверно

"Странно писать на разных языках для фронтенда и бэкенда". Почему странно-то? На клиенте вы рендерите элементы, двигаете формочки и пр. На сервере вы работаете с БД, протоколами и пр. Логичнее бы было использовать как раз разные языки

Не то что надоевшие. Я, так скажем, пришёл из мира python и django. Сейчас пришёл к мысли, что, странно писать на разных языках для фронтэнда и бэкенда, поэтому надо бы потихоньку осваивать что-нибудь на ноде. И на глаза попался как раз этот loopback. И на первый взгляд прям идеально подходит под то, что я ищу: целостный фреймворк (не куски, которые надо собрать воедино), заточенный под написание API, без какого-либо рендеринга страниц, ORM из коробки. Loopback чем-то плох? Или есть какие-то альтернативы, более-менее подходящие под такие условия?

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

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

Храните все связанные данные в самом документе 😎

и в какой nosql бд можно хранить сложный документ с большой вложенностью?

От Loopback попахивает Тырпрайзом в стиле .NET. Нечто такое вот огромное, неповоротливое и переусложнённое. Если вам нравится вот так https://github.com/strongloop/loopback/raw/master/docs/assets/lb-modules.png, можете попробовать)

ну, например у меня есть массив объектов, и в этом массиве объектов лежат еще объеты содержащие массив. мне потребуется их обновлять (те которые вложенны) - монга, например, не сможет обновить объект вложенного массива

А какие есть альтернативы? Только, пожалуйста, без такого, чтобы каждый endpoint самому описывать. В express именно так, насколько я понимаю. Хотелось бы примерно как в Django — указал модель, указал, какие CRUD операции тебе от неё нужны. Всё, готово. Всё занимает 4 строчки, благодаря наследованию. Но при этом неплохо расширяется / изменяется путём переопределения методов, mixins и ещё всяких механизмов. Ну и ORM свой сразу.

А какие есть альтернативы? Только, пожалуйста, без такого, чтобы каждый endpoint самому описывать. В express именно так, насколько я понимаю. Хотелось бы примерно как в Django — указал модель, указал, какие CRUD операции тебе от неё нужны. Всё, готово. Всё занимает 4 строчки, благодаря наследованию. Но при этом неплохо расширяется / изменяется путём переопределения методов, mixins и ещё всяких механизмов. Ну и ORM свой сразу.

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

Почему тырпрайз-то?

мне, как и предыдущему оратору, тоже кажется, что оно попахивает тырпрайзом и лупбек туда и метит

мне, как и предыдущему оратору, тоже кажется, что оно попахивает тырпрайзом и лупбек туда и метит

Народ, вот уже месяц пытаюсь перестать думать SQLем и работать с ентим вашим NoSQL. Как в MongoDB (+Mongoose) делается связь one-to-many? Например, список коментариев к посту или список пользователей, подписавшихся на обновления треда. Сложить их в отдельную коллекцию и добавить ID родительского документа или каким-то макаром запихнуть их в нечто типа массива в родительском документе? При этом по ним должен быть простенький поиск (например, все коментарии пользователя под постом) и выборка порциями. Подходят ли для этого "поддокументы" (http://mongoosejs.com/docs/subdocs.html)? Как делать такое по феншую?

В NoSQL у тебя будет документ с постом и в нем массив субдокументов с комментариями. Не нужно никаких 1M, суть немного иная

О! Есть аругментированный список минусов?

Точнее секвалайз за три строчки подрубаетсч

А ещё вопрос, как вы поступаете с импортами? Транспилируете бабелем в require? Или не используете импорты в пользу require?

Если юзать node 7+, то Babel имхо не нужен. Нативных импортов не предполагается ещё с пол года, плюс это будет сильно не похоже на RequireJS транспайлинг, так что просто поменять расширение файла не получится (https://medium.com/p/e0e7dcc44c6e). Async/await уже есть нативный и он норм, а Babel будет генерить лапшу с адовым дебагом.

Если юзать node 7+, то Babel имхо не нужен. Нативных импортов не предполагается ещё с пол года, плюс это будет сильно не похоже на RequireJS транспайлинг, так что просто поменять расширение файла не получится (https://medium.com/p/e0e7dcc44c6e). Async/await уже есть нативный и он норм, а Babel будет генерить лапшу с адовым дебагом.

во первых можно после бабеля на выход давать es6-7 во вторых бабель это не только es7->es5 а также куча разных полезных плагинчиков

Слышал плохие отзывы про этот ваш секвалайз. Правда от phpшника. В сравнении с phpшными инструментами. Что думаешь на этот счёт?

Слышал плохие отзывы про этот ваш секвалайз. Правда от phpшника. В сравнении с phpшными инструментами. Что думаешь на этот счёт?

Поддержу, иногда дикие запросы генерит плюс баги бывают в кустах. И api мальца не удобное, но это уже вкусовщина. Я от него отошёл в сторону Knex. Это QueryBuilder от sequelize. Миграции есть (хотя имхо, не оч реализация), запросы пишу ручками и ее парюсь.