GraphQLBundle
GraphQLBundle copied to clipboard
Enhance type mappings to limit to schema(s)
| Q | A |
|---|---|
| Bug report? | no |
| Feature request? | yes |
| BC Break report? | no |
| RFC? | no |
| Version/Branch | dev-master |
Currently you can have multiple schemas. Those schemas will have only types visible, which were used in the schema. This is a good thing. You can also share types between schemas. Then they are visible in both. Also nice.
Problems: The mapping configuration collects everything into a single pool of types, even though at the end not all of them are part of every schema:
- You have to name your root types differently.
- You have to name types differently should they have different structure, but preferably the same name.
If you think the public config solves 2. problem - it does not really. In most cases. Additionally, it brings in some cumbersome issues with it. For example every condition on which public configuration is based in your schema creates more and more possible combination of schemas you can get out. And you have to account for all this when you want to dump via console. Because in fact, every output is an own schema at the end.
Requirements:
- It should be still possible to share types (call them global)
- It should be possible to limit types to a schema
Example illustrating different cases:
overblog_graphql:
schema:
schemaA:
query: Query
mutation: Mutation
schemaB:
query: Query
mutation: Mutation
schemaC:
query: Query
mutation: Mutation
mappings:
auto_discover: false
types:
- type: yaml
dir: path/to/global/types # types from here are usable in all schemas
- type: yaml
dir: path/to/schemaA/types
schema: schemaA
- type: yaml
dir: path/to/schemaB/types
schema: schemaB
- types: yaml
dir: path/to/schemaC/types
schema: schemaC
update: Removed the multi-schema case, it would bring in more trouble than advantages. You can simply have shared types, or restricted types. At least as a starter :)
To be able to name the root types equally, like above, they must simply be defined in the restricted typings, but not the shared.
I'm working with multiple schemas recently and it could really be a great addition. As you mentioned, types conflicts between schema is kind of a problem. But I think it's gonna be quite hard to implement.
@Vincz
the question is master or 0.13 ... Master is far ahead working towards 1.0. It should be BC and 0.13 would be usable sooner, but would require another application on master... For example there is the generator refactored, but also the API has changed. I might need to create namespaces to prevent name collisions on generated types. How much effort it will be to reapply I can't yet tell.
Whether this matters or not depends on whether I need to change generated code... Let's see...