Аргументы и переменные выполняют совершенно разные функции.
Каждое поле в схеме GraphQL может быть настроено на прием одного или нескольких аргументов .Например:
query FilmQuery {
film (id: "ZmlsbXM6MQ==") {
id
title
}
}
Здесь поле film принимает аргумент с именем id. Аргументы используются для изменения значения, в котором разрешается поле. В нашем примере выше сервер возвращает другой объект Film на основе значения id, которое предоставляет клиент.
Аргументыпринять входные данные , которые могут быть скалярами, перечислениями или более сложными типами входных объектов.Здесь мы передаем строковое значение "ZmlsbXM6MQ==" аргументу.Выписывая значение внутри запроса, мы говорим, что мы используем литеральное значение .
Нет ничего плохого в том, чтобы использовать литеральные значения в ваших запросах, но когда значение передается варгумент должен быть динамическим, нам нужно что-то большее - нам нужны переменные .
Переменные позволяют нам параметризировать и повторно использовать запросы. Вот наш пример, переписанный с использованиемпеременная:
query FilmQuery($myId: ID!) {
film (id: $myId) {
id
title
}
}
Переменные должны сначала быть определены в верхней части документа, как часть определения операции.Здесь мы определили одну переменную ($myId) и сказали GraphQL, что ее тип равен ID!.После определения переменные можно использовать в любом месте операции.Фактические значения любых переменных, используемых в вашем документе, должны отправляться вместе с самим запросом, когда клиент фактически отправляет запрос на сервер.
Опять же, аргументы предоставляют только способ изменить способ запросавыполняется, в то время как использование переменных в качестве входных данных для этих аргументов делает конкретный запрос динамическим и многократно используемым.
Обратите внимание, что вы можете использовать конкатенацию строк или литералы шаблонов на стороне клиентадобиться эффекта, аналогичного тому, что делают переменные.Однако в целом следует избегать этого, поскольку 1) это излишне создает дополнительную работу для клиента и 2) самостоятельная сериализация входных данных, особенно сложных, таких как типы входных объектов, может быстро стать сложной и подверженной ошибкам.