беру данные из файлика. Схему он строит и данные graphiql есть. Но когда делаю фильтр он не фильтрует а отдает все занчения. Заметил одну разницу. В запрос добовляеться elemmatch при фильтрации. Кто сталкивался хелп понять что делать)

☝️ Можно написать своё кастомное правило для твоей задачи:

https://github.com/dotansimha/graphql-eslint/blob/master/docs/custom-rules.md

Всем ку. Вопрос такой. Используем для .net либу для gql сервера, где создаём класс с мутациями. Либа не позволяет регать два класса с мутациями. Это в принципе спецификация gql не позволяет так делать?

Схема как я понимаю не может содержать два типа мутаций?

Да, есть только три корневых узла — query, mutation, subscription

Но на втором уровне можно сколько угодно 🙂

Понял. Надо курить матчасть. Спасибо

Это получается расчёт на то, что эндпоин должен содержать запросы и мутации к какому то одному домену например?

Наоборот, в схеме их всего три, а все остальное — вложено. Если хочется прямо разделить — нужны отдельные схемы (и, вероятно, отдельные транспортные эндпоинты)

Есть также federation, которое более явно разделяет по сервисам

Всем привет. Есть такой json объект { "id":1,"data":"123981248123", "array":[{"id":1,"data":"22222222"}] для graphql нормально делать такие схемы со вложенностями. Или по старой доброй делать через ключ?

Я пробовал держать глобальный даталоадер, а не в рамках контекста одного запроса. Это больно.
В реализации автора gqlgen используется map, потому она кеширует и нужно этот кеш очищать руками.

{
    users(first: 10) {
        id
        name
        allBooks {
            id
            name
        }
    }
}

{
    users(first: 10) {
        id
        name
        books(first: 5) {
            id
            name
        }
    }
}

Даталоадеры обычно тянут энтити по id. В данном случае для получения книг, совсем никак нельзя передавать айдишники пользователей в даталоалер. Получается смешанная логика, потом через полгода никто не разберет что написано.

В твоем случае надо на уровне users для каждого пользователя иметь массив айдишников книг. Для этого надо залазить в 4ый аргумент инфо и проваливаться в аргументы поля books, чтоб запросить нужное кол-во книг.

А уже в самом резолвере books из первого аргумента source считывать массив айдишников необходимых книг. И передавать их в дата-лоадер booksDataLoader.loadMany(booksIds).

Либо полениться и схитрить: на уровне users запрашивать к примеру 10 айдишников книг. А уже в резолвере books срезать кол-во вытаскиваемых книг из даталоадера, согласно args.first. Но это костыль, чтоб не ковыряться в info на уровне резолвера users.

ЗЫ. Создавать даталоадеры под каждый запрос нормальная практика. Особенно, когда даталоадер завязан на ограниченный список полей, который необходимо дернуть из базы согласно полей которые указал пользователь в своем graphql-запросе. Лучше потратить чутка CPU на инициализацию DL, чем по сети гонять вагон данных.

PSS. Ну а вообще надо прояснить для себя, что DL может быть 3рех видов (скоупов):
- на весь сервер (все пользователи могут получать одни и те же данные)
- на контекст запроса (даталоадер привязан к пользователю, разграничение по правам)
- на контекст запроса и конкретного поля в graphql-запросе (привязка не только к контексту ну и набору полей, которые будут дергаться из базы даталоадером).

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

Почему нельзя вынести в разные компоненты нужные данные и потом импортировать в одну?

если не будет при этом включен network policy - network, то обновится в массиве только запись о конкретной сущности, не перетирая весь кеш

> Даталоадеры обычно тянут энтити по id.

Вопрос скорее философский, но вроде бы dl принимает на вход именно key, который может быть еще и составной. Т.е. получается что-то вроде "дай мне данные, вот ключ", а что за данные и что за ключ не имеет значения 🙂 В нашем случае ключ это идентификатор пользователя.


> В твоем случае надо на уровне users для каждого пользователя иметь массив айдишников книг. Для этого надо залазить в 4ый аргумент инфо и проваливаться в аргументы поля books, чтоб запросить нужное кол-во книг.

Да, это хороший вариант, но у меня golang 🙁 Нужно конечно покопаться в либе, но с ходу того самое info нет, только args и ctx 🙂

> Либо полениться и схитрить: на уровне users запрашивать к примеру 10 айдишников книг. А уже в резолвере books срезать кол-во вытаскиваемых книг из даталоадера, согласно args.first. Но это костыль, чтоб не ковыряться в info на уровне резолвера users.

Да, думал над таким вариантом, но кроме first будет еще sort 🙁

> ЗЫ. Создавать даталоадеры под каждый запрос нормальная практика.
Если не нужен кеш как опция даталоадера. Хотя никто конечно не запрещает его реализовать сбоку.

> на контекст запроса и конкретного поля в graphql-запросе
Пока склоняюсь к этому решению 🙂

Спасибо всем за помощь, не ожидал что кого-то заинтересует вопрос 🙂

А нельзя их как то в кеш записывать под разными ключами Результат 1 и  Результат 2 ?

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