Por que é GraphQL Variável Mutation Sintaxe Assim redundante?

votos
0

Consultas GraphQL / mutações são super limpo: eles requerem apenas o que eles realmente necessitam , nada mais. Ou pelo menos os mais básicos são.

Mas se você usar variáveis ​​com qualquer um, em seguida, sua sintaxe inevitavelmente tem redundância nele:

query HeroNameAndFriends($episode: Episode) {
  hero(episode: $episode) {
    name
    friends {
      name
    }
  }
}

Observe o $episode: Episodee episode: $episode. A coisa é CADA mutação GraphQL exige esta mesma redundância: se você usar variáveis, cada argumento deve ser definido duas vezes (e se você estiver fazendo programáticas consultas, você, sem dúvida, são o uso de variáveis).

Minha pergunta é: por quê? Parece tão desnecessário fazer todo mundo que usa GraphQL tem que repetir seus argumentos pela segunda vez.

Porque não basta fazer a sintaxe:

query HeroNameAndFriends() {
  hero(episode: Episode) {
    name
    friends {
      name
    }
  }
}

ou se o seu realmente precisa para permitir diferentes nomes de variáveis, permitem uma terceira parte opcional:

query HeroNameAndFriends() {
  hero(episode: Episode : $episode) {
    name
    friends {
      name
    }
  }
}

Para ser claro, eu entendo que consultas de variáveis ​​usando são diferentes dos não-variáveis, mas o que eu estou perguntando sobre é, por que escolher uma sintaxe para as consultas que obriga todos a se repetir?

Ele parece tão ... não seca! Certamente eu estou faltando uma razão importante pela qual esta repetição é necessária?

Publicado 10/10/2019 em 00:47
fonte usuário
Em outras línguas...                            


1 respostas

votos
2

Por que eu tenho para listar meus argumentos em uma função JavaScript? Não é óbvio que a função

const getFullName = () => firstname + ' ' + lastname;

recebe dois argumentos, um chamado firstnameum chamado lastname? Bem, eu acho que aqui é fácil de ver através mas há casos mais complicados em que não é tão óbvio. Agora, o exemplo acima parece estranho, mas existem algumas linguagens de programação funcional em que expressões como (_ + 2)e _.concat(_)são expressões de função válido. E você pode criar algum código bastante desagradável (olhando para você, ponto livre Haskell). Mas um monte de línguas parecem pensar que declarar a entrada de um pedaço de código de forma explícita é uma boa idéia.

Voltar para GraphQL: Vamos olhar para alguns usos mais complicados de variáveis ​​porque as variáveis ​​são realmente uma implementação variável completa. Você pode fazer mais com eles em seguida, basta aplicá-los a um argumento:

query NestedInput($name: String) {
  user(where: { name: { contains: $name } }) { ... }
}

query WithDirective($long: Boolean) {
  users {
    name
    bio @include(if: $long)
    friends(showAll: $long) {
      name
    }
  }
}

Então variáveis ​​pode ser usado em um monte de lugares e também ser usado várias vezes. E consultas não seldomly GraphQL se tornar muito grande. Será que este trabalho com a segunda sintaxe que você propôs? Sim, mas acho que a legibilidade sofreria. DRY não se trata de reduzir a quantidade de caracteres que você tem que digitar, mas sobre a redução de erros. Mas muitas vezes ser explícito sobre as coisas também pode reduzir os erros (por exemplo, um monte de sistemas do tipo nos dias de hoje são sobre ser explícito sobre os parâmetros de entrada e seus tipos).

Então eu acho que era simplesmente um comércio de decisão que foi tomada pelos desenvolvedores do GraphQL e eles escolheram a versão explícita. Não se esqueça o contexto: GraphQL foi criado no Facebook, uma das maiores aplicações web no mundo.

Uma vez que os benefícios da explicitação não são óbvias aqui é uma edição que lista alguns:

  • A declaração permite que um desenvolvedor para entender rapidamente todas as variáveis ​​e seus tipos correspondentes em uma consulta.
  • GraphQL desenvolvedor de ferramentas não tem inferir cara do tipo das variáveis ​​do esquema e, em vez pode simplesmente pesquisar o tipo de entrada.
  • Mensagens de erro ficar mais fácil de entender, imagine o argumento showAllnão leva booleans mas ints. Com a declaração, podemos dizer mismatching types for variable $long. $long is Boolean but expected Int. Se não for declarado que teria que dizer $long is sometimes used as Boolean, sometimes as Int. E se nós usá-lo como três tipos diferentes?
  • Consultas quebrando poderia ser detectado por GraphQL única análise estática de código: Novamente imaginar que mudar o tipo de showAllpara Int. Neste caso, a consulta pode ser detectado como errado, enquanto que sem a declaração de tipo explícita a consulta pode em vez quebrar em tempo de execução.
Respondeu 10/10/2019 em 01:32
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more