Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metadata leak between schemas #234

Closed
alx13 opened this issue Jan 20, 2019 · 2 comments
Closed

Metadata leak between schemas #234

alx13 opened this issue Jan 20, 2019 · 2 comments
Labels
Duplicate 🔑 This issue or pull request already exists

Comments

@alx13
Copy link

alx13 commented Jan 20, 2019

Describe the bug
As said in #196 there should not be metadata leak between two schemas using different resolvers.
But currently booth schemas get same resolvers.
Actually it's related to #110 and #183, so close if you think it's duplicate.

To Reproduce
Minimal reproducible code:

// server.js
import 'reflect-metadata';
import http = require('http');
import express = require('express');
import {
  ApolloServer,
} from 'apollo-server-express';

import {
  Resolver,
  Query,
  buildSchemaSync,
} from 'type-graphql';

@Resolver()
class Schema1Resolver {
  @Query((_returns) => Boolean)
  public testSchema1() {
    return true;
  }
}

@Resolver()
class Schema2Resolver {
  @Query((_returns) => Boolean)
  public testSchema2() {
    return false;
  }
}

export async function initServer() {
  const isProduction = process.env.NODE_ENV === 'production';

  const app = express();
  const httpServer = http.createServer(app);

  new ApolloServer({
    schema: buildSchemaSync({
      resolvers: [
        Schema1Resolver,
      ],
    }),
    playground: true,
    debug: true,
    introspection: !isProduction,
    tracing: !isProduction,
  })
    .applyMiddleware({
      app,
      path: '/graphql-schema-1',
    });

  new ApolloServer({
    schema: buildSchemaSync({
      resolvers: [
        Schema2Resolver,
      ],
    }),
    playground: true,
    debug: true,
    introspection: !isProduction,
    tracing: !isProduction,
  })
    .applyMiddleware({
      app,
      path: '/graphql-schema-2',
    });

  httpServer.listen({ port: 8080 });
}

if (require.main === module) {
  initServer()
  .catch(() => {
    process.exit(1);
  });
}

Expected behavior
/graphql-schema-1 should only have testSchema1 query, and /graphql-schema-2testSchema2

Enviorment (please complete the following information):

  • OS: MacOSX
  • Node: v8.12.0
  • Package version: 0.16.0
  • TypeScript version: 3.2.4
  • reflect-metadata: 0.1.13
@MichalLytek
Copy link
Owner

MichalLytek commented Jan 24, 2019

Yeah, it's a duplicate of #110 🔒

For now, you need to run two separated node.js processes:

node app-server.js
node dashbord-server.js

With separated createServer function with not imports overlap.

@johnlimed
Copy link

I was facing the same behaviour and acknowledge that the work around on v0.17.X would be to run two separate node.js scripts.

Just wanted to discuss what I found and understand whether this is similar if not the same fix that was implemented in v0.18.0-beta.1. I'm hesitant to use the beta for now.

I noticed that there was a clear function in the MetadataStorage class and so I tried to clear the storage right after a graphql schema is built.

in dist/schema/schema-generator.js line 39 I called the clear function.

    static generateFromMetadataSync(options) {
        this.checkForErrors(options);
        build_context_1.BuildContext.create(options);
        getMetadataStorage_1.getMetadataStorage().build();
        this.buildTypesInfo();
        const schema = new graphql_1.GraphQLSchema({
            query: this.buildRootQueryType(),
            mutation: this.buildRootMutationType(),
            subscription: this.buildRootSubscriptionType(),
            types: this.buildOtherTypes(),
        });
        build_context_1.BuildContext.reset();
        getMetadataStorage_1.getMetadataStorage().clear();
        return schema;
    }

This resulted in the behaviour: that each generation of schema is according to the definitions provided.

Was this the approach taken in the fix of 0.18.0-beta.1? Or are there some other considerations that I have not taken into.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate 🔑 This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants