overblog / GraphQLBundle

This bundle provides tools to build a complete GraphQL API server in your Symfony App.
MIT License
783 stars 221 forks source link

Enhance type mappings to limit to schema(s) #644

Open akomm opened 4 years ago

akomm commented 4 years ago
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:

  1. You have to name your root types differently.
  2. 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:

  1. It should be still possible to share types (call them global)
  2. 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.

Vincz commented 4 years ago

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.

akomm commented 4 years ago

@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...