Graphql-tools: Query Directives

[ericclemmons]

👋 I've attempted to implement query directives before eventually finding this in the docs:

We believe confining this logic to your schema is more sustainable than burdening your clients with it, though you can probably imagine a similar sort of abstraction for implementing query directives. If that possibility becomes a desire that becomes a need for you, let us know, and we may consider supporting query directives in a future version of these tools.

– https://www.apollographql.com/docs/graphql-tools/schema-directives.html#What-about-query-directives

⭐️ At Starbucks we do a great deal of prototyping the UI across multiple environments, which usually means coordinating various "test" schema changes for deployment to be leveraged by several teams (most of which writing native Android or iOS code).

🏃‍♀️💨 As a result, I was working on enabling several query directives to expedite the prototyping process before "wiring up" the _real_ schema afterwards:

• @_(groupBy: "category") for transforming an array to key/value pairs
  (https://github.com/APIs-guru/graphql-lodash)

• @mock directive for replacing existing properties for easier prototyping by bypassing expensive API calls or using explicit values to see how a very long name appears, for instance:

  {
  user {
    balance @mock(value: "${{random.number}}")
    name @mock(value: "{{name.title}} Joey Joe Joe Junior Shabadoo, Esq.")
  }
  }
  

• @log directive that attaches resolver-specific logs to the extensions object for insights to that call.

• @trace directive that attaches tracing data to a specific resolver.

• @flatten directive that basically does what normalizr & other libs do to reduce payload size.

⏲ Most of these are intended only for development, so the run-time impact isn't a factor. But, the problem with graphql-lodash is that there's not a means of optionally _bypassing_ a resolver, which is helpful for bypassing expensive of problematic downstream calls.

🤔 If it's possible to, in development, dynamically extend every FIELD_DEFINITION | SCALAR with these directives, then perhaps that's a workaround.

💪 But I'd to be able to allow clients to leverage built-in query directives to manipulate the payload to match the UI's ideal expectations, then formalizing the result into a proper schema for production.

💬 Let me know how I can help make this happen!

[ericclemmons]

Some related projects, but couldn't get either to (1) work or (2) show up in GraphiQL autocomplete. (Though I did see that schema._directives had the new directive!)

• https://github.com/smooth-code/graphql-directive/
• https://github.com/lirown/graphql-custom-directives

[ahouzzer]

Any new progress on this?

[apalazzin]

Any new progress on this?

UP!

[yaacovCR]

Query directives are out of scope for this package as this package provides, in general, schema tools. Query directive work belongs in server/client packages, including ApolloServer, see linked issue above related to @defer