Feature Request: high level API for implementing executable directives

[jaminhaber]

request

Hello!

I have been messing around with SchemaDirectiveVisitor and I noticed that it allows the location to be set to "FIELD" but it does not support implementing field directives. Directives like the default @skip and @include are very helpful for building a flexible graphql API.

I was wondering if there are any plans to support query directives that can be called by the client?

I see it mentioned 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.'

it also seems like someone posted a pull request for that a while back as well https://github.com/apollographql/apollo-server/issues/3121

example

here is an example of what an upperCase directive would look like

schema

type User {
   name: String
 }

query (from client)

user {
   name
   upperName: name @upperCase
}

should result in

{
   name: "john cena",
   upperName: "JOHN CENA"
}

Thank you!

[glasser]

For what it's worth: SchemaDirectiveVisitor is actually part of the separate graphql-tools project. While Apollo Server 2 lets you pass schemaDirectives to its constructor, it's just passed on to a graphql-tools function. In the forthcoming Apollo Server 3 we're dropping this pass-through and letting you just call the graphql-tools function directly if you'd like; this means you can upgrade to the newest version of @graphql-tools/schema rather than being locked in to whatever version AS links. (Also, graphql-tools has a newer alternative to schemaDirectives which it now considers to be "legacy".)

Apollo Server doesn't have any high-level ways of handling query directives (also called executable directives), but you can add code to your resolvers that is sensitive to directives. For example, in a resolver you can look at info.fieldNodes and see if there are directives on any of the nodes; perhaps you may want to wrap your resolvers in order to do the transformations you've described.

The docs you've quoted will probably be removed in AS3 because we're dropping the pass-through support for schemaDirectives. I'll leave this issue open as a feature request for easier ways to handle executable directives.

[kevin-lindsay-1]

Definitely a +1 from me on this, I originally used directiveResolvers because of how clean and easy to use they were, and when they were deprecated in favor of SchemaDirectiveVisitors I had a bunch of trouble getting it to work cleanly, due to the aforementioned "stepping on toes" of @graphql-tools and apollo-server.

That, and the combination of things like federation and loading schemas via @graphql-tools/load made things pretty confusing from a setup process, because instead of piping one output into another, you need to cherry-pick outputs in a way that no guide really tells you how to do.

It really feels like there's no go-to comprehensive example of setting up a server with all of the options enabled; there's lots of tutorials telling you how to do each one in isolation, but there's no definitive guide on setting up a basic service with something like the following:

• schemas in .gql
• resolvers in a resolvers directory, exported as a simple map for all of them
• schema directives
• federating to a gateway
• support for an OIDC-compliant JWT & RBAC directives

To me, this seems like a pretty standard setup that would cover 80-90% of use cases, and yet the docs don't really seem to have a simple preferred example for a fairly comprehensive "go-to" server setup.

I don't for a second think I'm doing anything non-standard in my setup, but right now pretty much every single one of those bullet points has no "preferred" solution. Most everybody in the forums and GH seem to be trying to do the same things, but so often when trying to get their bearings somebody will always preface a solution with "this just how I did it".

Right now it feels like there's a lot standard pieces in apollo-server, but no reference server setup that people can choose to deviate from; feels like you have to deviate/hack right off the bat because there's not really a comprehensive reference implementation.

[theogravity]

I found this doc as a good starting point

https://docs.nestjs.com/graphql/migration-guide#directives

[trevor-scheer]

Apollo Server continues to be impartial to how you create your GraphQLSchema, and @graphql-tools has done a good job of providing schema creation / manipulation functionality to the community.