У кого есть опыт работы с graphql (express), подскажите, нужно ли оборачивать методы для работы с БД или прямо из ресолверов работать с БД? Будут ли плохие последствия потом?

Прямо из resolver работаю с бд

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

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

А на каком языке пишите? И с какой базой работаете?

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

Графкуэль это как бы контроллер (если смотреть на него в парадигме MVC). Он дергает модельки (сервисы и реджистри).

у меня примерно такая структура UsersModule
(использую NestJS)
Единственное, пока мешаю в резолверах Services и Dataloaders, думаю нужно спустить Dataloader на уровень репозитория, но тогда придется прокидывать контекст вниз

У меня много разных коннекшнов к разным источникам данных, там и базы и рест-апи

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

Никто не сталкивался с такой ошибкой "Invariant Violation: Must contain a query definition" ? Если работать без кеша, то нормально все работает...

Добрый вечер! На связи Никита, создатель Щилди. Вот-вот Щилди добавят в 65 000 чатов — и я спешу представить вам свой новый проект: Тудурант.

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

Как вебсайт
Как iOS приложение
Как Android приложение

Основные правила продуктивности я описал в статье "Как у меня получилось запустить 7 продуктов за год" и в видео-руководстве "Как пользоваться Тудурантом" (всего две минуты). Если вкратце: в Тудуранте нельзя добавлять задачи без четкой даты выполнения, на основной вкладке всегда показана только одна задача для концентрации, а неприятные задачи названы "лягушками" и выполняются первым делом каждый день.

Я хакнул свою продуктивность простыми правилами и сделал приложение для вас, чтобы и вы смогли добиться такого же успеха! Тудурант полностью бесплатен первые 30 дней, а мобильными приложениями можно пользоваться даже без логина. Никаких обязательств — просто попробуйте Тудурант в вебе, как iOS приложение или как Android приложение.

Так вы поддержите абсолютно бесплатный Щилди, который помогает банить более 250 000 спам-аккаунтов в сутки (а еще, в отличие от других популярных ботов, я не продаю рекламу, только изредка рассказываю вам о своих новых продуктах). Спасибо!

— @borodutch

Всем привет, подскажите пожалуйста, если есть 2 мутации на создание и обновление, то как лучше будет делать: 1. Сделать create-input.type и update-input.type. 2. Сделать один input.type?

В любом случае их будет два, при обновлении ты передашь ид, а при создании - нет

но можно ведь сделать чтобы было 2 аргумента, 1-ый будет id, а второй уже сама модель объекта

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

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

Да, нужно писать разные инпут типы под create и update.

Понятно что муторно, но у себя я их просто генерирую.

ок, спасибо

Ребят, подскажите пожалуйста такой вопрос. Есть потребность сделать прослойку в виде graphql apollo сервера, чтобы был gate между rest сервером. Но и ещё чтобы был серверный рендеринг. Делал кто нибудь подобное? Куда копать вообще? По отдельности все ясно вроде, а вот все это совместить...

А зачем совмещать?

А как если не совмещать? Отдельно будет крутиться Apollo Server и отдельно будет прослойка для ssr?