As we discussed in ardatan/graphql-tools#40 we need to support dynamic schemas—where “dynamic” here means that the schema is determined on server start by composing various modifiers in different files and modules, as opposed to a static schema.gql file.

A solution to handle these dynamic servers, would be to set up a shell command that would return an introspection JSON. That command would usually be something like:

{
    "generateSchema": "node tools/generateSchema.js"
}

But then we have this cache invalidation issue that I’m not sure how to solve. I imagine something like a --watch mode could work, but would make it hard for developers to write a script that would not only return the schema but also communicate futures changes through some sort of watch protocol. Though maybe utility libraries could help and make this whole idea feasible.

Another solution would be to actually launch the GraphQL server and have things like linters and autocompletion be checked against this running server, such as if the server gets restarted with a different config, it will return different responses to linter/autocompletion introspection queries and thus we will avoid any cache invalidation issue. The drawback here is that the tooling wouldn’t work without launching the server but maybe that’s still the best thing to do considering that we need to run a command anyway—and if we imagine autocompletion for a SQL database, having that database running in the background makes sense, so I guess the same reasoning apply to a GraphQL server.

For example:

1. Relay
2. Lokka

And Apollo when there are special considerations.

From this list, at first: https://github.com/graphql/graphql-js/blob/master/src/validation/specifiedRules.js

With more to come later! Eventually we should support defining custom rules.

For situations like this: facebook/relay#1080