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

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

@egoarka  Ну это не во всех случаях, а только в нескольких запросах. Бывают случаи, когда по связям из базы оочень много нужно запросить в процессе обработки операции. Я уже задумался о введении уровня кэша, но попробовал написать аггрегацию на 270 строк, и все заработало и так быстро)

10 сентября в офисе Rambler&Co пройдет первое offline-событие Facebook Developer Circle: Moscow, первого официального сообщества разработчиков Facebook в Москве и России. Приедут спикеры от Facebook. Ребят, приглашаем всех принять участие)
https://facebook-developer-circle-moscow-launch-event.splashthat.com/

Про graphql что-нибудь будет?

Простите что пишу сюда, не отыскал специально чата для этого. Ищу работу back, typescript, GraphQL. Могу организовать CI/DI доставка Docker.

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

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

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

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

Все верно, волосатый Графкуэль это один из подходов. Где-то применим, где-то нет. Всегда надо исходить из продукта и задач. Важно было показать, что есть такой подход в графкуэле, в отличии от реста.

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

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

На PiterJS conf 2019 (https://conf.piterjs.org/) будет практический доклад по GraphQL:

Полина Гуртовая выступит с  "GraphQL - уменьшаем энтропию". В нем разберёт кейс "причесывания" внешних интеграций, про сложности на пути и немного про apollo и relay.

Регистрация ещё открыта, а если не получится быть физически на конфе - будет трансляция (ссылку на нее скинем в социалках PiterJS в день конфы)

Привет ребята!
Если главный бэкэнд приложения и маленькие сервисы тоже на gql.
По задумке, пользователь общается с бекендом, бек иногда пересылает запросы юзера на внутренние сервисы.

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

Пушить в subscription-redis из сервиса, на беке сделать subscription point и отдавать новые сообщения?
Может можно как-то на сервисе реализовать свой subscription и юзера туда спроксировать через schema-delegation?