У меня есть эскизы, сохраненные в моей базе данных в виде байтового массива. Кажется, я не могу понять, как вернуть их клиентам внешнего интерфейса через GraphQL.
В стандартном подходе REST я просто отправляю POJO обратно с байтами, и я могу легко его отобразить.
Однако попытка вернуть byte[] бросает
Unable to match type definition (ListType{type=NonNullType{type=TypeName{name='Byte'}}}) with java type (class java.lang.Byte): Java class is not a List or generic type information was lost: class java.lang.Byte
Ошибка носит описательный характер и говорит мне, что не так, но я не знаю, как ее решить.
Мой thumbnail.graphqls выглядит так:
type Thumbnail {
id: ID!
resource: [Byte!]
}
И эскиз POJO
public class Thumbnail extends BaseEntity {
byte[] resource;
}
Я использую graphql-spring-boot-starter на стороне Java для обработки вещей, и я думаю, что он поддерживает Byte из коробки, так что где я ошибся?
Очень свежо для GraphQL, так что это может быть очевидной ошибкой.
Ваше здоровье,
Я ожидал, что результат GraphQL будет выглядеть так же, как и результат запроса REST. Таким образом, byte[] будет выглядеть как строка байтов ... Просто как мне заставить GraphQL принять, что это допустимый тип ответа?




Вы должны сериализовать его в один из стандартных типов. Если вы хотите, чтобы ваш байтовый массив выглядел как строка, например «F3269AB2», или как массив целых чисел, например [1,2,3,4,5], это полностью зависит от вас.
Вы можете добиться сериализации, написав преобразователь для своей сущности, например:
public class ThumbnailResolver extends GraphQLResolver<Thumbnail> {
public String resource(Thumbnail th) { ... }
//or List<Integer> resource(Thumbnail th) { ... }
//or whatever
}
Решатель всегда имеет приоритет над вашей сущностью. Это означает, что если в классе преобразователя будет найден метод преобразователя с правильным именем, параметрами и типом возвращаемого значения, он будет вызываться вместо метода сущности. Таким образом, мы можем «переопределить» методы сущности, чтобы вернуть другой результат, даже другой тип, чем фактическое поле сущности. Используя преобразователи, мы также могли бы получить доступ к службам в области приложения и т. д., Которых у объекта обычно нет.
После написания резолвера не забудьте обновить файл схемы до:
resource: String
#or resource:[Int]
#or whatever
Ваша схема должна ссылаться на тип преобразователя, поскольку это то, что получает graphQL. В этом случае фактический тип объекта станет неактуальным для graphQL.
В качестве плана Б вы можете реализовать новый Скаляр. Это было бы похоже на изобретение нового базового типа. Это тоже не так уж и сложно. Вы можете увидеть уже существующие скалярные типы здесь и сделать что-то подобное.
Затем вы можете назвать свой новый тип ByteArray или что-то в этом роде, объявив его в своей схеме:
scalar ByteArray
а затем используйте его.
Я бы выбрал первое решение, так как его проще и быстрее реализовать.
Я думаю, ваша проблема в том, что вы пытаетесь сериализовать двоичный массив в json (я думаю, вы возвращаете json из своего контроллера). Как вы представляете, как должен выглядеть ваш ответ?