Resolve function behaviour identical to Controller

Is your feature request related to a problem? Please describe.

Currently the resolve function looks always like this:

public function resolve($rootValue, array $args, GraphQLContext $context, ResolveInfo $resolveInfo)
    {
        // ...
    }

Most of the time I don't need $rootValue, $context and $resolveInfo. I spend some time thinking about how to improve the resolve functions to feel more Laravel-ish.

Describe the solution you'd like

Resolve function should behave in the same way as controller methods do.

1. Instead of passing 4 attributes to the resolve function maybe create some kind of "Request" object. It might even implement some methods that are already available in the default HTTP Request class provided by Laravel. That way I don't have to write my own logic for simple things (filled, all, input, except, only, validate …).

2. Instead of always passing this Request object, maybe determine the attributes through reflection. So I can have resolve functions based on my needs. function resolve(Request $request) gives me the request object. resolve($id, $name) gives me only id and name from $args. And so on…

3. Resolve Eloquent Models based on reflection. If I have a id or some named attribute. Then I might use the resolve function this way: resolve(Flight $flight) (either id is defined or flight attribute is used as an id), resolve(Flight $flight, Passenger $passenger) (I have flight and passenger as attributes). That way I dont have to manually write $flight = Flight::find($args['id']); every time.

4. Service Injection. Instead of relying on the constructor for passing in Services from the IoC container, maybe resolve them automatically when they are an attribute of the function. In my opinion this does not serve any purpose than to have consistency with Http Controller. I am totally fine with passing services through the constructor.

When the resolve function become more like the controller methods I could imagine that I could reuse the same Controller/Resolver class for Http Controller and GraphQl purposes. Especially when the "Lighthouse" Request object is implemented more or less identical to the default Http Request.

Describe alternatives you've considered

I will probably create an abstract wrapper Resolver class in the next days. That way I can create resolvers in the style described above (except 4.), without relying on you to change the resolver logic. This might even become a part of Lighthouse if you wish. But then all resolvers have to extend this class if they wish to have the same flexibility. Note that default Controllers do not require any Class extensions or interface.

Start with the current four-argument resolve function and compare it with Laravel controller methods and the HTTP Request behavior described in the issue. The proposal covers request injection, reflection-based arguments, model resolution, and service injection, so a concrete scope and acceptance criteria must be decided before implementation can be considered done.