Description
First, I would like to say thank you for this great project.
Is your feature request related to a problem? Please describe.
I am looking to create a framework where the bulk of the code is written and rust and delegates to a language like python for business logic. Given these constraints, the schema of the API is inherently dynamic and thus is not known at compile time. It would be optimal if somehow juniper could support this (admittedly niche) use case.
Describe the solution you'd like
If juniper provided a lower level API that let you register types to a Registry dynamically and then propagate that up to an executable schema (side stepping traits like GraphQLType - which are not instance based), would allow for this to work.
Describe alternatives you've considered
I looked to see if this is possible today given the API's exposed by juniper. While the registry type is exposed and does seem to be the main point of interaction, this means you lose much of the query validation and other great work done by the juniper create.
I considered instead depending on graphql-parser and doing the validation and execution myself. But again, I lose a lot of what juniper has to offer. As an alternative to my idea above, Is there room for some crate between the ergonomics that juniper provides and the raw graphql parsing done in graphql-parser?
Additional context
This issue has been brought up in several issues in the past. Namely issues #7 and #106 but haven't really been obviously resolved.