смотрю тут напсиали юзают graphql-yoga. скажите, а разве это не идиотизм, ради графкуель добавлять > 5 библиотек на клиент? я молчу о бекенде

Шкала идиотизма в количестве библиотек измеряется?

ну вообще да

ну вообще да

Вас понял

нахуя мне 200 кб какой-то лапши неведомой и десятки непонятных библиотек ради говна которому 2 года, если я могу обойтись рестом апи который юзают уже 20 лет и 0 библиотек

нахуя мне 200 кб какой-то лапши неведомой и десятки непонятных библиотек ради говна которому 2 года, если я могу обойтись рестом апи который юзают уже 20 лет и 0 библиотек

Если у тебя нет ответа на этот вопрос — значит граф тебе не нужен. Всё значительно проще, чем тебе кажется

нахуя мне 200 кб какой-то лапши неведомой и десятки непонятных библиотек ради говна которому 2 года, если я могу обойтись рестом апи который юзают уже 20 лет и 0 библиотек

особенно учитывая, что рест не существует

да никому это гавно не нужно, кроме тех кто в него бабки льет

да никому это гавно не нужно, кроме тех кто в него бабки льет

давай ты набрасывать не будешь

я думал услышать аргументы в пользу графкуель просто. ведь это совершенное безумие творится в этом зоопарке. я как туда сунулся так ахерел

я думал услышать аргументы в пользу графкуель просто. ведь это совершенное безумие творится в этом зоопарке. я как туда сунулся так ахерел

зоопарк? кек

и явно бросается в глаза что его хайпят: подсосы фейсбцука проплаченные и стартаперы со своими говно-хедлесс-цмс на графкуеле. все

и явно бросается в глаза что его хайпят: подсосы фейсбцука проплаченные и стартаперы со своими говно-хедлесс-цмс на графкуеле. все

!ро флейм

я думал услышать аргументы в пользу графкуель просто. ведь это совершенное безумие творится в этом зоопарке. я как туда сунулся так ахерел

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

да и вообще http/1.1 ненужен, лучше http/2.0, стримы красива

Делал так: .use(async(ctx, next) => { const middleware = router.routes(); middleware(ctx, next); await next(); }) .use(someMiddleware); Миддлварка после роутера отрабатывает, но ломаются роуты

Надо было await middleware(ctx, next);

я думал услышать аргументы в пользу графкуель просто. ведь это совершенное безумие творится в этом зоопарке. я как туда сунулся так ахерел

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

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

"graphql когда описывает получение в качестве ответа вложенные объекты согласно схемы не подходит как формат передачи данных между клиентом и сервером"

я ничего не понял, хотя перечитал 5 раз

из-за чего может npm i зависать в контейнере?

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

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

из-за чего может npm i зависать в контейнере?

памяти мало

я ничего не понял, хотя перечитал 5 раз

что же там не понятного - graphql описывает получение в качестве ответа формат вложенных объектов согласно схемы, то есть такой graphql запрос { user(id: 1) { name age friends { id name age } } }вернет объект юзера с вложенными объектами его друзей { id: "1", name: "user1", age: 50, friends: [ {id: "..", name: "...", age: "..."}, {id: "..." name: "...", age: "..." } ] }Почему это не подходит как формат для общения клиента и сервера - проблемы начинаются тогда когда мы описываем более сложные запросы например когда пишем соцсеть и хотим показать список людей с которыми юзер может быть знаком и нужно получить от сервера список друзей всех друзей юзера, то есть примерно такой запрос { user(id: 1) { name age friends { id friends: { id age name } } } }и что получится - мы получим огромное дерево вложенных объектов где может быть много дублей -один и тот же юзер может находится в списке друзей многих других юзеров, и как результат мегабайты json-a, тормоза на парсинг и обработку а вот если бы graphql отдавал бы результат в виде нормализированной структуры { users: { "1": { id: "1", name: "...", age: ... friends: ["2", "3"] }, "2": { id: "2", name: "...", age: ... friends: ["4", "5", ...] } } }то у нас не было бы никакого дублирования потому что один и тот же юзер включался бы в ответ только один раз

что же там не понятного - graphql описывает получение в качестве ответа формат вложенных объектов согласно схемы, то есть такой graphql запрос { user(id: 1) { name age friends { id name age } } }вернет объект юзера с вложенными объектами его друзей { id: "1", name: "user1", age: 50, friends: [ {id: "..", name: "...", age: "..."}, {id: "..." name: "...", age: "..." } ] }Почему это не подходит как формат для общения клиента и сервера - проблемы начинаются тогда когда мы описываем более сложные запросы например когда пишем соцсеть и хотим показать список людей с которыми юзер может быть знаком и нужно получить от сервера список друзей всех друзей юзера, то есть примерно такой запрос { user(id: 1) { name age friends { id friends: { id age name } } } }и что получится - мы получим огромное дерево вложенных объектов где может быть много дублей -один и тот же юзер может находится в списке друзей многих других юзеров, и как результат мегабайты json-a, тормоза на парсинг и обработку а вот если бы graphql отдавал бы результат в виде нормализированной структуры { users: { "1": { id: "1", name: "...", age: ... friends: ["2", "3"] }, "2": { id: "2", name: "...", age: ... friends: ["4", "5", ...] } } }то у нас не было бы никакого дублирования потому что один и тот же юзер включался бы в ответ только один раз

Да, есть такая беда, это все таки не мап-редьюс тула

Тут придется написать еще один эндпоинт

Как очень удачно было у кого-то сказано, граф имеет рекурсивную природу

что же там не понятного - graphql описывает получение в качестве ответа формат вложенных объектов согласно схемы, то есть такой graphql запрос { user(id: 1) { name age friends { id name age } } }вернет объект юзера с вложенными объектами его друзей { id: "1", name: "user1", age: 50, friends: [ {id: "..", name: "...", age: "..."}, {id: "..." name: "...", age: "..." } ] }Почему это не подходит как формат для общения клиента и сервера - проблемы начинаются тогда когда мы описываем более сложные запросы например когда пишем соцсеть и хотим показать список людей с которыми юзер может быть знаком и нужно получить от сервера список друзей всех друзей юзера, то есть примерно такой запрос { user(id: 1) { name age friends { id friends: { id age name } } } }и что получится - мы получим огромное дерево вложенных объектов где может быть много дублей -один и тот же юзер может находится в списке друзей многих других юзеров, и как результат мегабайты json-a, тормоза на парсинг и обработку а вот если бы graphql отдавал бы результат в виде нормализированной структуры { users: { "1": { id: "1", name: "...", age: ... friends: ["2", "3"] }, "2": { id: "2", name: "...", age: ... friends: ["4", "5", ...] } } }то у нас не было бы никакого дублирования потому что один и тот же юзер включался бы в ответ только один раз

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

Да, есть такая беда, это все таки не мап-редьюс тула

это решаемо, кек

это решаемо, кек

Решаемо конечно но это уже за рамками графа

ну, graphql дает все необходимые инструменты для этого

что же там не понятного - graphql описывает получение в качестве ответа формат вложенных объектов согласно схемы, то есть такой graphql запрос { user(id: 1) { name age friends { id name age } } }вернет объект юзера с вложенными объектами его друзей { id: "1", name: "user1", age: 50, friends: [ {id: "..", name: "...", age: "..."}, {id: "..." name: "...", age: "..." } ] }Почему это не подходит как формат для общения клиента и сервера - проблемы начинаются тогда когда мы описываем более сложные запросы например когда пишем соцсеть и хотим показать список людей с которыми юзер может быть знаком и нужно получить от сервера список друзей всех друзей юзера, то есть примерно такой запрос { user(id: 1) { name age friends { id friends: { id age name } } } }и что получится - мы получим огромное дерево вложенных объектов где может быть много дублей -один и тот же юзер может находится в списке друзей многих других юзеров, и как результат мегабайты json-a, тормоза на парсинг и обработку а вот если бы graphql отдавал бы результат в виде нормализированной структуры { users: { "1": { id: "1", name: "...", age: ... friends: ["2", "3"] }, "2": { id: "2", name: "...", age: ... friends: ["4", "5", ...] } } }то у нас не было бы никакого дублирования потому что один и тот же юзер включался бы в ответ только один раз

ты можешь попросить { user(id: 1) { name age maybeKnownFriends { id age name } } } и на выходе получить плоскую структуру без дублей

А как в графе описать связь многих ко многим?

А как в графе описать связь многих ко многим?

в доке видел одну из первых страниц об этом

в доке видел одну из первых страниц об этом

Там вроде напиано что никак )

А как в графе описать связь многих ко многим?

Связь по ключам идёт с бд

Сорри, что влезают, а разве проблема вывода друзья-дрезей, не решается глубиной выборки?

Иначе можно же вытащить всю базу)

Связь по ключам идёт с бд

по резолверам

Там вроде напиано что никак )

а вообще, как напишешь резолвер на бекенде, так и будет работать

Сорри, что влезают, а разве проблема вывода друзья-дрезей, не решается глубиной выборки?

ну а ты вытаскивай только друзей друзей

т.е. 2 уровня

Ну теперь представь индивида у которого друзей пол ляма

Связь по ключам идёт с бд

Ога, а там начинаются n+1 запрос проблемы

Ну теперь представь индивида у которого друзей пол ляма

ну а шо, думаешь не потянет?

нутак сделай ограничение на 10к

как в вк

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

Ну на беке другой чел прописывал связи в dump В докере однако... Посмотри структуру связок в postgraphile

Поделюсь полезной статейкой про граф и его болячки (и как лечится) https://medium.freecodecamp.org/five-common-problems-in-graphql-apps-and-how-to-fix-them-ac74d37a293c

памяти мало

на системе довольно много для npm, а разве можно как-то отрегулировать ресурсы для контейнеров в ubuntu?

на системе довольно много для npm, а разве можно как-то отрегулировать ресурсы для контейнеров в ubuntu?

Это в чат докера

Это в чат докера

ок

Ребят, подскажите пожалуйста, есть такая вот модель: http://dpaste.com/2ADM5QR Когда я пишу в базу, то всё окей, создается вот такой объект: http://dpaste.com/2AR5J4D Но когда я делаю populate это блока вот таким вот запросом: let query = await Blocks.find().populate('operations.link').populate('transactions').limit(1).lean(); транзакции вытаскивает правильно, а операции почмеу-то нет. Выводит вот такое: "operations": [ { "_id": "5bc73887719d692203ee6bcc", "link": "5bc73886719d692203ee6bc9", "onModel": "votes" } ] Хотя ожидается, что выведет операцию из коллекции votes. Подскажите, в чем косяк запроса

кто что для миграций посоветует?

кто что для миграций посоветует?

sequelize

кто что для миграций посоветует?

Или же можно использовать umzug

На основе которого работает sequelize

Если нужны чисто миграции

Но клиент для командной строки придется писать самостоятельно)

Или же можно использовать umzug

Спасибо

Спасибо

Сэкономлю твоё время и кину свой на коленке написанный cli, который во многом повторяет sequelize: https://gist.github.com/Vitaly-Rudenko/2b685747a902adea7ad0c044a2ffef3a

нет бы взять монгу с монгузом...

нет бы взять монгу с монгузом...

нахуй не нужна

+

Сэкономлю твоё время и кину свой на коленке написанный cli, который во многом повторяет sequelize: https://gist.github.com/Vitaly-Rudenko/2b685747a902adea7ad0c044a2ffef3a

О!

Спасибо большое

нет бы взять монгу с монгузом...

ибо без миграций не выйдет

ибо без миграций не выйдет

?

красиво

там просто в index.js конфиг

?

было одно поле name стало два поля firstName lastName монга смело идет нахуй без миграций

а он еще нужен внутри аппы

короче на коленке, как и сказал :D

было одно поле name стало два поля firstName lastName монга смело идет нахуй без миграций

sql ненужон

sql ненужон

хуевый вброс

хуевый вброс

+