Graphql-tools: makeExecutableSchema leads to strange directive behavior

Created on 12 May 2020  路  13Comments  路  Source: ardatan/graphql-tools

Perhaps this is user error, but I noticed that running the following query when using makeExecutableSchema, the error coming back is connected to the BookInput type.

mutation {
    createAuthor(input: {
        name: "M"
    })
}

Here's a repo both with and without makeExecutableSchema used:
https://github.com/morleytatro/graphql-tools-bug

Notice the difference in results.

All 13 comments

That particular directive as implemented is no longer supported as of v5, see https://github.com/ardatan/graphql-tools/issues/842, in particular https://github.com/ardatan/graphql-tools/issues/842#issuecomment-623579618, https://github.com/ardatan/graphql-tools/issues/842#issuecomment-623721474, and https://github.com/ardatan/graphql-tools/issues/842#issuecomment-624196986

The last comment lists a few new recent alternatives for directive driven validation.

The discrepancy you are seeing is that Apollo is still internally using v4.0.7.

See also #1234 to track a new functional approach to schema directives.

Maybe we can restore support now that all non-legacy functionality does not actually use healSchema/visitSchema/visitSchemaDirectives, just by "unfixing" healSchema.

I am not sure if I quite understand it correctly.

But the following code:

const schema = makeExecutableSchema({
  typeDefs,
  resolvers,
  schemaDirectives: {
    isAuth: IsAuthDirective,
  },
});

is not working with "graphql-tools": "^5.0.0". As in, that isAuth directive is not called when querying something.

However when I install "graphql-tools": "^4.0.7", the directive _is_ called.

If this is intended, I think it is quite strange that the official Apollo docs are still suggesting to use this approach: https://www.apollographql.com/docs/graphql-tools/schema-directives/

Even more confusing is that when theIsAuthDirective is not correctly implemented graphql still throws errors. Suggesting that it will work when you make those errors vanish by fixing them.

Ah so I found out that there is another doc that state the new method I guess.

Very confusing, but I think this is the problem:

In this doc:
https://www.apollographql.com/docs/graphql-tools/schema-directives/
The suggest the use of makeExecutableSchema. Which is deprecated as far as I understand the above conversation?

But in this doc: https://www.apollographql.com/docs/apollo-server/schema/directives/ (which I guess is newer) they suggest the following method, which I guess is still supported somehow:

const server = new ApolloServer({
  typeDefs,
  resolvers,
  schemaDirectives: {
    upper: UpperCaseDirective,
  }
});

There is a regression in v5 that causes certain directives to no longer work. The examples should all still work as we have tests that ensure they still work. We plan on restoring support for all directives that worked in v4 for the next release. The next release will also suggest a new functional approach, but it should have better backwards compatibility as well.

Apollo is on v4 so they had no changes.

I am pretty sure something is up with the combination of makeExecutableSchema on an apollo server with directives. Because when I just shove the typeDefs resolvers and schemaDirectives directly into the ApolloServer options it works perfectly fine.

But I have already been debugging for like hours and hours, so I will not further investigate this problem since the above mentioned solution works for me.

Hope it will help anyone encountering issues and finding this on google

Apollo is using v4, if you use graphql-tools u are using v5 with some directives no longer supported. If you post your directive I can try to see why it is no longer supported, but in reality we are attempting to restore support, with progress tracked in this issue.

I apologize for you encountering this issue. Hopefully this will be resolved soon.

@yaacovCR Do not worry. I feel like it is kinda the apollo-graphql docs fault. Since we shouldn't need to worry about what graphql-tools version to use (and even in case we need to, it should be explicitly stated what version is safe to use). That is the responsibility of that particular library. So the new apollo-graphql docs are more correct in that way. I think I will start an issue there suggesting to update their docs on this matter.

Ah so I found out that there is another doc that state the new method I guess.

Very confusing, but I think this is the problem:

In this doc:
https://www.apollographql.com/docs/graphql-tools/schema-directives/
The suggest the use of makeExecutableSchema. Which is deprecated as far as I understand the above conversation?

But in this doc: https://www.apollographql.com/docs/apollo-server/schema/directives/ (which I guess is newer) they suggest the following method, which I guess is still supported somehow:

const server = new ApolloServer({
  typeDefs,
  resolvers,
  schemaDirectives: {
    upper: UpperCaseDirective,
  }
});

Thank you so much for that answer. I have been trying to get directives to work for 2 hours now. I fully bame the documentation I followed

Not sure if you are all ready for this, but you should be able to test using schema generation with makeExecutableSchema and passing to Apollo server via schema property, with preserved backwards compatibility for all the original directive resolvers, using the new scoped packages:

@graphql-tools/schema
@graphql-tools/utils
etc

as necessary

via canary tag. Would be extremely helpful to us!

Example project using new scoped packages: https://github.com/yaacovCR/apollo-stitcher/blob/master/package.json

v6 API in progress: https://www.graphql-tools.com/docs/introduction

馃憤 @yaacovCR v6-alpha.2 works well for my simple cases. We wrote typeDefs for directives and so v5 worked as well, but now we'll be testing v6 with more complexity.

Closed by #1419.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MehrdadKhnzd picture MehrdadKhnzd  路  3Comments

proehlen picture proehlen  路  4Comments

adamkl picture adamkl  路  3Comments

confuser picture confuser  路  4Comments

ericclemmons picture ericclemmons  路  4Comments