Если вы новичок в GraphQL, настоятельно рекомендую ознакомиться с моей предыдущей статьей. В этой статье мы более подробно рассмотрим типы и запросы graphql. Требования для запуска такие же, как упоминалось в предыдущей статье.
Поскольку аннотация autowire необязательна, первое, что я сделал, это заменил все аннотации @Autowire конструкторами. С Ломбоком это сделать намного проще.
Код выглядит намного чище. Больше никаких скучных геттеров и сеттеров. Теперь давайте закодируем схему graphql в соответствии с правилами GraphQL. Упоминается много правил, но мы рассмотрим некоторые из них. Сначала я решил разбить схему на несколько файлов. Чтобы сделать его более управляемым и согласованным с именами файлов *.graphqls.
Я переместил всю схему связанную с автором в author.graphqls так же, как и схему связанную с книгами. И я создал query.graphqls для всех запросов и мутаций. Благодаря graphql-java-kickstart все файлы схемы подхватились автоматически.
Типы ввода
GraphQL предлагает базовый набор скалярных типов, таких как строка. Эти базовые скаляры используются в качестве аргументов для полей и запросов. Это нормально, если у вас мало аргументов, но если их несколько, управлять ими становится утомительно. В таких случаях лучше группировать все аргументы в объекты. Именно здесь на сцену выходят типы ввода GraphQL, особенно в случае мутаций. В схеме он похож на обычные типы объектов, но для его определения используется ключевое слово input вместо type.
Давайте изменим простой запрос getBookByName, добавив тип ввода. Для этого я добавил поле filter в запрос типа BankFilter.
BankFilter содержит в схеме то же содержимое, что и класс java.
Теперь давайте создадим проект и запустим док-контейнеры, чтобы протестировать его.
mvn чистая установка
docker-compose up -d
В отличие от предыдущего, аргумент запроса filter представляет собой сложный входной объект типа BankFilter. Поэтому мы определяем его поле name внутри фигурных скобок. Это дает вам возможность добавлять будущие параметры без изменения фактического запроса.
Только из-за одного аргумента это не выглядит очень полезным. Но когда у вас есть несколько аргументов, например, для мутаций, это очень практично.
Здесь вместо нескольких аргументов один тип ввода BookInputв мутации newBook намного чище и управляемее.
Хорошей практикой является добавление уникального типа вывода к каждой мутации. Итак, давайте сделаем это.
Я создал новый тип вывода NewBook, который в данном случае идентичен типу Book. Результат запроса остается прежним.
Несмотря на то, что типы входных данных и типы выходных данных выглядят очень похоже, вы не можете смешивать оба типа в схеме. Аргументы полей также не разрешены для типов ввода.
Аргументы на полях
В GraphQL каждое поле объектов и вложенных объектов можно передавать с аргументами. Синтаксис для определения очень похож на синтаксис запроса. Это также дает GraphQL возможность выполнять несколько выборок API без особых затрат на разработку.
В реальном мире одна книга может быть написана несколькими авторами. Давайте изменим тип книги, чтобы отразить это, возвращая список авторов вместо одного. Обновленный тип книги выглядит следующим образом
Списки GraphQL определяются квадратными скобками. Теперь каждый тип книги содержит список авторов. Здесь поле автор принимает один аргумент типа order, который, в свою очередь, имеет тип enum Порядок списка. При этом мы можем решить, в каком порядке нам нужен список авторов. Аргумент полей такого типа может быть полезен для отображения упорядоченных данных для внешнего интерфейса.
Я также добавил новое поле starRating в тип автора. Этот рейтинг будет использоваться для упорядочения списка авторов в порядке возрастания или убывания.
Теперь давайте изменим класс BookAuthorResolver, чтобы разрешить список авторов с порядком аргументов поля. Все аргументы поля доступны в GraphQLResolver, поэтому я просто добавил поле порядка в метод резолвера getAuthor().
Давайте протестируем запрос getBookByName в порядке убывания.
Как и ожидалось, список авторов находится в порядке убывания starRating. Благодаря функции автоматической выборки схемы почтальон знает ожидаемые значения для поля order. Если вы попытаетесь ввести какие-то случайные значения, появится предупреждение, как показано ниже.
В таких случаях вы можете использовать запросы на самоанализ схемы, чтобы получить больше информации о типах схемы.
Поскольку аргумент поля order не является обязательным, мы можем запросить без него.
Здесь вы получаете порядок списка по умолчанию, возвращаемый authorRepository. Вы можете ознакомиться с этим проектом здесь.
Я надеюсь, что краткий обзор типов graphql поможет вам использовать более продвинутые функции graphql для создания более быстрых API.
Удачного GraphQLing!
