Получилось. Оказывается до id не мог добраться

Прекрасная штука, пользуюсь

я тоже генерирую типы по схеме, с этим все ок, но вот иметь бы такое же для rest  было бы круто

Ребята, всем привет. Начинаю писать серевер на тайпскрипте. Для генерации схемы взял ‘type-graphql’. По каким-то причинам, билд путем ‘nxp tsc && node dits/index.js’ работает. А вотчер с ‘npx ts-node ./src/index.ts’ выкидывает ошибку ‘Error: You need to provide explicit type for Task#title !’. Когда Task#title - это банальный стринг и вообще схема Task-а взята из примера в type-graphql. Кто-то сталкивался?

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

@GamegaOleg решил проблему с перфом на деве?

да спасибо, я так и не понял что делал graphql -x в докментации не нашел этого флага, но убрал его перезхал на tsnd  стало рабоать заметно быстрее

👍

спасибо )))

Если кто-то попадет на такой баг, то проблема была в том что рядом с Task.ts лежал транспилированный Task.js. По каким-то причинам когда-то давно он странспилировался отдельно. Так вот, при запуске с ts-node, почему-то брался тот js-ник, а не свежесгенерированный из dist/

Кто-то может реализовывал функционал определения статуса юзера online/offline? Подскажите пожалуйста куда копать, чтобы зацепиться на события на сервере, что-то типа subscribe/timed out/unsubscribe (apollo server 2)

Вопрос: использую graphql-compose-mongoose для построения схемы + квери в другой апи в резолверах. Раньше другой апи был rest, тоесть в резолверах вызывался RestApiDataSource, сейчас там graphql вместо реста. Какой подход лучше использовать? Данные из другого апи надо предварительно трансформить перед отдачей на клиент

@nodkz Послушал доклад на Holy.js про фрагменты и Relay.
Особо интересным показался разговор про "Волосатый" GraphQL API. Основная мысль, я так понял, такая - при хорошо спроектированном GraphQL API разработчики клиентской стороны могут спокойно ходить по описаным в схеме связям, вызывая различные resolvers, а в плохом - словно в REST стучатся в определенные точки.
По моему мненую, это утверждение верно лишь для тех проектов, в которых логика модели хранимых данных декларативно мапится на клиентское приложение, то есть в довольно простых приложениях.

В случаях, когда бэкенд представляет из себя  прложение с трехзвенной архитектурой (Представление - Бизнес -Данные), в нем много бизнес логики и, особенно, когда делается серьезный упор на производительность, сделать "Волосатый" GraphQL будет почти что невозможно. Может я просто не видел хорошего примера, но все наши попытки на проекте, которому уже больше года, сводятся все равно к описанию определенных операций и конкретной их обработке.

Тем не менее, даже при таком подходе, надо сказать, видятся огромные преимущества использования GraphQL.  Жесткая типизация, в совокупности с продвинутым тулингом, позволяет тратить в разы меньше времени на общение с фронтендерами по поводу изменений в  API. В моем случае есть три клиентских приложения,, которые делают 6 человек, и я почти не трачу времени на объяснения изменений в API.  Я, как максимум, говорю, какие запросы изменились - дальше они уже лезут в песочницу и смотрят сами. Да и самому легче при разработке фич использовать песочницу для проверки работы запросов, чем какой-нибудь PostMan в случае Rest.

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

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

https://github.com/overpod/ku делал недавно на призме пример

в файле мутаций есть         t.prismaFields(['createVideo'])
       t.prismaFields(['createCategory'])

они пробрасывают CRUD призмы

@overpod  Кодогенерация -  с нее мы начинали. Она дала возможность очень быстро полететь навстречу таскам, и где-то месяца 4 мы жили отлично. Использовали не призму, а кастомное решение, но смысл тот же. У нас представление, которое мы отдаем юзеру, существенно отличается от того, что есть на уровне бизнес-сущностей и в  базе, от слова совсем. Соответственно, кодогенерация нам не нужна.

Сначала пробовали такую схему: нужно много логики? - дергаешь кастомный запрос, написанный отдельно, а он внутри себя дергает 5-6 запросов сгенеренных, между делом совершая различные вычисления и обработки. Но здесь уперлись в производительность. Переписывая запросы в базу на монго-аггрегацию, в самых тяжелых запросах я получил прирост производительности в 400 раз.