Насколько тяжёлая у Вас проверка авторизации? Что она делает?

Вы навешиваете авторизацию на типы или на операции (мутации и квери)?

Проверка токена почти на все операции

нагрузка около 1000RPS, даже если вынесен токен в Redis, очень сильно снижает производительность gql

Я сталкивался с проблемой, когда директивы были навешены на типы и потом при профайлинге было видно как при запросе эти директивы по сто раз отрабатывают.

На типы не вешаю, сталкивался в свое время

Скажите если я сделал query в одном компоненте как получить данные из кеша что бы переиспользовать их в другом ? (vue-apollo)

Вызвать квери. Он вернёт вам кеш

То есть снова сделать запрос?

Да. Если у вас не стоит получение данных только по сети

Будет брать из кеша

Спасибо

привет
пытаемся реализовать union в который входит connection и accesserror
т.е хочется иметь что-то вида
union Items = ItemsConnection | AccessError

и запрос вида

query {
 items(first,after..) {
     ...on ItemsConnection {
         pageInfo
         nodes
     }
     ...on AccessError {
        message
    }
 }
}

но че-то там ошибка кривая вылезает и непонятно делают ли так вообще

если union засунуть внутрь nodes то нормально работает, но на мой взгляд выглядит немного нелогично, что доступ на items получается есть, а на nodes уже может не быть, хотя всё это часть одного connection

query {
   items {
       pageInfo
       nodes {
            ...on Item { id }
            ...on AccessError { message }
       }
   }
}

вопрос какой путь более "графкуельный"?

И да, если вдруг кто-то пропустил:

https://www.apollographql.com/blog/introducing-the-apollo-explorer/

Ваш первый вариант правильный и с точки зрения graphql всё верно. Если ошибка, значит где-то ошиблись в реализации. Я сам сделал недавно точно такую же query:

query {
  inbox {
    notifications {
      ... on NotificationConnection {
        nodes {
          id
        }
      }
      
      ... on NotAuthenticatedProblem {
        message
      }
    }
  }
}

Всем привет!

Есть задача получать для каждого элемента списка, список других элементов. Например для каждого пользователя, список последних прочитанных книг. Кол-во книг, для каждой платформы может отличаться, например в мобильных приложениях нужно отдавать последние 5, а на вебе последние 3 книги.

Если делать в лоб и запрашивать книги для каждого пользователя, то будет проблема N+1, даталоадер не воткнешь, отдельное поле lastFiveBook у User тоже не сделаешь, ведь необходимое кол-во отличается от платформы.

Есть ли какой нибудь паттерн на этот случай?

А в чем проблема с даталоадером?

Ну на худой конец можно ограничить вложенность, сomplexity limit

Кол-во книг задается аргументом, т.е. сегодня 5 для мобильных приложения, 3 для веба, а завтра 2 для обеих платформ 🙂

Как такое сделать с даталоадером, если ему на вход нужно передавать key?

Почитайте сначала как работает dataloader, он не завязан на количестве необходимой вам информации