Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mutation namespaces #440

Open
ChvilaMartin opened this issue Feb 11, 2022 · 11 comments
Open

Mutation namespaces #440

ChvilaMartin opened this issue Feb 11, 2022 · 11 comments
Labels
additional info needed Additional information is needed to proceed dependencies Pull requests that update a dependency file enhancement New feature or request

Comments

@ChvilaMartin
Copy link

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
Copy link
Collaborator

@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.

@oojacoboo oojacoboo added additional info needed Additional information is needed to proceed dependencies Pull requests that update a dependency file labels Feb 11, 2022
@enumag
Copy link

enumag commented Feb 17, 2022

@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
Copy link
Collaborator

oojacoboo commented Feb 17, 2022

@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
Copy link
Contributor

Lappihuan commented Apr 22, 2022

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
Copy link

enumag commented Apr 22, 2022

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

@Lappihuan
Copy link
Contributor

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
Copy link
Collaborator

oojacoboo commented Apr 22, 2022

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

@Lappihuan
Copy link
Contributor

@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
Copy link
Collaborator

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
Copy link
Collaborator

@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 oojacoboo pinned this issue Jun 12, 2022
@oojacoboo
Copy link
Collaborator

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.

@oojacoboo oojacoboo added the enhancement New feature or request label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
additional info needed Additional information is needed to proceed dependencies Pull requests that update a dependency file enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants