Cannot inject GraphQLFactory into forRootAsync factory/class

[michaelbromley]

I'm submitting a...

[ x ] Bug report

Current behavior

When I try to inject GraphQLFactory into either a factory function or a class passed to GraphQLModule.forRootAsync(), the app fails to bootstrap, with no error displayed in the console.

Expected behavior

I think I should be able to inject GraphQLFactory and use it in a factory or class passed to .forRootAsync().

Minimal reproduction of the problem with instructions

1. git clone git@github.com:nestjs/nest.git
2. cd nest/sample/12-graphql-apollo
3. npm install
4. edit app.module.ts to look like:

imports: [
    CatsModule,
    GraphQLModule.forRootAsync({
      useFactory(graphQLFactory: GraphQLFactory) {
        return {
          typePaths: ['./**/*.graphql'],
          installSubscriptionHandlers: true,
        };
      },
      inject: [GraphQLFactory]
    }),
  ],

5. npm run start

What is the motivation / use case for changing the behavior?

I want to use the GraphQLFactory.mergeTypesByPaths() method to do some pre-processing of my schema when bootstrapping my app. Up until today I was using the old v3.0.0 way of configuring graphql, where I could inject GraphQLFactory into my AppModule.

Now I am upgrading to v5.1.0 and it seems that when I try to inject GraphQLFactory into either a factory function or a class passed to GraphQLModule.forRootAsync(), the app fails to bootstrap with no error.

Environment

Nest version: 5.3.0

"@nestjs/common": "^5.3.0",
"@nestjs/core": "^5.3.0",
"@nestjs/graphql": "^5.1.0",

[kamilmysliwiec]

Fixed in v5.1.1. Thanks for reporting!

[michaelbromley]

This still appears to be broken for me in v5.1.1.

[kamilmysliwiec]

Weird 😢 Reopening

[kamilmysliwiec]

Alright.
So basically GraphQLFactory depends on ResolversExplorerService and a few others which in turn depends on GRAPHQL_MODULE_OPTIONS. It creates a circular infinite dependency. Since mergeTypesByPaths doesn't need options object, we could extract this method to another class.

[matcic]

@kamilmysliwiec I was about to open the same issue and was going to suggest what you just said. Just in case the following is what I'm using for now @michaelbromley:

import { fileLoader, mergeTypes } from 'merge-graphql-schemas';
import { flatten } from 'lodash';

export function mergeGraphqlTypes(...patterns: string[]): string {
  const files = patterns.map(pattern => fileLoader(pattern));
  return mergeTypes(flatten(files));
}

[kamilmysliwiec]

One question @matcic @michaelbromley, could you share your sample use-cases of mergeGraphqlTypes? It might be useful for another feature that I'm planning to introduce very soon.

[michaelbromley]

Sure, here's my use-case (this is prior to Apollo Server v2 migration, so using the old style):

https://github.com/vendure-ecommerce/vendure/blob/7f35f10a12392558decd3c285988113aa37ab175/server/src/app.module.ts#L91-L104

    private createSchema(customFields: CustomFields) {
        const typeDefs = this.graphQLFactory.mergeTypesByPaths(__dirname + '/**/*.graphql');
        const extendedTypeDefs = addGraphQLCustomFields(typeDefs, customFields);
        return this.graphQLFactory.createSchema({
            typeDefs: extendedTypeDefs,
            resolverValidationOptions: {
                requireResolversForResolveType: false,
            },
            resolvers: {
                JSON: GraphQLJSON,
                DateTime: GraphQLDateTime,
            },
        });
    }

The addGraphQLCustomFields() function is internally using graphql-js's extendSchema function to extend the existing objects with new fields according to user config. Implementation is here.

@matcic thanks - that's pretty much exactly what I've got at the moment ;)

[matcic]

@kamilmysliwiec my use-case is related to microservices: the idea is to have one schema per microservice (which in turn is generated by merging together several types belonging to different models) and then to merge all schemas into one. I am using Graphql bindings behind the scenes in order to delegate requests to the appropriate endpoint.
I am actually in the process of designing such architecture with a special focus on user authorization - I am pre-processing all resolvers as well in order to create some permission wrappers that can be applied through graphql-middleware. I am afraid I cannot share a complete implementation yet, but I'd be interested in knowing more about the feature you are planning to introduce 😄

[kamilmysliwiec]

Thanks for sharing your use-cases @matcic @michaelbromley, appreciate that ❤️ I have just published 5.2.0, you can use GraphQLTypesLoader now (exported from the root).

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.