Umgang mit Schema-Typ-Direktiven

Gato GraphQL ist ein code-first-Server, d. h. er verwendet Code zur Entwicklung des Schemas. (Die Alternative ist der SDL-first-Ansatz, der die Schema Definition Language nutzt, um zunächst das Schema zu erstellen und dann den Service zu entwickeln).

Da kein SDL vorhanden ist, können code-first-Server Schema-Typ-Direktiven nicht auf natürliche Weise unterstützen. Um diese Einschränkung zu umgehen, hat Gato GraphQL den folgenden Mechanismus entwickelt:

• Die Query von angefordert zu ausführbar transformieren
• IFTTT-Regeln auf die ausführbare Query anwenden

Das Ergebnis ist eine vollständige Unterstützung für Schema-Typ-Direktiven auf dem GraphQL-Server.

​

Warum funktioniert das?

@deprecated ist eine Schema-Typ-Direktive und muss daher auf dem Schema angewendet werden. Aber was würde passieren, wenn wir kurz so tun, als wäre sie eine Query-Typ-Direktive, und @deprecated auf ein Feld direkt in der Query setzen?

Zum Beispiel bei der Ausführung dieser Query:

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

Nun, es könnte auch so funktionieren! Denn schließlich ist eine Direktive nur eine Funktionalität, die auf dem Feld ausgeführt wird; ob diese Funktionalität über das Schema oder direkt in der Query deklariert wird, ändert nichts an ihrem Verhalten.

Auch wenn es funktioniert, ergibt es keinen Sinn. Wir können unsere Clients nicht zwingen, @deprecated zu ihren queries hinzuzufügen. Das ist eine Funktionalität, die die Anwendung serverseitig entscheidet, nicht der Client.

Die Funktionalität selbst funktioniert jedoch weiterhin. Daher spielt es aus funktionaler Sicht keine Rolle, ob die Direktive dem Schema oder der Query hinzugefügt wird. Außerdem wird jede Direktive letztendlich in der Query vorhanden sein, da sie dort ausgeführt wird.

Wenn der Server also kein SDL hat, kann er die Direktive zur Laufzeit trotzdem in die Query einbetten.