Schema config param is not fully compatible with GQLCodeGen; Improper caching of complex schemas about graphql-let

[comp615]

A few thoughts on potential approaches here:

One naiive way would be to simply extend the existing code to handle exported modules (i.e. just like we kind of have a URL loader and a simple file loader today, we could add one more). The downside of this is that it's still not API compatible and we are ultimately maintaining a copy of the same code

The most compatible way would be to use the underlying GQL Tools loaders as shown in #650. However, this approach has a few drawbacks. First and foremost...it's slow. While it's acceptably slow for the batch use case, the webpack loader case is slow to the point of making this non-viable. In a project with dozens of GQL files, each file is treated independently by the loader; meaning each builds a separate execContext which reads the schema. This now goes from 1ms to 200ms or more, bringing builds to a crawl. Some of this might be caused by GQL Tools kicking back a Schema object instead of raw file we can hash.

One solution to that problem is to cache the execContext or schema in the loader (since it is a singleton). But now we have the reverse problem, we never reevaluate the schema. So hot reloading is useless. In effect, loaders do not know when the entire build is done, nor do we get a list of files involved in building the schemas such that we could watch them in the loader.

So to actually solve this problem, it's very likely that we should convert the loader to a plugin with a loader component. These two would be able to better coordinate since we could produce a cached schema per build that could be reused for each file. Then on subsequent builds (i.e. hot reloads) we could simply re-create the schema.