Gestione delle direttive di tipo schema

Gato GraphQL è un server code-first, ovvero utilizza il codice per sviluppare lo schema. (L'alternativa è l'approccio SDL-first, che utilizza lo Schema Definition Language per produrre prima lo schema e poi sviluppare il servizio).

Poiché non dispone di un SDL, i server code-first non possono supportare in modo naturale le direttive di tipo schema. Per evitare questa limitazione, Gato GraphQL ha sviluppato il seguente meccanismo:

• Trasformare la query da richiesta a eseguibile
• Applicare le regole IFTTT alla query eseguibile

Ne deriva un supporto completo per le direttive di tipo schema sul server GraphQL.

​

Perché funziona?

@deprecated è una direttiva di tipo schema, quindi deve essere applicata sullo schema. Tuttavia, cosa accadrebbe se fingessimo per un momento che sia una direttiva di tipo query e aggiungessimo @deprecated su un certo campo direttamente nella query?

Ad esempio, durante l'esecuzione di questa query:

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

Ebbene, potrebbe funzionare anche così! Perché, in fondo, una direttiva non è altro che una funzionalità da eseguire sul campo; dichiarare tale funzionalità tramite lo schema, o direttamente nella query, non fa comportare la funzionalità in modo diverso.

Ora, anche se funziona, non ha alcun senso. Non possiamo costringere i nostri client ad aggiungere @deprecated alle loro query. Si tratta di una funzionalità decisa dall'applicazione lato server, non dal client.

Tuttavia, la funzionalità stessa continua a funzionare. Pertanto, dal punto di vista funzionale non importa se la direttiva venga aggiunta allo schema o alla query. Inoltre, ogni direttiva finirà prima o poi per essere presente nella query, dato che è lì che viene eseguita.

Quindi, se il server non dispone di un SDL, può comunque integrare la direttiva nella query, in fase di esecuzione.