Избегает ли GraphQL объектов передачи данных?
Насколько я понимаю, Объекты передачи данных (DTO) обычно представляют собой небольшие, плоские, сериализуемые объекты без поведения, основным преимуществом которых является простота транспортировки по сетям.
GraphQL имеет следующие аспекты:
- поощряет обслуживание богатые графы объектов, что (по крайней мере, в моей голове) противоречит «плоской» части DTO,
- позволяет клиентам выберите именно те данные, которые они хотят, который обращается к "небольшой" части,
- возвращает Объекты в стиле JSON, который обращается к "не зависимым от поведения" и "сериализуемым" частям.
Исключают ли друг друга GraphQL и шаблон DTO?
Вот что привело к этому вопросу: мы представляем архитектуру микросервисов со шлюзом. Я разрабатываю один API, который вписывается в эту архитектуру, которая будет обслуживать (среди прочего) геометрия. Во многих (скорее всего, в большинстве) случаев геометрия не будет полезна для клиентских приложений, но будет иметь решающее значение в других, поэтому их необходимо обслуживать. Несмотря на то, что они сериализованы, геометрия может быть большой, поэтому предоставление клиентам возможности отказаться от них может значительно сэкономить полосу пропускания. RESTful API, которые я видел для обработки геометрии, делают это, предоставляя параметр "returnGeometry" в строке запроса. Мне никогда не нравился такой подход, и я изначально предполагал, что будет обслуживать достаточно глубокий набор связанных / вложенных возвращаемых объектов, от многих из которых клиенты предпочтут отказаться. Все это привело меня к рассмотрению интерфейса GraphQL. По мере развития дизайна я начал рассматривать возможность сглаживания вывода (полностью или частично), что привело меня к рассмотрению шаблона DTO. Итак, теперь мне интересно, не лучше ли было бы все сгладить в DTO и пропустить GraphQL (в пользу REST, я полагаю?). Я рассмотрел золотую середину с DTO, обслуживаемыми с использованием GraphQL, чтобы клиенты могли выбирать атрибуты, которые им нужны, но мне интересно, неуместно ли это смешивание шаблонов и технологий.
Ответы 1
Я думаю, что стоит различать 2 типичных варианта использования GraphQL и скрытый третий вариант использования, который объединяет первые два.
Однако во всех трех случаях сама природа GraphType состоит в том, чтобы выборочно решать, какие поля вы хотите отображать из объекта вашего домена. Звучит знакомо? Должен, вот что такое DTO. GraphQL или нет, вы не хотите, например, открывать поле «пароль» в своей таблице «Пользователи», поэтому вам нужно так или иначе скрыть его от клиентов.
Это возможно благодаря тому факту, что GraphQL не делает никаких предположений о вашем уровне сохраняемости и дает вам инструменты для обработки ваших типов ввода / запросов по вашему усмотрению.
1.Конечная точка GraphQL, доступная напрямую клиентам (например, в Интернете, на мобильных устройствах):
В этом случае вы должны использовать любой клиент GraphQL, чтобы напрямую общаться с вашей конечной точкой graphql. DTO здесь - это фактические объекты GraphType, которые структурированы в зависимости от полей, которые вы добавили в свои открытые GraphTypes.
Внутри вы должны использовать преобразователи полей для преобразования вашего DTO в объект вашего домена, а затем использовать свой репозиторий для его сохранения.
Преобразование DTO происходит внутри преобразователя полей GraphType.
GraphQL --> DTO --> Domain Entity --> Data Store
2.Конечная точка REST, доступная клиентам, которые внутренне используют конечную точку GraphQL:
В этом случае ваши веб-клиенты и мобильные клиенты работают с традиционными DTO через REST. Однако контроллеры подключаются к конечной точке GraphQL с внутренним доступом - в отличие от варианта использования №1 - чьи GraphTypes являются точным отображением сущностей вашего домена, включая поле пароля!
Преобразование DTO происходит в контроллере перед, вызывающем конечную точку.
DTO --> Domain Entity --> GraphQL --> Data Store
3. Объединение 1 и 2
Это вариант использования, когда вы переключаете свою архитектуру с одной на другую и не хотите ломать вещи для клиентов-потребителей, поэтому вы оставляете оба варианта открытыми и в конечном итоге списываете один из них.
Надеюсь это поможет!
Да вы все правильно читаете! Это совершенно нормально и согласуется с хорошим моделированием предметной области (с DTO или эквивалентом).
Мой вопрос был нацелен конкретно на ваш сценарий №1, в котором клиенты общаются напрямую с конечной точкой GraphQL. Он спрашивает, допустимо ли в таком сценарии предоставить серию плоских классов и использовать GraphQL, чтобы позволить клиентам выбирать, какие классы (и их свойства) они хотят получить. Я думаю, ваш ответ предполагает, что да, это нормально. Я правильно читаю?