Graphql-laravel: Expose field resolver depth parameter

[shengslogar]

Summary

v2.0.1

Resolving query fields is hard-coded to a depth of 5. When exceeding this limit, non-intuitive SQL errors are thrown.

https://github.com/rebing/graphql-laravel/blob/edb88d6c5f46a1333dd02e287831d29703af00c3/src/Support/SelectFields.php#L44

Use Case

I ran into this issue when creating a deep nested query and using eager loading on the resolve method per documentation.

Possible Solutions

• Expose via instance variables in both Field and SelectFields classes to be overridden
• Expose via instance variable in Field class and optional parameter with $getSelectFields closure (here)
• Improve documentation to explain the limit and how to override it (there is a hint at it under the "eager loading relationships" section, but it wasn't clear to me)

Happy to look into making this work if pointed in a suggested direction.

[mfn]

I prefer to keep things _away_ from Field. If possible, only SelectField should be adapted.

How about adding a field to SelectFields and bump the default, e.g. public static $depth = 9; on SelectFields.

That way it can be adapted (read: bumped up even more) if necessary.

I imagine this would be done _once_ per boot of the ServiceProvider (and not dynamic depending on the query).

What do you think?

[shengslogar]

@mfn I haven't looked into the source enough to understand the performance implications of $depth, but assuming that's the point of it (to improve performance), would it not make more sense to only override as needed on a specific query?

Otherwise, I get why you'd want to keep that out of Field and a static var (or maybe even a config field?), along with bumping up the default depth sounds fine to me.

[mfn]

Please see https://github.com/rebing/graphql-laravel/pull/472 and let me know if it fixes your use case.

[shengslogar]

@mfn That's perfect. Thank you for implementing that!!

[mfn]

The fix is part of 2.1.0 release

[shengslogar]

@mfn Beautiful. Updating now. Thanks again.