Support "all" in client response projection

[jxnu-liguobin]

Is your feature request related to a problem? Please describe.
Hi, since the last time we used dynamic automatic call, we think it is better to use automatic generation completely because there may be performance problems with the proxy. Now we consider that we can also entrust the implementation to the framework generation. Of course, I think this may have exceeded the responsibility of this framework.

I have roughly written a template and implemented it by associating entity resolver returnType.
In this way all codes will be fully automated,however, I think it may increase the framework coupling.

Describe the solution you'd like
ftl:

<#if package?has_content>
    package ${package};


</#if>
import com.fasterxml.jackson.core.type.TypeReference;
import com.kobylynskyi.graphql.codegen.model.graphql.GraphQLOperation;
import com.kobylynskyi.graphql.codegen.model.graphql.GraphQLOperationRequest;
import com.kobylynskyi.graphql.codegen.utils.Utils;
import io.github.dreamylost.OkHttp;
import scala.concurrent.Await;
import scala.concurrent.duration.Duration;
import scala.concurrent.ExecutionContext.Implicits.global;
<#list imports as import>
    import ${import}.*;
</#list>

<#if javaDoc?has_content>
/**
<#list javaDoc as javaDocLine>
 * ${javaDocLine}
</#list>
 */
</#if>
<#if generatedInfo.getGeneratedType()?has_content>
@${generatedInfo.getGeneratedType()}(
    value = "com.kobylynskyi.graphql.codegen.GraphQLCodegen",
    date = "${generatedInfo.getDateTime()}"
)
</#if>
public class ${className}<#if implements?has_content> extends <#list implements as interface>${interface}<#if interface_has_next>, </#if></#list></#if> {

    public ${className}() {
    }

<#list operations as operation>
<#if operation.javaDoc?has_content>
    /**
    <#list operation.javaDoc as javaDocLine>
     * ${javaDocLine}
    </#list>
     */
</#if>
<#if operation.deprecated>
    @Deprecated
</#if>
<#list operation.annotations as annotation>
    @${annotation}
</#list>
    ${operation.type} ${operation.name}(${requestType} operateRequest) throws Exception {
    <#if projectionType?has_content>
        ${projectionType} projection = new ${projectionType}();
        for (Method m : projection.getClass().getDeclaredMethods()) {
            Utils.selectOnProjection(projection, m, 1, ${max});
        }
        <#else>
        Object projection = null;
    </#if>
        GraphQLRequest graphQLRequest = new GraphQLRequest(operateRequest, projection);
        Future<${operation.type}> retFuture = OkHttp.executeRequest(graphQLRequest, new TypeReference[${operation.type}] {});
        ${operation.type} ret = Await.result(retFuture, Duration.Inf());
        return ret;
    }

    ${operation.type} ${operation.name}(${requestType} operateRequest<#if projectionType?has_content>, ${projectionType} projection</#if>) throws Exception {
        GraphQLRequest graphQLRequest = new GraphQLRequest(operateRequest, projection);
        Future<${operation.type}> retFuture = OkHttp.executeRequest(graphQLRequest, new TypeReference[${operation.type}] {});
        ${operation.type} ret = Await.result(retFuture, Duration.Inf());
        return ret;
    }

</#list>
}

will generate code like this :

import com.fasterxml.jackson.core.type.TypeReference;
import com.kobylynskyi.graphql.codegen.model.graphql.GraphQLOperation;
import com.kobylynskyi.graphql.codegen.model.graphql.GraphQLOperationRequest;
import com.kobylynskyi.graphql.codegen.utils.Utils;
import io.github.dreamylost.OkHttp;
import scala.concurrent.Await;
import scala.concurrent.duration.Duration;
import scala.concurrent.ExecutionContext.Implicits.global;

/**
 * Create a new event.
 */
@javax.annotation.Generated(
    value = "com.kobylynskyi.graphql.codegen.GraphQLCodegen",
    date = "2020-12-31T23:59:59-0500"
)
public class CreateEventMutationResolverImpl {

    public CreateEventMutationResolverImpl() {
    }

    /**
     * Create a new event.
     */
    @javax.validation.constraints.NotNull
    Event createEvent(CreateEventMutationRequest operateRequest) throws Exception {
        EventResponseProjection projection = new EventResponseProjection();
        for (Method m : projection.getClass().getDeclaredMethods()) {
           //support response all fields in GraphQLResponseProjection
            Utils.selectOnProjection(projection, m, 1, 3);//Projection will be called recursively
        }
        GraphQLRequest graphQLRequest = new GraphQLRequest(operateRequest, projection);
        Future<Event> retFuture = OkHttp.executeRequest(graphQLRequest, new TypeReference[Event] {});
        Event ret = Await.result(retFuture, Duration.Inf());
        return ret;
    }

    Event createEvent(CreateEventMutationRequest operateRequest, EventResponseProjection projection) throws Exception {
        GraphQLRequest graphQLRequest = new GraphQLRequest(operateRequest, projection);
        Future<Event> retFuture = OkHttp.executeRequest(graphQLRequest, new TypeReference[Event] {});
        Event ret = Await.result(retFuture, Duration.Inf());
        return ret;
    }

}

use it:

//will response all fields and limit depth is` max`, a new option in plugins.
new CreateEventMutationResolverImpl().createEvent(new CreateEventMutationRequest().setId("id222"))
//or select fields
new CreateEventMutationResolverImpl().createEvent(new CreateEventMutationRequest().setId("id222"), new EventResponseProjection().id())

and if GraphQLResponseProjection can provider a selectAll method, do not need invoke Utils.selectOnProjection(projection, m, 1, 3);
so, can implement selectAll ?

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[kobylynskyi]

I like the idea of "selectAll" for projection.
But resolver impl generation - is not a responsibility of this library because there is an unlimited amount of possible implementations.

[jxnu-liguobin]

But resolver impl generation - is not a responsibility of this library because there is an unlimited amount of possible implementations.

Yes, I think so too, so I may have to maintain a separate image library of graphql Java CodeGen to support this function.
On the other hand, if it's possible to support selectAll in projection, i can implement generate resolver' impl more convenient in my mirror repo.

[jxnu-liguobin]

i write like this in LocationResponseProjection:

    ......
    private LocationResponseProjection projection = new LocationResponseProjection();
    private Map<String, Integer> subProjectionDepth = new HashMap<String, Integer>();

    public LocationResponseProjection selectAll() {
            projection = projection.id();
            projection = projection.locationType();
            if (subProjectionDepth.getOrDefault("onCustomerLocation", 0) < 5){ //5 is a maxDepth plugin's option
             //Avoid the infinite nesting of `selectAll` that might exist, of course, I'm just guessing.
                subProjectionDepth.put("onCustomerLocation", onCustomerLocation.getOrDefault("onCustomerLocation", 0) + 1);
                projection = projection.onCustomerLocation(new CustomerLocationResponseProjection().selectAll());
            }
            if (subProjectionDepth.getOrDefault("onDealerLocation", 0) < 5){
                subProjectionDepth.put("onDealerLocation", onDealerLocation.getOrDefault("onDealerLocation", 0) + 1);
                projection = projection.onDealerLocation(new DealerLocationResponseProjection().selectAll());
            }
            projection = projection.typename();
        return projection;
    }
    ......

ftl

<#if fields?has_content>
    private ${className} projection = new ${className}();
    private Map<String, Integer> subProjectionDepth = new HashMap<String, Integer>();

    public ${className} selectAll() {
    <#list fields as field>
        <#if field.type?has_content>
            if (subProjectionDepth.getOrDefault("${field.methodName}", 0) < ${maxDepth}){
                subProjectionDepth.put("${field.methodName}", ${field.methodName}.getOrDefault("${field.methodName}", 0) + 1);
                projection = projection.${field.methodName}(new ${field.type}().selectAll());
            }
        <#else>
            projection = projection.${field.methodName}();
        </#if>
    </#list>
        return projection;
    }
</#if>

If this method can be accept, I will submit PR and add option in plugins.

[kobylynskyi]

@jxnu-liguobin the problem is that there could be a field named selectAll and there will be a conflict.
Need to think about method name..

[jxnu-liguobin]

@jxnu-liguobin the problem is that there could be a field named selectAll and there will be a conflict.
Need to think about method name..

yes, indeed, there may be a field called SelectAll.

[jxnu-liguobin]

@jxnu-liguobin the problem is that there could be a field named selectAll and there will be a conflict.
Need to think about method name..

Is it possible to use uppercase or append suffixes? if we need a special method name, we can use $ , it also be used in scala, example:
scalac HelloWorld.scala after compiling two files are generated HelloWorld.class and HelloWorld$.Class.

(As it happens, we are the code generation library)
so $ is an available for class/method which composite by system.and it cannot be used in graphql schema.

http://spec.graphql.org/June2018/#sec-Punctuators

[joffrey-bion]

@jxnu-liguobin @kobylynskyi I'm not sure I understand the use case for selectAll correctly, but I have to point out that this defeats the essence of GraphQL, and the very reason why we use it over REST in my company.

The point of having to query fields manually is that you can convey information to the backend about what you really need as a client from the server's response. This allows servers to use fine-grained usage metrics in order to deprecate/remove fields that are queried by no clients (in a backwards compatible manner). If clients start querying "all fields", they will query fields they don't need, and that's definitely a no-go.

You can argue that people can manually declare every field one by one and query what they don't need but this is really not the same:

1. this needs conscious effort, so you wouldn't spend time querying everything if you didn't need the data
2. there is no accidental growth in the queried fields, meaning that updating the schema wouldn't magically add new fields to your query (as opposed to using selectAll)
3. you can see deprecated fields and act on it (which you can't do with selectAll)

Could you please clarify the benefit of supporting selectAll? (which GraphQL doesn't support in its query language)

[jxnu-liguobin]

@jxnu-liguobin @kobylynskyi I'm not sure I understand the use case for selectAll correctly, but I have to point out that this defeats the essence of GraphQL, and the very reason why we use it over REST in my company.

The point of having to query fields manually is that you can convey information to the backend about what you really need as a client from the server's response. This allows servers to use fine-grained usage metrics in order to deprecate/remove fields that are queried by no clients (in a backwards compatible manner). If clients start querying "all fields", they will query fields they don't need, and that's definitely a no-go.

You can argue that people can manually declare every field one by one and query what they don't need but this is really not the same:

1. this needs conscious effort, so you wouldn't spend time querying everything if you didn't need the data
2. there is no accidental growth in the queried fields, meaning that updating the schema wouldn't magically add new fields to your query (as opposed to using selectAll)
3. you can see deprecated fields and act on it (which you can't do with selectAll)

Could you please clarify the benefit of supporting selectAll? (which GraphQL doesn't support in its query language)

1. Support automatic projection generation，At present, only this is supported.
2. Support full projection by default,It's true that this doesn't take some advantages of graphql.
   but as a private platform, graphql schema is open to customers. schema often has many levels of nesting, and users must to call them in turn.

However, this brings great convenience, so users should weigh the convenience and the amount of data. Of course, users can also use partial projection.

As you all know(in private platform), the user can see the useless and expired fields, but since the user has already known the graphql schema definitions and deprecated description. the user should be responsible even if there is an error in the use of the request.

But in saas platform, the uses cannot see graphql schema definitions, so, there may be possible what you said.

To sum up, we can consider it as an experimental function and add a experimental annotation.

[kobylynskyi]

@joffrey-bion thanks for your input.
I agree, all method does confront with GraphQL principles. But it could still be used for testing purposes (e.g. in integration tests). What do you think?

[joffrey-bion]

@kobylynskyi I see.

I'm still not entirely convinced, but if @jxnu-liguobin has a use case for which selectAll would be helpful, I won't be opposed to this change.

[jxnu-liguobin]

@kobylynskyi I see.

I'm still not entirely convinced, but if @jxnu-liguobin has a use case for which selectAll would be helpful, I won't be opposed to this change.

This is my project, open source, but only a draft https://github.com/growingio/growingio-graphql-javasdk
(chinese)