Obsługa dyrektyw typu schema

Gato GraphQL jest serwerem code-first, czyli używa kodu do tworzenia schematu. (Alternatywą jest podejście SDL-first, które używa Schema Definition Language do najpierw wyprodukowania schematu, a następnie tworzenia usługi).

Ponieważ nie posiada SDL, serwery code-first nie mogą naturalnie obsługiwać dyrektyw typu schema. Aby uniknąć tego ograniczenia, Gato GraphQL opracował następujący mechanizm:

• Przekształcanie zapytania z żądanego na wykonywalne
• Stosowanie reguł IFTTT do wykonywalnego zapytania

Skutkuje to pełną obsługą dyrektyw typu schema na serwerze GraphQL.

​

Dlaczego to działa?

@deprecated jest dyrektywą typu schema, więc musi być stosowana na schemacie. Co jednak by się stało, gdybyśmy na chwilę udawali, że jest to dyrektywa typu query i dodali @deprecated bezpośrednio do jakiegoś pola w zapytaniu?

Na przykład, podczas wykonywania tego zapytania:

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

Cóż, to też mogłoby działać! Bo przecież dyrektywa to tylko pewna funkcjonalność do wykonania na polu; zadeklarowanie tej funkcjonalności przez schemat lub bezpośrednio w zapytaniu nie powoduje, że funkcjonalność zachowuje się inaczej.

Jednak choć to działa, to nie ma żadnego sensu. Nie możemy zmuszać naszych klientów do dodawania @deprecated do ich zapytań. To funkcjonalność decydowana przez aplikację po stronie serwera, nie przez klienta.

Niemniej jednak sama funkcjonalność nadal działa. Dlatego, z funkcjonalnego punktu widzenia, nie ma znaczenia, czy dyrektywa jest dodana do schematu, czy do zapytania. Co więcej, każda dyrektywa w końcu znajdzie się w zapytaniu, ponieważ tam właśnie jest wykonywana.

Dlatego jeśli serwer nie ma SDL, nadal może osadzić dyrektywę w zapytaniu, w czasie wykonania.