Разве логин не должен быть запросом в GraphQL?
В руководство при аутентификации GraphQL login - это Мутация:
type Mutation {
post(url: String!, description: String!): Link!
signup(email: String!, password: String!, name: String!): AuthPayload
login(email: String!, password: String!): AuthPayload
}
Разве логин не должен быть Запрос, поскольку:
- Операция не имеет побочных эффектов на сервере.
- Цель состоит в том, чтобы запрос токен.
Я что-то упустил?
Ответы 1
В контексте этого примера login должен быть запросом, а не мутацией, при условии, что его преобразователь не имеет побочных эффектов, по крайней мере, в соответствии со спецификацией. Однако есть несколько причин, по которым вы, вероятно, не увидите этого в дикой природе:
Если вы реализуете аутентификацию, вы, вероятно, захотите регистрировать активность своих учетных записей пользователей, либо сохраняя некоторые данные о событиях входа / выхода из системы, либо, по крайней мере, включая какое-то поле «последний вход» в запись учетной записи. Изменение этих данных было бы будет побочным эффектом.
Разработано соглашение, согласно которому любые операции, возникающие в результате действий пользователя, рассматриваются как мутации, независимо от побочных эффектов. Вы видите это с
react-apollo, например, гдеuseQueryзапускает связанный запрос при монтировании, тогда какuseMutationпредоставляет только функцию, которая может быть вызвана для запуска этого запроса. Если вы планируете использовать Apollo на стороне клиента, стоит учитывать такие клиентские функции при разработке схемы.Мутации выполняются последовательно, а запросы выполняются одновременно. Это означает, что было бы предсказуемо запустить мутацию входа в систему и одну или несколько других мутаций после нее в одном и том же вызове, что позволит вам использовать аутентифицированный контекст для последующих вызовов. То же самое нельзя сказать о запросах - если
loginявляется запросом и вы включаете с ним другие запросы в одну операцию, все они начнут разрешаться одновременно.
Вне зависимости от того, как они выполняются (последовательно или одновременно), на стороне сервера запросы и изменения фактически взаимозаменяемы. У вас могут быть запросы с побочными эффектами и мутациями без побочных эффектов. Вероятно, вам следует придерживаться соглашений, но я думаю, что иногда есть веские причины, по которым вам, возможно, придется выбросить эти соглашения из окна.
Спасибо за подробное объяснение!
Mutations are ran sequentially, while queries are ran simultaneously, это было хорошее наблюдение. Я понятия не имел об этом. Спасибо. Помогает в принятии некоторых решений о том, следует ли разрешать как мутацию или запрос.
Примечание. Теперь у Apollo есть ловушка useLazyQuery, которая не будет запрашивать данные, пока вы вручную не активируете загрузку, что очень похоже на useMutation. Но в настоящее время он не возвращает обещание (см. github.com/apollographql/react-apollo/issues/3499)
Это x 100. Если бы mutation вместо этого назывался (что, по общему признанию, менее запоминающимся) «императивным, некэшируемым запросом», было бы более очевидно, что это именно то, что вы хотите в этом сценарии. Если вам нравится обсуждать семантику, я настоятельно рекомендую переключиться на REST API, где вы можете напиться.
Приносим извинения за поздний ответ. Насколько я понимаю, мутация - это то, что при изменении ваших данных и запроса просто извлекается, поэтому вход в систему должен быть запросом. ?