GraphQL client: @NestedParameter vs hard-coded inputValue

[jmini]

On the GitLab GraphQL api you can do:

query readGroupAndLabels {
  group(fullPath: "tech-marketing/demos/gitlab-agile-demo/initech") {
    name
    webUrl
    labels(includeAncestorGroups: true, after: "eyJ0aXRsZSI6IndvcmtmbG93OjpxYSIsImlkIjoiMTM1NDg4NDEifQ") {
      nodes {
        id
        title
        description
        color
      }
      pageInfo {
        hasNextPage
        endCursor
      }
    }
  }
}

Can be executed here: https://gitlab.com/-/graphql-explorer

---

With the Typesafe GraphQL client, it is possible to use @NestedParameter like this:

    Group readGroupAndLabels(
            @Name("fullPath") @NonNull @Id String fullPath, 
            @Name("includeAncestorGroups") @NestedParameter("labels") boolean labelsIncludeAncestorGroups, 
            @Name("after") @NestedParameter("labels")  String labelsAfter
    );

Working example: https://github.com/jmini/gitlab-experiments/tree/main/smallrye-graphql-client

But this parametrize the query:

query readGroupAndLabels {
  group(fullPath: $arg0) {
    name
    webUrl
    labels(includeAncestorGroups: $arg1, after:  $arg2) {
      nodes {
        id
        title
        description
        color
      }
      pageInfo {
        hasNextPage
        endCursor
      }
    }
  }
}

Which is fine, but I am wondering if I can set the input value to be set to a specific value, instead of surfacing it at method member.

[t1]

You mean as a constant, e.g. for includeAncestorGroups, because you always want the ancestor groups? No, that's currently not possible. Nice idea, though. Something like an annotation on the method, e.g. @ConstantParameter(name = "labels.includeAncestorGroups", value = "true")?

But looking at your code, maybe you want to enable the -parameters compiler option. Then you wouldn't have to use the @Name annotations to repeat the parameter name (you could leave it on labelsIncludeAncestorGroups or rename the parameter to includeAncestorGroups). This would also make the query string nicer... I agree, this is not very important ;-)

[jmini]

But looking at your code, maybe you want to enable the -parameters compiler option.

Yes the @Name is just a work-around because I can't use quarkus right now quarkusio/quarkus#43756 and I wanted the initialization code:

        WorkitemClientApi api = TypesafeGraphQLClientBuilder.newBuilder()
                .allowUnexpectedResponseFields(true)
                .build(WorkitemClientApi.class);

To work everywhere (regardless of the IDE / build tools settings).
So yes the @Name is redundant with the variable name, but right now I do not care.

Something like an annotation on the method, e.g. @ConstantParameter(name = "labels.includeAncestorGroups", value = "true")?

I think it would make sense. And be consistent with @NestedParameter.

An other idea (not sure if it is better), could be on the field itself:

public class Group {
    //... 
  
    @ConstantParameter(name = "includeAncestorGroups", value = "true")
    private LabelConnection labels;

}

Since the java class correspond to the GraphQL Type (with Kind OBJECT), the java field labels in the class corresponds to the GraphQL Field and this can have arguments. So it feels natural to have the option to put it there as well.

Is an issue needed for this?

[t1]

An annotation on the field sounds good, too. But it would have to have the semantics of a default, because you might want to actually pass this parameter to some methods, while others should rely on the default..

We eventually will need an issue and... a PR 😁