Как включить метаданные запроса на мутацию в GraphQL?

Question

Я строю сервер GraphQL с нуля с помощью API-интерфейса, заменив сервер REST API. В настоящее время некоторые запросы на существующем сервере API, в основном запросы на создание / обновление, которые будут являться мутациями в GraphQL, включают идентификатор запроса, который используется клиентом. Этот идентификатор запроса представляет собой метаданные о самом запросе, который не является частью ресурса домена.

Мой вопрос: как смоделировать / включить метаданные запроса в запросы и мутации GraphQL? Мое единственное решение до сих пор состоит в том, чтобы сделать тип запроса, который другие типы могут включать в качестве поля, чтобы данные запроса могли быть включены в тип возврата мутации. Однако мне не нравится этот подход, так как он смешивает данные запроса с типами моего домена, и это очень противоречит духу GraphQL. Есть ли приемлемый способ передать «произвольный», например, данные не доменного типа в ответе на запрос или мутацию в GraphQL?

Пример - что я хотел бы избежать:

type UserType {
  id: ID
  name: String
  request: RequestType // mixing request data in with domain type of User
}

type RequestType {
  id: ID
}

Обновление

Для тех, кто интересуется этой проблемой, основываясь на ответах здесь, я решил, что ключ GraphQL extensions является хорошим вариантом для добавления произвольных данных в ответ GraphQL без того, чтобы данные стали частью вашего графа данных. В Express-GraphQL документы по добавлению ключа расширений к ответам можно найти здесь: https://github.com/graphql/express-graphql#providing-extensions. Хороший обзор расширений здесь: https://marmelab.com/blog/2017/09/06/dive-into-graphql-part-iii-building-a-graphql-server-with-nodejs.html#server-logging

Тем не менее, если метаданные запроса концептуально являются частью данных домена, то, следуя предложенному Кашифом ниже предложению о создании ResponseTypes, которые включают типы домена, может быть правильным подходом.

Answer 1

Так как GraphQL был разработан, чтобы быть независимым от протокола, вы должны использовать шаблон метаданных выбранного протокола. Если вы используете HTTP, вы должны передать заголовки. Если вы используете WS / STOMP / MQTT / AMQP, вы можете включить метаданные в каждый кадр.

В качестве альтернативы GraphQL имеет протокол расширений . Вы можете добавить request-id к своим ответам в объекте расширений. Apollo использует расширения для кэширования, телеметрии и т. Д.

Мы использовали GraphQL в производстве около года, мы сделали ошибку, добавив метаданные в GraphQL, и им становится сложно управлять. Не упустите преимущества от функций протокола, который вы используете.

Answer 2

Метаэлементы такого типа обычно передаются в заголовках с каждым запросом. И тогда вы можете обрабатывать их на своем сервере GraphQL так, как вам нравится

Например,

//Request Headers
...

X-Request-Id: <Your_Request_Id>

...

Обновление

Заголовки работают в обоих направлениях, поэтому не должно быть проблем с их использованием на клиенте. Вытащите их из ответа, когда вам нужно.

Однако, если вы действительно хотите, чтобы requestId был в вашем ответе на мутацию, то это часть вашего домена. И нет ничего плохого в том, чтобы иметь собственный тип ответа. Многие существующие API-интерфейсы GraphQL имеют собственный тип ответа, например LoginResponse, RegisterResponse, который затем оборачивается вокруг ваших доменных объектов, но также включает дополнительные элементы в meta поля