Всем привет.
Кто-нибудь сталкивался с проблемой скорости чтения/обновления кэша при большом количестве обьектов? И если да, то как решали проблему? Используем InMemoryCache, тянем дерево с количеством узлов около 10-20к, даже без нормализации, приложение фризится. Hermes также пробовали, да, быстрее, но все еще медленно.
Заранее спасибо!

была схожая проблема с хранением полигонов координат. В итоге пришлось в apollo хранить ключ на внешний кеш приложения. Хотя в 3 ветке, что-то с кешом много мудрили, авось и лучше стало. Но у меня около миллиона объектов было, на 10-20к провисаний не должно быть

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

Вместо eq используй фильтр in

Параметр должен быть массивом. Фильтр - объект where, поле с суффиксом _in

Запрос тоже к strapi

Вовремя)
Давно разобрался,  но всеравно спасибо

Можно ли запускать редирект из Link? Ситуация такая: в отдельном link добавляю заголовок с токеном, но где редиректить если токена нет? разумно ли это делать из link?

в Apollo как-то можно поменять keyFields для всех типов, не перечисляя их?

Всем привет! Такой вопрос - как можно объединить мутации при отправке на сервер, чтобы сделать один POST. Например, нужно изменить 10 одинаковых элементов но с разными ID. Сейчас,  я делаю это в строковом виде, т.е. складываю много запросов в одну строку и делаю запрос.

Apollo сам умеет делать batch запросы насколько помню

А что мешает всё в одной мутации делать?

Выглядит как проблема дизайна GraphQL-схемы.

Нужно сделать мутацию типа updateMany, которая выбирает элементы по какому-то where и массово их обновляет за раз.

Что-то типа такого.

спасибо, а вы говорите про фронт?

сейчас это и есть одна мутация, но с n-количеством операций типа createElement_N: createElement(N-data){},

Это плохо. )

знаю, поэтому и обратился за советом.

Понял)

У меня проблема apollo-server с subscriptions.
Может кто-то подсказать? Не могу понять в какую сторону копать.

Есть такая схема и резолвер
const typeDefs = gql
  type Example {
    id: ID
    value: string
  }
  type Subscription {
    onExampleUpdate: Example
  }

const resolvers = {
  Example: {
    id: (parent) => parent.id,
    value: (parent) => parent.value,
  },
  Subscription: {
    onExampleUpdate: {
      subscribe: () => pubsub.asyncIterator('CHANNEL_EXAMPLE')
    },
  },
}

И где-то в другом месте я публикую изменения
pubsub.publish('CHANNEL_EXAMPLE', data)
тут все работает отлично

но когда я хочу использовать dataSource внутри резолвера, то результат кешируется при следующих обновлениях и я получю старые данные

const resolvers = {
  Example: {
    id: (parent) => parent.id,
    value: (parent) => parent.value,
    // тут
    issue: (parent, parent, context) => context.dataSources.exampleAPI.getIssueByExampleId(parent.id)
  },
}

Кроме отключения кэша пока решения не нашел