Graphql-tools: Using GraphQLObjectTypes with makeExecutableSchema?

Created on 7 Sep 2017  路  5Comments  路  Source: ardatan/graphql-tools

I'm trying to use mongoose-schema-to-graphql to automatically generate GraphQL types derived from Mongoose models. Unfortunately, the mongoose-schema-to-graphql package generates GraphQLObjectType objects, not GraphQL schema language strings. Because makeExecutableSchema only accepts an array of strings (or a function that returns an array of strings), passing these GraphQLObjectType objects into the typeDefs field of makeExecutableSchema results in type errors.

I've gotten around this with an ugly hack. I convert the GraphQLObjectType returned by mongoose-schema-to-graphql's createType into a GraphQL schema language string using the printType utility function in the graphql package, and drop the result into the typeDefs option of makeExecutableSchema.

Obviously, there's a huge amount of wasted work being done here.

Ideally, I wonder if it would be possible for makeExecutableSchema to optionally accept GraphQLObjectTypes and/or other pre-parsed GraphQL primitives (maybe through some other options field, since types/resolvers/etc. could be passed in), instead of exclusively accepting strings that need to be parsed.

I'd love to hear your opinions, or if there's a better way to accomplish what I'm trying to do.

Thanks.

Most helpful comment

In my case I already had my schema written up in schema language (i.e. graphql-tools approach) and wanted to add some mongoose capabilities for occasional server-side data operations. Rather than ditching graphql-tools (a lot of work to rewrite the schema) I'm just adding mongoose models on the side..they are almost identical to graphql types so it's mostly a copy/paste job to generate mongoose models from schema language types. Granted it's not ideal to have such code duplication but this was a practical matter. Also, putting the types / models duplication aside, I'm partial to leaving my queries / mutations written in schema language...i.e. graphql-tools has value there to me.

If anyone comes up with a better approach to the predicament of incorporating mongoose with graphql-tools, I'd be curious.

For the long term, ideally graphql-tools would incorporate the logic from a package like mongoose-schema-to-graphql so that we can continue to create query and mutation schemas in schema language and optionally re-use models in mongoose i.e. eliminate code-duplication (duplication of graphql types and mongoose models for this use case).

All 5 comments

Is your goal to combine the schema string with the object types generated by the package? What I mean is, do you have data in your schema that doesn't come from mongoose?

@stubailo Yeah, I have an existing string schema that I'm trying to combine with the object types.

If I didn't, would you just recommend not using graphql-tools?

Yeah - if you already have a schema written up with object types, there's no big reason to use makeExecutableSchema. You can still use stuff like addMockFunctionsToSchema with GraphQL.js types, since that's the same thing you get from the schema function!

There have been a lot of feature requests for combining string schemas with ones defined using the underlying GraphQL.js objects, or generated from tools; but it's a bit hard from a technical standpoint. Definitely open to ideas and contributions about how to make that happen.

In my case I already had my schema written up in schema language (i.e. graphql-tools approach) and wanted to add some mongoose capabilities for occasional server-side data operations. Rather than ditching graphql-tools (a lot of work to rewrite the schema) I'm just adding mongoose models on the side..they are almost identical to graphql types so it's mostly a copy/paste job to generate mongoose models from schema language types. Granted it's not ideal to have such code duplication but this was a practical matter. Also, putting the types / models duplication aside, I'm partial to leaving my queries / mutations written in schema language...i.e. graphql-tools has value there to me.

If anyone comes up with a better approach to the predicament of incorporating mongoose with graphql-tools, I'd be curious.

For the long term, ideally graphql-tools would incorporate the logic from a package like mongoose-schema-to-graphql so that we can continue to create query and mutation schemas in schema language and optionally re-use models in mongoose i.e. eliminate code-duplication (duplication of graphql types and mongoose models for this use case).

I think this is a duplicate of #185 or #340, in retrospect.

Was this page helpful?
0 / 5 - 0 ratings