How to provide custom resolver mechanism?

[KarlisJ]

I'm trying to achieve that GraphQL query in mapped to Laravel Eloquent builder. In my mind, a query like

{
    post(id: 2) {
        id
        title
        content
        user {
            id
            name
        }
        comments {
            id
            content
            user {
                name
            }
        }
     }
}

should be mapped to

\App\Models\Post::query()
    ->addSelect('id')
    ->addSelect('name')
    ->addSelect('email')
    ->with([
        'user' => function ($builder) {
            $builder
                ->addSelect('id')
                ->addSelect('name');
        },
        'comments' => function ($builder) {
            $builder
                ->addSelect('id')
                ->addSelect('content')
                ->with(['author' => function ($query) {
                    $query->addSelect('name');
                }]);
        },
    ])
    ->find(2);

Is there a way to implement my own logic how resolvers are handled?

I'm looking for an option to pass query builder instance around in resolvers and manipulating the builder to then execute the built query.

From the docs

Result returned by resolve function is directly included in the response (for scalars and enums) or passed down to nested fields (for objects). [...] You can return any value, graphql-php will pass it untouched to nested resolvers

I've managed to pass query builder to nested resolvers and actually build the query however there are problems with scalars and enums. In the end, the whole system seems to be built differently.

---

Not looking for other Laravel implementations like Lighthouse. My concern is that the default mechanism for resolving is forcing to fetch more data from the database than requested from the client. Even in Lighthouse specifying only one field will do select * from which bloats the runtime memory and makes database queries longer.

[spawnia]

I added docs for this, see https://github.com/webonyx/graphql-php/pull/1101/files#diff-301a2998dd7e5ac817d73935d870810d96b51411a60a5be855aed24289ba5557R153-R185

[KarlisJ]

Thank you, $resolveInfo->getFieldSelection()does help optimizing but for my use case it only helps to some degree.

In that example you return

return $builder->last();

which I suppose is meant to be an array.

I want the result to be the built query builder so that I could then work on that instead of an array response. But spending some time in source code it seems that this behavior (resolver returns data as an array) is deeply implemented in the core.

I managed to create a workaround. From resolvers, I return just enough information so that corresponding nested resolvers would be executed and use a global container to access the query that I build. Then from the result from qraphql-php I only check if there are any errors but the actual results pull out the query from the global container.

That's the best I could figure out.

[spawnia]

You can return anything you want from the resolver of a non-leaf field, as long as the resolver of a leaf field is able to produce a value from it.

[KarlisJ]

Yes, that I know. But my problem is what the "value" is that should be produced from a leaf field.

Looking into code I see

$results[$responseName] = $result;

which indicates that the value is supposed to be an array.

I want the result of \GraphQL\GraphQL::executeQuery to return a query builder that I can then later call the method to actually fetch data. But looking at the docs and code it seems that's not possible since the internally package expects the leaf resolver to return data and operates on a response that's an array.

[spawnia]

At some point, this library has to see actual values - it needs to perform scalar coercion, validate non-nullability, etc.