Change default-resolver lookup according to @namespace directive

[DelDaGhost]

What problem does this feature proposal attempt to solve?

When creating a big graph I would like to split the graph into multiple-files.
In order to also keep the resolvers of this graph clean, I would like to have them sorted in multiple folders.

This is currently possible by using the @field-directive on each field(query/mutation).
But it is a bit of repetitive code if you strictly follow the same structure.

Which possible solutions should be considered?

When the default lookup of the resolver also takes the @namespace-directive into account it would be possible to just declare the namespace and still use the default-lookup of the resolvers.
Maybe there would also be a way to define the default-path or better yet a postfix for the default-path for a whole graphql-file since then it would also work for validators?

Example:

extend type Mutation @namespace(field:"App\\GraphQL\\Mutations\\User") {
    registerUser(input: RegisterUserInput!): User!
}

Then lighthouse would look for 'App\GraphQL\Mutations\User\RegisterUser.php' instead of 'App\GraphQL\Mutations\User\RegisterUser.php'.

I've currently overwriten the ResolverProvider in my project in order to achieve this.
Thx @thekonz for pointing me in the right direction here :)

Code-Example:

namespace App\Extension\Nuwave\Lighthouse\Schema;

use Illuminate\Support\Str;
use Nuwave\Lighthouse\Schema\ResolverProvider;
use Nuwave\Lighthouse\Schema\Values\FieldValue;
use Nuwave\Lighthouse\Support\Utils;

class CustomResolverProvider extends ResolverProvider
{
    protected function findResolverClass(FieldValue $fieldValue, string $methodName): ?string
    {
        $directives = $fieldValue->getField()->directives;

        foreach ($directives as $directive) {
            if ($directive->name->value === 'namespace') {
                return Utils::namespaceClassname(
                    Str::studly($fieldValue->getFieldName()),
                    [$directive->arguments[0]->value->value],
                    static fn (string $class): bool => method_exists($class, $methodName),
                );
            }
        }
        
        return parent::findResolverClass($fieldValue, $methodName);
    }
}

[spawnia]

Why not just add App\\GraphQL\\Mutations\\User and other field-groups you might have to namespaces.queries in your config/lighthouse.php file?

[DelDaGhost]

You are correct, that seems like a more practicable approach then the one I suggested. Since you can also apply it to validators which my approach doesn't.

But I'm also not perfectly happy with it for 2 reasons:

• When the project becomes bigger this folder-array will become really big and I guess it impacts performance when lighthouse needs to loop through all of them to find the resolver
• Since it is just a string which points to a folder there is no IDE-Support which means when refactoring big applications and deleting a model with its queries and mutations it can be easily overlooked to also remove the folder from the array.

[spawnia]

I see your point, I also think it would be preferrable to have the configuration right in the schema next to the fields.

Unfortunately, @namespace seems unsuitable for this with its current design.

"""
Redefine the default namespaces used in other directives.
The arguments are a map from directive names to namespaces.
"""
directive @namespace repeatable on FIELD_DEFINITION | OBJECT

Any argument name we would choose might clash with the name of a directive. Perhaps we just need to add a new directive for this, something like?

extend type Mutation @defaultNamespace(fields: "App\\GraphQL\\Entities\\User") {
    registerUser(input: RegisterUserInput!): User!
}

However I also think that adds complexity, which might be unnecessary. Some reasons why I am not a big fan:

• GraphQL itself does not know namespaces for fields, thus putting all custom resolver classes in a single directory is advantageous to avoid duplicates. Avoiding namespaces encourages good naming that still makes sense for API consumers that never see your PHP code.
• The organisation of fields in groups/entities/whatever is already done in the GraphQL schema file - you can look there to see some structure. You can just autogenerate your fields with an artisan command, it will generate the class right where it needs to be, you never even have to open the directory where all the resolver classes reside.

[DelDaGhost]

From seeing it in action I agree with your point that the namespace-directive is not the best choice for this.
Unfortunately I also don't think that a new directive would really solve this problem since you would only be able to apply it to Queries and Mutations but not to validators of input-types.

When writing the CustomResolverProvider I debugged it in order to see all the information I can use.
At least personally for my use-case it would have been perfect to have the information in which graphql-file the field was declared. Idk if thats something which is doable.
But if it would be than people would be able to break the schema down in multiple-files and write a CustomResolverProvider which derives the folder based on the schema-file.

I completely agree with your first-point here.

However with the second-point I'm not 100% with you. It's true that the classes can be auto-generated (which is amazing, thx for that feature :)) but you still have to write some custom-code there in order to resolve it and therefore also refactor it in case you need to change that field.
I know you could always look at the graphql-file, but I personally am a big fan to structure the code-base in a way that if you need to change something, that you can just go through the folder-structure and easily find the right file without looking at any references or using a search-function.

[spawnia]

At least personally for my use-case it would have been perfect to have the information in which graphql-file the field was declared. Idk if thats something which is doable.

It would be very complicated to maintain this information in schema merging. Also, it might not be practical for every case since the GraphQL schema might not even come from a file - see https://lighthouse-php.com/master/api-reference/events.html#lifecycle-events.

I personally don't look at the folder structure of my app much at all and rely solely on search by filename or content.

Thanks for the discussion. I have decided that I do not want to add such a feature. In addition to the reasons I provided against namespaces, I also think it is valuable to keep Lighthouse simple and have one way of doing things. I think it is better for long-term maintainability of the project to just stick with one approach that is well-documented - newcomers to the app will have a much easier time figuring out what is going on.

[DelDaGhost]

Ok, thank you for taking a look at this and thinking it through :)