Владлен Хеллсайт

Вам нужен GraphQL клиент, например urql (urql-vue) или apollo-client (vue-apollo). Если вам нужен один запрос, то можно обойтись обычным fetch, например:

const response = await fetch('https://example.com/graphql', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    operationName: 'fetchAuthor',
    query: 'query fetchAuthor { author { id name } }',
    variables: {},
  }),
});

const data = await response.json();

В GraphQL на текущий момент невозможно сделать рекурсивное дерево через вложения, даже если мы будет повторять вложения, она в любом случае будет иметь конечное количество элементов, не говоря уже про размер самого запроса (не ответа). Однако всё не так плохо как может показаться, есть решения для этой проблемы:

1. Возвращать плоский массив элементов, соответственно на клиенте можем собрать дерево.

tasks {
_id
name
status
children {
    _id
    parentId
    name
    status
}

2. Использовать кастомный скаляр, например JSON. Однако в данном случае мы теряем типизацию схемы, в виду того что в скаляре может находится что угодно.
3. Сделать резолвер, который будет фильтровать элементы по ID их родителя. Однако в данном случае, сервер будет получать много запросов, так как в дереве может находится много элементов.

Вытаскивать все рестораны оправдано если вы будете делать PWA и их будет не так много, а потом просто кидать запрос с датой последней синхронизации на поиск изменений. Однако если вы делаете публичное API, то лучше сразу реализовать поиск через аргументы в query, со временем к категориям добавятся сортировки и другие фильтры. Это придётся реализовывать на каждом клиенте отдельно.

Так скажем ваш GraphQL API сейчас работает только с вашей БД, а потом придётся делать скажем REST запросы на чужой API и вот уже вытаскивать все рестораны не так уже выгодно для сервера. Произвести всякие оптимизации будет сложно, так как мы не знаем какие данные нужны клиенту и каждый раз тащим мегабайты ради скажем ресторана с одной категорией, так как человек каждый раз заходит в инкогнито и никакого кэша там снова не будет.

const posts = [{ id: 0, message: 'foo', author: 0 }]
const users = [{ id: 0, name: 'bar', posts: [0] }]

const resolvers = {
    User: {
        posts({ id }) {
            return posts.filter(post => (
                post.author === id
            ))
        }
    },
    Post: {
        author({ author }) {
            return users.find(user => (
                user.id === author
            ))
        }
    },

    posts() {
        return posts;
    },

    users() {
        return users;
    }
};

Используйте подход Relay для решения этой проблемы, вместо того что бы описывать все аргументы в мутацию, просто сделайте input и передавайте в него нужные данные. Вот хорошая статья для прочтения.

input UpdateClubInput {
    id: ID!
    name: String
    position: String
    league: String
}

mutation {
    UpdateClub(input: UpdateClubInput!): Club
}

Мне нравится подход Relay для пагинации. Собственно толком ничем не отличается и от других условий выборки, примерно так:

query {
	users(first: 10, order: "id") {
		totalCount,
		edges {
			cursor,
			node {
				id,
				name,
				lastAt,
				avatar {
					original,
					preview
				}
			}
		},
		pageInfo {
			startCursor,
			endCursor,

			hasNextPage,
			hasPreviousPage
		}
	}
}

В этом примере получаем первые 10 записей с сортировкой по id. PageInfo хранит в себе информацию есть ли следующая/предыдущая страница и курсоры которые которые передаются в параметры before или after.