Decoupling requested and executable queries

Gato GraphQL uses a directive pipeline, an architecture that enables the server's engine to resolve, validate, and execute the query. In order to make the engine as simple as possible, every action concerning the resolution of the query takes place within the pipeline, through directives.

Calling the resolver to validate and resolve a field, and merge its output into the response, is accomplished through a couple of special directives: @validate and @resolveValueAndMerge. These directives are of a special type: they are not added by the application (on either the query or the schema) but by the engine itself. These 2 directives are implicit, and they are added always, on every field of every query.

From this strategy we can see that, when executing a query on the GraphQL server, there are actually 2 queries involved:

• The requested query
• The executable query

The executable query, which is the one to be ultimately resolved by the server, is produced from applying transformations on the requested query, among them the inclusion of directives @validate and @resolveValueAndMerge for every field.

For instance, if the requested query is this one:

{
  posts {
    url
    title @uppercase
    content @include(if: $addContent)
  }
}Copy

The executable query will be this one:

{
  posts @validate @resolveValueAndMerge {
    url @validate @resolveValueAndMerge
    title @validate @resolveValueAndMerge @uppercase
    content @validate @include(if: $addContent) @resolveValueAndMerge
  }
}Copy

​

Where is it used

Gato GraphQL uses this mechanism to produce the executable query, in the following circumstances:

• Adding system-type directives (such as @validate and @resolveValueAndMerge)
• Adding any directive through IFTTT through directives
• Defining a strict field-execution order for Multiple Query Execution