Our project needs a few blocked fields on our schema not exposed to our clients. We implemented using BlockedFields to success. However, one thing desired was something more declarative in the SDL so one easily understands a field isn't part of the external schema right in the SDL. A directive seems like a nice way to accomplish this desire.

One challenge we faced implementing our custom directive was the RuntimeWiring is built, field visibility and directives included, before directives are processed. This prevented us from using BlockedFields directly. So we made our own custom GraphqlFieldVisibility which holds a Set of field patterns to block. As the directive is processed we add to this Set so when the respective getFieldDefinitions or similar on the GraphqlFieldVisibility is called it does not return the blocked fields.

Personally I worried this would assume too much about our usage or be incompatible with some of the library. I'm not sure if I'm still concerned looking more into our project and the library itself, but I'm writing this to see if others like the idea and if it's something to pursue. It certainly was compelling to us. Perhaps there's a better or more sustainable way to implement it though?

For extra demonstration, here's how it looks in our project now using an example from the above documentation in the example project schema

# A mechanical creature in the Star Wars universe.
type Droid implements Character {

    appearsIn: [Episode]! @blocked_field

}