Lidando com directives de tipo schema

Gato GraphQL é um servidor code-first, ou seja, utiliza código para desenvolver o schema. (A alternativa é a abordagem SDL-first, que usa o Schema Definition Language para primeiro produzir o schema e depois desenvolver o serviço).

Por não ter um SDL, servidores code-first não conseguem suportar directives de tipo schema de forma nativa. Para contornar essa limitação, o Gato GraphQL desenvolveu o seguinte mecanismo:

• Transformar a query de solicitada para executável
• Aplicar regras IFTTT à query executável

Isso resulta em suporte completo a directives de tipo schema no servidor GraphQL.

​

Por que funciona?

@deprecated é uma directive de tipo schema, portanto deve ser aplicada no schema. No entanto, o que aconteceria se fingíssemos por um momento que ela é uma directive de tipo query e adicionássemos @deprecated em algum campo diretamente na query?

Por exemplo, ao executar esta query:

query {
  posts {
    id
    title
    content @deprecated(reason: "Use newContent instead")
  }
}Copy

Bem, também poderia funcionar! Porque, afinal, uma directive é apenas uma funcionalidade a ser executada no campo; declarar essa funcionalidade via schema, ou diretamente na query, não faz com que a funcionalidade se comporte de forma diferente.

Agora, mesmo que funcione, não faz sentido algum. Não podemos forçar nossos clientes a adicionar @deprecated às suas queries. Essa é uma funcionalidade decidida pela aplicação no lado do servidor, não pelo cliente.

No entanto, a funcionalidade em si ainda funciona. Portanto, do ponto de vista funcional, não importa se a directive é adicionada ao schema ou à query. Além disso, toda directive eventualmente acabará presente na query, já que é lá que ela é executada.

Portanto, se o servidor não tem um SDL, ele ainda pode incorporar a directive na query, em tempo de execução.