graphql: GraphQl Multiple Endpoints not working

Will do my best to fix this issue as soon as possible

@kamilmysliwiec Have any update for this issue?

@kamilmysliwiec Looking for the fix. Any update?

@kamilmysliwiec thx that would be really nice if its working. My existing api contains about 50 modules with code first approach, I don’t want to update these to schema first.

I decided to switch my code from code first to schema first and now everything works as it should.

I tried the isAbstract: true method, but this still doesn’t work the moment I use any enum, where I can’t set this property. Is this even in progress? Since this is opened since March and it’s still not fixed, maybe it would be a good idea to remove it from the docs as it seems it’s actually supported?

I dug a bit deeper and probably found the culprit for the discrepancy.

During the graphql module initialization and before constructing the schema, the GraphQLSchemaFactory resets all storages except of the TypeDefinitionsStorage, which is e. g. referenced by the TypeDefinitionsGenerator (which itself is used by GraphQLSchemaFactory).

The second execution of LazyMetadataStorage.load(resolvers); re-evaluates all object classes and their annotations and therefore cuts references to previous module initializations, but does not clear these references in the TypeDefinitionsStorage, which will be favoured to be re-used later when establishing e. g. connections between field-object-types with their parents.

A viable solution is to add a clear method on the TypeDefinitionsGenerator, which in return would call a clear method on the TypeDefinitionsStorage.

I will create a PR.

Any chance someone has a solution to solve that while keeping code-first approach ?

I think the multiple endpoint feature in the docs should have a note that it only works with the schema first system until this issue is fixed. I just spent a couple of hours wondering what I’m doing wrong to then decide to google for a possible answer or if someone else ran into the problem I have and this GH issue ended up the #1 result.

I believe this prohibits the ability to have a very secure authentication system with Nest using GraphQL (i.e. refreshing access tokens in a very “tight” cookie path for recalling the refresh token) because one can’t have a separate endpoint for refreshing access tokens.

Also, with the above auth use case in mind, I think it would be cool to have an exclude prop, (as in opposite to the include prop) to tell the GraphqlModule to load every resolver except those noted in the exclude prop. If that sounds like a feasible idea, I’d even venture to try and PR it and at the same time see if I can dig into the code to find why the endpoint feature isn’t working with the Code First approach.

For now and to move forward, I’m going to try creating the separate app suggested above. I’m using a monorepo setup already. Should be easy enough to try. It might not even be a bad idea seeing as a “refresh” endpoint could get a lot of hits with a lot of users and with it being its own app, it would be using a separate process (or even multiple processes) and so, it can scale separate to the core application or rather, not intrude on resources used by the core application.

Scott

@kaufmo Your issue is this https://github.com/kaufmo/nestjs-typeorm-multiple-graphql-bug/blob/684bab8815a001d4be8c9da00c98b7c36590d0d2/src/app.module.ts#L28

Dont use autoSchema . Remove code-first approch totally from the app and create schema.gql manually and then give it path to typePath like this

@Module({
  imports: [
  GraphQLModule.forRoot({
    debug: true,
    path: 'user',
    playground: true,
    include: [AdminModule],
    typePaths: ['your/path/to/*.gql'],
    context: ({ req, res }) => ({ req, res })
  }),
  GraphQLModule.forRoot({
    debug: true,
    path: 'auth',
    playground: true,
    include: [FrontendModule],
    typePaths: ['your/path/to/*.gql'],
    context: ({ req, res }) => ({ req, res })
  })
],
 providers: [],
 exports: []
})

export class AppModule { }

@NormySan I found that when I changed my annotations from @ObjectType() to @ObjectType({ isAbstract: true }) it fixed the issue for me. Not sure if this helps you but thought I’d share.

As for my research, as my conflict appears with an ObjectType, it lies in the TypeDefinitionsGenerator#generateObjectTypeDefs - therefore somewhere in the ObjectTypeDefinitionFactory or one of the underlying registries, where probably the metadata/objects are not cleared and restored between the generation. So references to objects from the first run are reused, which breaks when creating a GraphQLSchema later on.

The GraphQLSchema from the official graphql-js package relies on object equality (using Set#has on GraphQLObjectType instances) and therefore adds referenced ObjectTypes twice - the one referenced in the metadata in the fields from a previous run as well as the object itself from the fresh generation.

Either the metadata/registries have to be cleared and constructed from scratch again or all objects have to be reused.

I have not identified the location where some store like a registry is reused from the previous module initialization though.

After some trials and errors I came up with working solution/workaround that allows to keep the code-first approach while having multiple GraphQL endpoints. The solution uses the NestJS workspaces.

The trick is in splitting the project into multiple apps with a shared library. Each of these apps has its own GraphQL configuration and can use whatever models and resolvers from the shared library. As both apps are built separately the schema is generated without any naming conflicts.

Here is the repo with the example

Even one endpoint

GraphQLModule.forRoot({
      typePaths: ['./src/**/*.graphql'],
      context: ({ req }) => ({ authToken: req.headers.authorization }),
      resolvers: {
        DateTime: GraphQLDateTime,
        Upload: GraphQLUpload,
      },

is not generating schema at launching tried many paths /src src …/src

@francisfontoura According to the documentation isAbstract is used to suppress SDL generation for the specific object type. If this solves the problem while it’s still added to the schema then it’s most likely a bug since thats not the expected behaviour from my understanding.

I’m not trying to include unused object types in my schema, I’m building an application with multiple GraphQL endpoints and both endpoints are getting the same object types, resolvers etc. added do them even though they are completely seperated and it’s configured to only load object types, resolvers etc. from specific modules.

I’m also having this issue and I really need to get this working. Is there anything that I could help with to get this resolved?

Any updates ? i have tried “code First approach” with different schemas but no luck so far 😦

I’ve created also an example, see #896