Привет, как в graphql реализовать фильтрацию по дочерним элементам?

P.S. бот перестал удалять сообщения 😂

?

ахах, опять дельнул коммент с примером)

например у меня есть фильтр по статьям - с фильтром по категории, в статьях я получаю комментарии (например топ 10) - это норм

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

передай имя и отфльтруй, или я не понимаю тебя

мне нужно исключить статьи, где есть неподходящие childrens

я делаю фильтр статей по категории, внутри лежат комменты -> им делаю фильтр по id пользователя

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

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

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

и фильтрация по комментам уже не влияет на выборку статей

можно конечно сделать специальный резолвер конкретно под этот случай, но так и в rest api можно делать

можно конечно пойти обратным путем, получить пользовтаеля, все его комменты, и уже там например отсортировать статьи по cat_id

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

Apollo серверный рендеринг работает тупо. Чтобы вы поняли как описываю.  Вызываю функцию React.renderToStaticMarkup на элемент, он рендерится, все useQuery получают loading true. Но на этом процесс не останавливается, запросы к api продолжают идти в фоновом режиме, хотя уже страница отрендерена и отдана клиенту. Конечно можно подождать и отдать страницу вместе с заполненным APOLLO_STATE, из которого на клиенте потом востанновятся все данные, но это не серверный рендеринг, а клиентский, только с загрузкой сервера по выполнению запросов к базе данных, страница то отрендерена с loading'ами, а не с данными. Серверный рендеринг то нужен для целий прежде всего SEO. Но то, как это реализовано ни рыбо ни мясо, это не полноценный серверный рендеринг.

Спрашивается зачем делать запросы к api на сервере и возвращать их в виде кэша для восстановления, если нужно вернуть сразу отрендеренную с данными страницу.

Если отключить javascript полностью на клиенте, то серверный рендеринг apollo не сможет возвращать полноценные страницы

Все прекрасно работает.
Надо только правильно заюзать либу @apollo/react-ssr

Вот пример как в Next.js реализовано
https://github.com/zeit/next.js/blob/canary/examples/with-apollo/lib/apollo.js#L67

Ребат, никто не знает как сделать так, чтобы директива cacheControl распространялся на вложенные филды edges, node и pageInfo коннекшна, к примеру AnyConnection { edges { node { ... } }, pageInfo }?
Проблема в том, что если указать cacheControl для AnyConnection, то она фактически игнорируется так как у edges, node и pageInfo по умолчанию нет TTL, соответственно кеш не работает.
Повесить cacheControl на эти фложенные филды вручную не получится, ибо для разных кверь кеш может быть разным, например:

edges: [ProgramEdge]
node: ProgramNode
pageInfo: ProgramPageInfo

query a {
  channel {
    programs { }: ProgramConnection @cacheControl("maxAge": 9000)
  }
}

query b {
  livetv {
    relatedPrograms { }: ProgramConnection @cacheControl("maxAge": 30)
  }
}

Кто-нибудь знает как решить эту проблему?

Может будет лучше всего програмно смотреть у каких коннекшнов самый долгий TTL при билдинге схемы, и его указывать для этих вложенных филдов? Я, правда, не уверен сломает ли это что-то. По идее если TTL у коннекшна окажется меньше (или вообще отсутствовать), чем, например, у node, то по идее будет использован TTL конекшна 🤔

а без next?

Читай доку https://www.apollographql.com/docs/react/performance/server-side-rendering/#using-getdatafromtree

все сделал по доке и протестил