Are directives always applied to the schema and can be used as a middleware to restrict access?

https://www.apollographql.com/docs/apollo-server/schema/creating-directives/#enforcing-access-permissions

I was reading the article above, and It says this:

One drawback of this approach is that it does not guarantee fields will be wrapped if they are added to the schema after AuthDirective is applied

but I am not sure if this means that directives are not guaranteed to be applied or not to each field in the schema.

I believe this is merely noting that a schema is a JavaScript object that can in theory be transformed after it has been initialized — though GraphQLSchemas are intended to be immutable (they are according to their typings, there’s conceivable ways of working around this at runtime). It’s important to be clear about things like this in documentation, particularly when it’s pertaining to auth concerns.

If you are doing some exotic transformation the schema after it’s been built (e.g., something like schema.getType('Foo').getFields()['bar'] = ...), then you’d want to make sure the schema is re-visited (the visitor functions apply a AST “visit” pattern to the way they traverse and apply their transformations).

If you’re not changing the schema after it’s passed to ApolloServer — as is typically the case — you should not need to worry about this subtlety/word-of-caution.

Does that make sense?

Is there any documentation out there that describes field wrapping? I’ve been working with GraphQL for a while now but I admit (sheepishly) that I’m not sure what this concept gets at. (If you Google “graphql field wrapping” you basically get posts about how to use GraphQL as a wrapper for a traditional JSON REST API…) I understand GraphQL wrapper types, but I’m pretty sure that’s not what the graphql-tools docs is talking about.

I recently switched us to the new graphql-tools API (we were using SchemaDirectiveVisitor from the previous version of Apollo Server) and have been working on hoisting our auth directives up to the object type level (though they can still appear at the field level), and I’m trying to understand why our auth directive doesn’t seem to be firing in certain cases. We assemble our schema dynamically (sort of like the graphql-tools schema loaders but we rolled our own) and it is not modified after being passed to the Apollo Server constructor, and I just want to rule out the schema construction as the reason why the auth directive isn’t producing the result I expect in certain cases.