Блог

Я не могу понять, как GraphQL может свести к минимуму количество вызовов для получения данных с нескольких конечных точек. Например, у нас есть 2 конечные точки :

1. тот, который предоставляет информацию о посте, включая идентификатор автора по идентификатору поста

socialmedia.com/posts/:postid

2. другой, который предоставляет информацию об авторе поста по идентификатору пользователя

socialmedia.com/authors/:authorid

Мой вариант использования заключается в том, что я сначала получаю идентификатор автора из сведений о публикации, а затем сведения об авторе на основе идентификатора автора. Если бы я был клиентом rest, я бы сделал 2 звонка на 2 эти конечные точки.

Как это можно свести к минимуму при использовании graphql?

Это действительно зависит от того, как вы настроили свою схему GraphQL. Но давайте предположим, что в вашей схеме есть два типа:

 type Author {
 id: ID!
 name: String
 posts: [Post!]
}

type Post {
  id: ID!
  body: String
  author: Author!
}

 

Таким образом, у Автора много Постов, а у Поста один Автор. Для примера давайте также предположим, что у вас есть запрос верхнего уровня, который позволяет вам получить все сообщения:

 query Query {
 allPosts: [Post!]
}
 

Теперь предположим, что вы хотите загрузить все сообщения вместе с именем автора. Ваш запрос может выглядеть следующим образом:

 query AllPostsWithAuthors {
  allPosts {
    id
    body
    author {
      id
      name
    }
  }
}
 

Сервер должен разрешить этот запрос и предоставить именно ту информацию, которую вы запросили, и все это за один раз туда и обратно.
Но опять же — это зависит от того, как вы настроили свою схему. Сам по себе GraphQL-это всего лишь спецификация, и при этом довольно простая. Я вижу, как многие люди (включая меня) борются со «сменой парадигмы», чтобы мыслить в терминах графиков, а не в терминах ресурсов и конечных точек, и в конечном итоге они разрабатывают API-интерфейсы с ребяческим мышлением, завернутые в GraphQL, и результат не очень хороший. Я настоятельно рекомендую эту статью: https://graphqlme.com/2017/11/11/build-better-graphql-apis-thinking-in-graphs/