Can the plugin support getFields() in GraphQLResponseProjection?

Discussed in https://github.com/kobylynskyi/graphql-java-codegen/discussions/984

<div type='discussions-op-text'>

^{Originally posted by ruipliu July 22, 2022} This is to support complex use cases from client side building queries.

Now the response projections only have builder methods to add fields. But in client side there are certain business needs to dynamically build queries. The current client practice is creating the response projections and adding the fields in one time, which is hard coding. Could the plugin support getFields() in GraphQLResponseProjection for clients to access the fields in response projection after they created?

Here is an example:

Consider the [User - Order - Product] model.

• Use case 1: load ‘user.orders.products.name’ for each getUser query
• Use case 2: load ‘user.orders.status’ and ‘user.orders.products.status’ for each getUser query
• etc

In the client application, we might need data in use case 1 or use case 2 or use case 1 & 2. Hence we need to write 3 UserResponseProjection. If we have 10 use cases and their combinations exploded, we would prefer having a UserResponseProjection for each use case and combine these projections if we want to load fields in multiple use cases, which needs the fields attribute accessible.</div>

[kobylynskyi]

@ruipliu, thanks for your response.

To your 1st point:

The current response projection class does not support deduplication of fields. If we take your idea, the fields addition mechanism would be complex, as we need to deduplicate the field tree when we add a new field.

This should not be a problem. I think we can use a LinkedHashMap instead of a List for storing response projection fields (for deduplication purposes): https://github.com/kobylynskyi/graphql-java-codegen/blob/7364f7dd7d5696f73667f713e3a8e30a526d2326/src/main/java/com/kobylynskyi/graphql/codegen/model/graphql/GraphQLResponseProjection.java#L13

To your 2nd point:

I am fine with making the response projections immutable. But from your idea, if we want to build a response projection on top of another, we still need to hard code adding every fields. Shall we create a constructor or factory method that take in a list of response projection and internally combine into one? If so, we could reach an optimal position that we could maintain a response projection for each business requirement, and merge them if having multiple requirements.

What do you mean by hard code adding every fields? Also take in a list of response projection and internally combine into one - how does this become beneficial? Can you provide an example? Also, note that even today you can do the following:

ProductRespProj minimalProductDetails = new ProductRespProj()
        .id().name())
ProductRespProj extendedProductDetails = new ProductRespProj()
        .id().name().price().sku())

ParentRespProj proj1WithMinimalProductDetails = new ParentRespProj()
        .user(new UserRespProj()
                .id()
                .order(new OrderRespProj()
                        .total()
                        .product(minimalProductDetails)
                )
        )
ParentRespProj proj2WithExtendedProductDetails = new ParentRespProj()
        .user(new UserRespProj()
                .id()
                .order(new OrderRespProj()
                        .total()
                        .product(extendedProductDetails)
                )
        )

And with a “constructor” thing it will make a code cleaner by extending proj2 by reusing proj1:

ParentRespProj proj2WithExtendedProductDetails = new ParentRespProj(proj1WithMinimalProductDetails)
        .user(new UserRespProj()
                .order(new OrderRespProj()
                        .product(extendedProductDetails)
                )
        )

Do you see how we can make projections more reusable? Please provide code samples if you can.

[ruipliu]

Hi @kobylynskyi ,

There are two comments on your idea:

1. The current response projection class does not support deduplication of fields. If we take your idea, the fields addition mechanism would be complex, as we need to deduplicate the field tree when we add a new field.
2. I am fine with making the response projections immutable. But from your idea, if we want to build a response projection on top of another, we still need to hard code adding every fields. Shall we create a constructor or factory method that take in a list of response projection and internally combine into one? If so, we could reach an optimal position that we could maintain a response projection for each business requirement, and merge them if having multiple requirements.

Please let me know your comment. Thanks.