[WIP] Graphql schema language configuration

[mcg-web]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Documented?	yes
Fixed tickets	#12
License	MIT

[enumag]

To be honest I don't really like the proposed yaml configuraion from the docs

QueryDecorator:
    decorator: true
    hiers: Query
    config:
        fields:
            bar: { resolve: "@=..." }

FooDecorator:
    decorator: true
    hiers: Foo
    config:
        resolveType: "@=..."

It's simply too much writing and things about certain type are split across too many files - the graphql schema file, decorator configuration and the resolver itself.

Instead I'd like to add resolver for a type using a tagged service. Something like:

services:
    App\GraphQL\FooTypeResolver:
        tags:
            - { name: graphql.typeResolver, type: Foo }

    App\GraphQL\BarFieldResolver:
        tags:
            - { name: graphql.fieldResolver, type: Query, field: bar }

This would remove the wtf syntax resolve: "@=..." and enable us to write a compiler pass to register such services automatically so no yaml configuration would be necessary - just the schema + resolvers.

What do you think?

[mcg-web]

I like this proposal! But some points should be clarify, what will be done if many resolvers tagging the same fields? Does this mean we introduce cascades resolving just like promises?

[enumag]

For now, simply throw an exception (KISS). Such features can be added later with a clear use-case in mind. I don't really expect such feature to be necessary.

One thing I did not consider is how to add descriptions or if there are any other metadata that can't be in the schema directly. I don't have enough GraphQL experience to know what else is needed. Maybe the resolver could have a second method to return such things?

[renatomefi]

@mcg-web don't wanna work on it anymore?

[mcg-web]

@renatomefi WIP, I closed that one to don't spam subscribers because I'm going in a different direction with resolvers.