Есть ли способ указать тип в качестве входных данных для мутации без использования типа ввода в AppSync?

У меня проблема, связанная с мутацией / подпиской на AWS Appsync с использованием локального источника данных (т. Е. Источника данных типа NONE). Мне нужно скормить мутацию данными, определенными в схеме как type, и они содержат несколько полей (некоторые другие type также находятся внутри). Назовем это Profile

type Profile {
  id: ID
  name: String
  address: Address
  email: String
}

type Address {
  street: String
  number: String
  city: String
  zipcode: Int
}

Profile уже присутствует в схеме как type, потому что он используется в Подписке. Для этого, следуя правилам AppSync, мне нужно создать input и воссоздать все поля из исходного type, назовем его InputProfile.

input InputProfile {
  id: ID
  name: String
  address: InputAddress
  email: String
}

type InputAddress {
  street: String
  number: String
  city: String
  zipcode: Int
}

Теперь я не хочу просто дублировать все поля и подполя из исходных данных Profile, но я хотел бы просто использовать это прямо как-то. Это происходит из-за необходимости не иметь дубликатов (Profile и InputProfile), а просто иметь все поля в одном type. Таким образом, его будет легче поддерживать, и если возникнут какие-либо изменения, модификация может быть сделана в одной и той же точке кода, а не в двух точках, что приведет к возможным несоответствиям или ошибкам.

В дополнение к этому, обратите внимание, что для достижения этого результата также необходимо продублировать любое сложное подполе (то есть другое type) в Profile с соответствующим input в InputProfile. Как вы могли догадаться, это приводит к бесполезному количеству дубликатов, которых следует избегать.

Я также пытался скормить мутацию напрямую с помощью Profile, но AppSync выдает ошибку, поскольку ожидает, что это будет input.

Есть ли у вас какие-либо советы по преодолению этой проблемы и не могли бы вы предложить более удобное и элегантное решение?


person Riku92    schedule 09.10.2020    source источник
comment
Я бы посмотрел этот ответ, поскольку он более о решении, принятом спецификацией GraphQL, чем о чем-либо другом.   -  person Nader Dabit    schedule 11.10.2020
comment
@NaderDabit согласен с вами. Итак, с вашей точки зрения, это часть дизайна GraphQL, и это не предназначено для других способов (т.е. дублирование неизбежно в определенной степени)?   -  person TantrixRobotBoy    schedule 12.10.2020
comment
@TantrixRobotBoy Да, это мое понимание и интерпретация. Если вы погуглите, вы увидите еще несколько разговоров об этом с некоторыми интересными моментами.   -  person Nader Dabit    schedule 12.10.2020