Ability to combine multiple response projections

[ruipliu]

Discussed in #984

^{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.

[jxnu-liguobin]

If you don't care about to get all the values, you can use all$. Otherwise, it can't now.

[kobylynskyi]

@ruipliu if I understand correctly your problem statement, you want the ability to create a new instance of GraphQLResponseProjection out of another instance of GraphQLResponseProjection.
Is that true?
If yes, then this is a fairly simple feature to implement.

[ruipliu]

@kobylynskyi Yes correct.
Based on my knowledge of the source code, the only change is to add getFields() in GraphQLResponseProjection.java

[kobylynskyi]

Unfortunately adding getFields() method might be a breaking change for the clients who have a type with field getFields - because getFields() method will already be present in the TypeResponseProjection.

So the approach of creating an additional "copy" constructor would be better, what do you think?

Type1ResponseProjection type1 = new Type1ResponseProjection();
Type1ResponseProjection type1Copy = new Type1ResponseProjection(type1);

[ruipliu]

Sorry for the late reply.
The "copy" constructor may not work. As the aim of creating from existed one is to get the fields from a projection so that the field tree can be modified when or after creating.

For example, if we want to add price of a product in a projection having user.order.product.name field tree, we could get the product field and add accordingly.

Here are some alternative solutions, could you give some comments?

1. add special character in getFields(), like getFields$()
2. make 'fields' public

[jxnu-liguobin]

We should not modify the original getFields.

[ruipliu]

We should not modify the original getFields

There is no getFields() in current Graph l response projection. We are thinking of adding this methods to access and modify the fields.

Do you mean the field attribute should not be modified?

[jxnu-liguobin]

Do you mean the field attribute should not be modified?

we should only modify it by response projection method. If the returned by getField is mutable that will break this.

The "copy" constructor may not work. As the aim of creating from existed one is to get the fields from a projection so that the field tree can be modified when or after creating.

If the internal fields can be modified after creating object, it may lead to insecurity.

[ruipliu]

If the internal fields can be modified after creating object, it may lead to insecurity.

Could you explain the insecurity case a bit more? about what scenario and what kind of security problem. Thanks!

My feeling is the ResponseProjection is only a tool for client side building GraphQL query and it would be better to provide more convenience and accessibility. Client side could make effort to assure the security when using this class.

[jxnu-liguobin]

When a projection needs to be defined and subsequently used multiple times. Some times it may be modified, which results in multiple calls not having the same result.

[kobylynskyi]

@ruipliu,
I would really prefer not to expose fields outside. This would be breaking the encapsulation principle. So let's keep it "safe" inside the class so that users don't accidentally shoot themselves in the foot.

Let's take your case as an example:

if we want to add price of a product in a projection having user.order.product.name field tree, we could get the product field and add accordingly.

We could still solve it with the copy-constructor thing:

ParentResponseProjection proj1 = new ParentResponseProjection()
        .user(new UserResponseProjection()
                .id()
                .order(new OrderResponseProjection()
                        .total()
                        .product(new ProductResponseProjection()
                                .name()
                        )
                )
        )

ParentResponseProjection proj2 = new ParentResponseProjection(proj1) // resuing all projection from proj1
        .user(new UserResponseProjection()
                .order(new OrderResponseProjection()
                        .product(new ProductResponseProjection()
                                .price() // this will add price to an existing projection which already has name
                        )
                )
        )

ParentResponseProjection proj3 = new ParentResponseProjection(proj1) // resuing all projection from proj1
        .user(new UserResponseProjection()
                .order(new OrderResponseProjection()
                        .product(new ProductResponseProjection()
                                .none$() // this will clean up all projected fields that might already exist
                                .id()
                        )
                )
        )

// proj1 will have { user { id order { total product { name } } } }
// proj2 will have { user { id order { total product { name price } } } }
// proj3 will have { user { id order { total product { id } } } }

How does this sound to you?