[GraphQL] Custom Operations

[lukasluecke]

I'd like to open a discussion on the future potential for custom GraphQL operations beyond what's currently possible with #2445 and #2447 (and the minor changes afterwards).

Naming
Currently the only way to name operations is to specify a name that will get suffixed by the resource name. It would be nice to have a bit more control about this, maybe with a token for the resource name? E.g. create${Resource}Custom

Arguments
Currently the following methods exist:

• Choose specific fields from resource (denormalization_context)
• Use different class (input)
• Remove default arguments (args={})

It would be nice to be able to specify custom fields with types inline (I think @alanpoulain mentioned something about this once).

In the meantime maybe we could at least enable changing the nullability of existing fields per operation, e.g. the id field. (#2738, but customizable)

Result
Currently the following methods exist:

• Choose specific fields from resource (normalization_context)
• Use different class (output)

Setting output does not seem to work at the moment (#2754). Might be enough for now to fix this.

Otherwise the same options for custom fields and types as in the arguments would be nice to have.

[lukasluecke]

@SCIF @alanpoulain @dunglas What do you think about this?

[alanpoulain]

It would be nice to be able to specify custom fields with types inline

Yes I'm working on it.

[SCIF]

I'm ready to work on custom naming which makes a lot of sense for me. In my opinion, the name should be fully customizable. Let's arrange a way of defining the name? I don't like that name even for custom resolvers cannot be fully customized. Do you have any particular idea in mind about way of specifying an operation name?

Hi @alanpoulain , so, will it bring support of Interfaces?

@lukasluecke

Choose specific fields from resource (denormalization_context)
Sorry, what do you mean? Sounds interesting, just don't understand what this feature is.

[lukasluecke]

@SCIF

Naming: I thought about either letting the resolver override the operation name (e.g. getName method on the *ResolverInterface), or as mentioned above allow some kind of token in the name that get's parsed and replaced. Maybe we could even just add a field inside the operation config overrideName or something - this would be the smallest change, but might not be the best decision for the future 😄 So no, no particular idea in mind yet.

For the denormalization_context you could check the documentation for Using Serialization Groups per Operation and Denormalization - it's the same logic for GraphQL operations, just slightly different syntax. You can find an example of this in the DummyCustomMutation entity used for tests.

[SCIF]

Hi @lukasluecke ,

Not sure if it a good idea to get a resolver locator and instantiate all resolvers just to build a schema. In my opinion just name (don't think it worth to use any suffix or prefix here) on an operation would be the best solution in terms of explicitness and easyness of implementation.

[SCIF]

@alanpoulain , @dunglas , can we arrange some way and I will implement that? I'm ready to implement custom names and it could be used in my project :)

BTW, I'm still thinking it's really not good idea to keep all attributes under @ApiResource(grapqhl={}) since these cannot be autosuggested.

[SCIF]

Hi @lukasluecke , could you check my comment there? Is it expected requirement to specify "normalization_context" = {"iri" = "/someIri"} for any resources which are not ORM's one?

[soyuka]

I think that this deserves an ADR @alanpoulain @lukasluecke wdyt?

[sachingk]

Any updates on this ?

[sachingk]

I am playing around this from a week now. I was able to make custom naming for Mutation, Query, Subscription. I added a operation config called overrideName and decorated api_platform.graphql.fields_builder to achieve this.

What's difficult is to modify and make the operation to use custom output DTO or even another API resource. That's because everywhere in the code the resourceClass is being passed to other functions. During recurring function calls the value of the resourceClass changes the reference to the main resource class is lost.

Now because custom GraphQL operations can't return custom DTO / API resource, my project has reached dead end.

@SCIF @alanpoulain @dunglas
Any idea when will the capability of using custom output in GraphQL be released ? Seems like now more people are using GraphQL module of API-Platform than REST API

[nordnotor]

Any updates on this?

[sachingk]

Any updates on this?

I moved out of API Platform for my project. Now I am using GraphQLite.

It's more straight forward to create a query and mutation. You can create a controller class and then create a functions inside it. You can mark these functions either as query or mutation.

Needless to say, you can do anything inside the function and return the final data.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.