Graphql-laravel: Custom middleware can be defined for each query/mutation

[crissi]

"Custom middleware can be defined for each query/mutation" from the docs

I can see you write this in the docs, but I can't figure out how this works:

I would like to have the same endpoint, but just remove auth from the LoginMutation::class is this possible or what is the recommendation in this scenario?

'schemas' => [
    'default' => [
        'query' => [
            'cases' => App\GraphQL\Order\CaseQuery::class,
            'caseType' => App\GraphQL\CaseType\CaseTypeQuery::class
        ],
        'mutation' => [
            'case'  => CreateCaseMutation::class,
            'login' => LoginMutation::class
        ],
        'middleware' => ['auth']
    ],
],

[rebing]

Use it like this for example

'schemas' => [
    'default' => [
        'query' => [
            'cases' => App\GraphQL\Order\CaseQuery::class,
            'caseType' => App\GraphQL\CaseType\CaseTypeQuery::class
        ],
        'mutation' => [
            'case'  => CreateCaseMutation::class,
        ],
        'middleware' => ['auth']
    ],
    'guest' => [
        'mutation' => [
            'login' => LoginMutation::class,
        ],
    ],
],

[stevelacey]

@rebing so it's only per schema rather than per query/mutation?

[mfn]

@stevelacey yes, it's per schema

The suggestion made in https://github.com/rebing/graphql-laravel/issues/66#issuecomment-354066357 means that you've to call not /graphql but /graphql/guest and call the login mutation there.

[milewski]

@mfn so that means if I have 10 queries that require 10 different middlewares I need to create 10 different schemas? and to access each of these schemas I would need to append /graphql/{schema_name}? there is no simple way to do something like this example below and have a single endpoint for all the queries?:

class CustomerQuery extends Query
{
    protected $attributes = [
        'name' => 'customer',
        'description' => 'Returns a customer resource',
        'middleware' => [ 'some_middleware_1' ]
    ];

    public function type()
    {
        return GraphQL::type('customer');
    }

    public function resolve(....)
    {
        return ....
    }
}

[stevelacey]

@milewski yes, can confirm, there is no way to do this currently, I’m thinking about adding it, it sounds like a common use case to me. My project currently hacks around this by customizing the native middlewares, but it seems to me this would be a common thing people would want to do. The primary use case surely being not wanting to have to put guest middlewares queries like auth in a separate schema.

[mfn]

So this would introduce a 3rd level of middleware:

1. global (via config)
2. per schema (via config)
3. per query/mutation (via declaration)

I'm open to PRs!

[stevelacey]

Yep, bringing queries/controllers in line with controllers, I’ll give it some thought, it’d be nice to be able to effect a router group style equivalent as well, otherwise the only DRY approach for my example would involve relying on inheritance or traits

At that point maybe a artisan route:list equiv would be useful too...

[stevelacey]

The difficulty in the current implementation iirc seemed to be that it built out a router esque graph of the middlewares to be applied based on schema way earlier in the app flow than would allow customization per query. Maybe thats fine and this could compliment that, or maybe all of the logic could be consolidated at a point after at the very least we know which queries are being resolved. I think the latter could be cleaner, and could avoid some complications.

[mfn]

We've to take into account that what is asked here is _to some degree_ with the existing library already possible; not nicely, not obvious, not documented but possible.

I would weight that before doing massive changes if the added complexity is worth the flexibility of the library (i.e. target audiences of the library really benefiting from this).

The current route separation is also important for performance consideration; quite some work went into 2.0 to that so that GraphQL type system _does not have to be booted_ if it's not used. Now requiring access to that information implies accessing the type system implies having to boot the system. Thus it's important to avoid this if it's not consumed.

I realized this the moment I checked the source for the summary I wrote; I wouldn't have a clean idea how to implement this. Wondering what creativity is needed here to make it work.