Omit Types from schema if not used by loaded resolvers

[cross311]

Is your feature request related to a problem? Please describe.
We are placing resolvers in different folders for public or internal.
We are deploying the same graphQL codebase twice, one marked as public and one internal.
The public one does not have a number of revolvers, due to them only being internal.
We are doing this so we do not expose our internal models publically.

While only the resolvers that we require are showing up in the schema (👍 ), all of the ObjectTypes in the codebase are.

Describe the solution you'd like
The requested solution is to only put types that are used in the loaded resolvers.

Describe alternatives you've considered
We can split the codebase and move shared models into an npm package but would prefer not.

[cross311]

Been trying to work around this, and have found another workaround. javascript compiler is good enough that if the file is not in the import tree then the decorators will never get called.

Using the glob resolver syntax the only time a resolver will get loaded is if it is in that glob. Then you have to make sure that you do that use object types outside of the resolver flow. If an object type is used in a commonplace then it will get read in and be in the schema.

This workaround takes a lot of discipline but is possible.

[MichalLytek]

There are a few things you need to know:

1. Some people want to reuse the types/args classes so they have it files in separate folders and even projects (Typescript module and type-graphql dependency #69). So as we have multiple node_modules folders with multiple type-graphql packages, we need to store the metadata attached to global variable to share the metadata between packages inside single Node.js process.

2. Decorators has to be evaluated to put the metadata in store. So to be evaluated, they have to be in import chain from your app entry point. That's why you need to explicitly import resolvers classes or provide a glob string that will do that for you. Then the import chain goes to all imported args, input or object types and register them in metadata storage.

3. If the file with class is not in import chain, it won't be registered. It's usually unheard but if you use InterfaceType, your ObjectType implementation might be not imported in some case, so you might then need to explicitly import them in your base resolver because without it they won't show in your schema:
   

4. To actually include the types in schema, I need to provide them manually as graphql-js not always include all of them:
   https://github.com/19majkel94/type-graphql/blob/a704b8b992e0fe45aea3c1a35ee47f0b81faf9d6/src/schema/schema-generator.ts#L334-L341

5. I haven't considered multiple schema in one process as a common case. Because of the reasons described above, you may experience leaks in types emitted in schema. I would have to figure out how to provide in the schema-generator only the missing types, not the spread on all existing types. Maybe also I should filter queries and other handlers, not emit all from the MetadataStorage 😉

[cross311]

Thanks for the amazing response! As you mentioned in number 6, one way would be filtering at the end, which I am sure would not be an easy task.

I assumed we were using the library in a weird / edge case and was super excited that we could actually get it to do what we wanted! If we keep running into schema leaks I might take a harder look at the schema generator to see if I could implement what you recomend. But right now it is not blocking us, so I probably wont get to it soon.

If anyone wants to use library in similar way to us before a fix comes out a few things for workaround:

• make sure to only require / import resolvers|mutations|subscriptions you want included
  • easiest way to do this is put resolver groupings (different schemas) in different folders and change glob load regex based on which schema you want to run with.
  • if using direct import even if not using the resolver, as mentioned above, types will be in global metadata registry and will be in schema.
• Do not use index.ts files for models folder or resolver folder, brings everything in even if not actually used especially since most server side apps do not do tree shaking.
• break apart shared functions using models into different files, again so require/import only gets what is used.

Again thanks for the amazing library.

[MichalLytek]

I will try to take this into account during metadata -> schema converting process redesign.

Shouldn't be too hard to implement it, as the metadata storage will handle only metadata from decorators and the metadata builder will build full types info based on loaded resolvers only. So schema generator will emit only the needed types, so separate types property of buildSchema should be provided to support orphaned types: