Mutation namespaces

[ChvilaMartin]

Hello, hopefully this is not duplication of existing issue.

Is there support for Mutation namespaces like described there: https://graphql-rules.com/rules/mutation-namespaces?

What I want is to be able to have something like this

UserMutations {
   create(name: String!): String!,
   update(id: String!, name: String!): Boolean!,
   ....
},
PostMutations {
   ...
}

[oojacoboo]

@ChvilaMartin that's pretty cool. Unfortunately, that's not currently supported. I also don't see any support for this with https://github.com/webonyx/graphql-php. We'd need support there before adding support for that here.

[enumag]

@oojacoboo Webonyx supports it just fine. Or rather no additional support on their side is needed to implement it. I'm using it on another webonyx-based project. Here is how it works:

First I have types like these, representing the mutation namespaces:

final class UserMutationsType extends ObjectType
{
    public function __construct()
    {
        parent::__construct([
            'name' => 'UserMutations',
            'fields' => function () {
                return [
                    'create' => [
                        // definition of the create mutation
                    ],
                ];
            },
        ]);
    }
}

Next the MutationType needs to use these:

final class MutationType extends ObjectType
{
    public function __construct(ContainerInterface $typeResolver)
    {
        parent::__construct([
            'name' => 'Mutation',
            'fields' => function () use ($typeResolver) {
                return [
                    'user' => [
                        'type' => $typeResolver->get('UserMutations'),
                        'resolve' => function ($value, $args, $context, ResolveInfo $info) {
                            return [];
                        },
                    ],
                ];
            },
        ]);
    }
}

Easy enough in my opinion.

[oojacoboo]

@enumag thanks for the clarification here. This seems like a worthwhile improvement if someone wants to add a PR. It might be helpful to discuss implementation proposals prior.

[Lappihuan]

I've been thinking about this lately and feel like a Namespace Attribute on Controllers would be the most logical. Imagine:

#[GQL\Namespace]
class UserController {
    #[GQL\Query]
    public function user()...

    #[GQL\Mutation]
    public function create()...

    #[GQL\Mutation]
    public function update()...

    #[GQL\Mutation]
    public function delete()...

Which would result in this Schema:

UserMutations {
   create()...
   update()....
   delete()...
}

While the user Query is ignored by the Namespace and still directly under the Root Query.

[enumag]

It's actually already possible with current graphqlite. No extra features are necessary, just usage of the existing attributes, mainly ExtendType and Field.

[Lappihuan]

I mean yes its possible, but but hacky. And the goal of graphqlite is great DX, with the Namespace Attribute it can be backwards compatible and easily added to existing projects with very little work.

[oojacoboo]

@Lappihuan I like the namespace attribute idea. This would create a clean API in GraphQLite.

[Lappihuan]

@oojacoboo i'd like to base this on the work of #466 should i branch from there or do you see #466 merged soon?

[oojacoboo]

I'd like to get #466 merged into master soon and target a 6.0 release. I haven't had a chance to test any of it yet. Any additional eyes on it would be helpful.

[oojacoboo]

@Lappihuan let's keep it in another branch though. #466 already has way too much in it. I'd really like to keep things separated out. It makes it much easier to focus discussion, reviews and merges. I know it's a bit more work on the PR creation side.

[oojacoboo]

The PR attempt for adding mutations was closed and not merged. See the PR for additional details and reasoning.

There is an ongoing proposal to add metadata support to the GraphQL spec. This is probably the ideal way of handling this need.

I'm going to leave this ticket open, as the need for some sort of namespace like support still exists.