Extension Support

[michaelbird1155]

Hey all, I am getting started with this code first approach. So far I like and appreciate all the work that has been done. I am curious if there is any support for returning an extensions object? I see in the ExecutionResponse there is already code to add errors, data, and extensions to the response but I don't see a way to add extensions in the documentation. I have tried accessing the context object in the @query method in hopes of adding extensions through the ExecutionInput object but it is too far down the chain of events at that point.

My main use case is having field deprecation notices in the response. The partial response with the error and nested extension object doesn't seem the right fit as there isn't an error and the field still needs to be returned. Any ideas or solutions are appreciated! Thanks!

[phillip-kruger]

I do not think this is possible to contribute to extension of a response currently, although you might be able to do so using some of the events (Like AfterExecute) or something. For your specific use case: I do not think that deprecation information should be on a runtime response, but rather on the schema, and that is something that we should support and have been on our list for a while now (in fact I am not sure if we implemented this already, maybe @t1 or @jmartisk can remember). The idea is to use the normal @Deprecated annotation in your code and that will translate to https://spec.graphql.org/June2018/#sec-Field-Deprecation in GraphQL. We might also introduce our own annotation in case you want to deprecate it on GraphQL only (and not in Java)

It would be a good time to add this feature (if we have not already done so) ...

[phillip-kruger]

@jmartisk @mskacelik is something you want to look at ?

[michaelbird1155]

Thanks for the quick response! I have created a custom @Deprecated annotation that I apply to my fields that translates to the schema. The only other directives that came out of the box were some constraints. I think it would make sense to support the directives that are toggled on/off in schema. So far I haven't found an existing field annotation for those.

As far as reaching our customers, do you think having the deprecated notice in the schema is sufficient? Devs may not go back to look at the schema and may have greater chance of seeing a deprecation notice in the response.

[phillip-kruger]

Client (mostly) validate against the schema, so I would think it should be ok ? But I am not sure. I think for a start we can add the support for @deprecate as that should be done anyway and is part of the GraphQL Spec. As a separate issue we can look at allowing developers to contribute to the extension (I think that is reasonable) and if you want to use that for deprecation notice you can do so. How does that sound ?

[michaelbird1155]

I think that sounds very reasonable. I'm going to step away to pick up kids, but I'll try to follow up on this more tomorrow. Thanks @phillip-kruger !

[jmartisk]

Regarding the @Deprecated annotation, I think we could potentially transform java.lang.Deprecated to a directive, but there's a problem that it should support a reason parameter (per https://spec.graphql.org/draft/#sec--deprecated) and the java.lang.Deprecated annotation doesn't have any such parameter, so we wouldn't know where to find the reason. Perhaps we should instead add our own custom annotation, like io.smallrye.graphql.api.Deprecated that contains a reason? WDYT @phillip-kruger ?

[phillip-kruger]

Sounds good to me. io.smallrye.graphql.api.Deprecated will eventually move to MP. See eclipse/microprofile-graphql#47

[jmartisk]

Ok I've reported #1736

[michaelbird1155]

@phillip-kruger What needs done to allow developers to contribute to the extensions object?

[phillip-kruger]

We do a release when needed. @jmartisk when is the next one planned?

[jmartisk]

What branch are we talking about? 2.1.x, 2.0.x or 1.9.x?
We haven't yet backported the feature to 2.0.x and 1.9.x, but I assume we could do that if needed

[jmartisk]

After I know what branch, I can do a release almost at any time, we don't really have a strict schedule

[michaelbird1155]

I assume that 2.x are Jakarta EE and we aren't there yet. We are still on Quarkus 2 so I'm thinking the 1.9.x will do. Can you backport these two issues? #1736 #1750

[jmartisk]

Ok I've confirmed with the Quarkus release coordinator that there will actually still be another 2.16 release, so I'll try to release SmallRye GraphQL 1.9.3 and sneak it in there..