# Are directives always applied to the schema and can be used as a middleware to restrict access?
**URL:** https://community.apollographql.com/t/are-directives-always-applied-to-the-schema-and-can-be-used-as-a-middleware-to-restrict-access/301
**Category:** Server
**Tags:** server
**Created:** [June 2, 2021, 5:30pm UTC](https://community.apollographql.com/t/are-directives-always-applied-to-the-schema-and-can-be-used-as-a-middleware-to-restrict-access/301 "2021-06-02T17:30:23Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Jalil\_Bengoufa](https://community.apollographql.com/u/Jalil_Bengoufa)
#### Post date: [June 2, 2021, 5:30pm UTC](https://community.apollographql.com/t/are-directives-always-applied-to-the-schema-and-can-be-used-as-a-middleware-to-restrict-access/301/1 "2021-06-02T17:30:23Z")
[https://www.apollographql.com/docs/apollo-server/schema/creating-directives/#enforcing-access-permissions](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.
---
### Author:  [@abernix](https://community.apollographql.com/u/abernix)
#### Post date: [June 8, 2021, 7:33am UTC](https://community.apollographql.com/t/are-directives-always-applied-to-the-schema-and-can-be-used-as-a-middleware-to-restrict-access/301/2 "2021-06-08T07:33:28Z")
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 `GraphQLSchema`s 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?
---
### Author:  [@mdecurtins](https://community.apollographql.com/u/mdecurtins)
#### Post date: [March 7, 2022, 6:31pm UTC](https://community.apollographql.com/t/are-directives-always-applied-to-the-schema-and-can-be-used-as-a-middleware-to-restrict-access/301/3 "2022-03-07T18:31:20Z")
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.