Redundancy of defining the schema twice - schemaString and resolver

[paullen]

Hi,

My use case for this library is to define groups of queries, mutations, and subscriptions in separate go modules and stitch them together at runtime using dependency injection. To do this I can't define my entire schemaString at compile-time. It needs to analyse the provided queries, mutations and subscriptions at runtime and generate the schema itself.

Looking at the usage of this library, it seems I have to provide the schemaString and root resolver beforehand at compile-time. If we already have the resolver which essentially is a map to the schemaString itself, why don't we just generate the schema from the resolver? We don't have to work twice at it with a lot of room for human errors since there isn't any linting for the schemaString that informs us beforehand if it matches with the resolver.

This way of defining the schema can be achieved with Jaal but it isn't maintained properly and I would love to see this being implemented here.

I realise implementing this will be a breaking change which could be accommodated in the one of the upcoming major version releases.

Would appreciate your thoughts on this.

[pavelnikolov]

This is a schema first library and as such I don't see ever moving to a code first approach. Starting with schema first has some advantages:

• the schema is used by UI teams to mock their apps
• the schema is the contract between the backend code and the frontend code and therefore it is kept in source control and monitored carefully not to introduce any breaking changes
• starting with schema first, you can definite the data resolvers you need vs the data you already have (this allows you to abstract away many implementation details and simplify the queries)

In addition to the above, there are other projects which implement code first approach or are also schema first and generate the code from the schema. Feel free to use one of them.