Expose inner value of GraphQLResponse.

[RyogaK]

In my use case, I need to parse the GraphQLResponse from Juniper’s response and record it as structured logs. While GraphQLRequest has a public (pub) internal structure, but the internals of GraphQLResponse are not accessible, so currently, I have to serialize it once and then re-parse it as a string. This intermediary processing is cumbersome, and I would like to directly access the internal data of GraphQLResponse.

[LegNeato]

Thanks for the change! Perhaps it is better to have an into_result function to mirror the from_result function?

I would also love a simple test that uses the function so we can make sure to not regress accidentally.

[RyogaK]

@LegNeato Thank you for the idea. However, in GraphQLRequest (not GraphQLResponse), the internal values are exposed as pub, and there is no test there at all. In Rust, pub values remain immutable unless marked as mut, ensuring that no logic can be violated. So, what exactly is the purpose of this test? Additionally, the name into_result suggests that it moves self, but GraphQLResponse needs to consistently be returned as a response after its contents are inspected by middleware. Therefore, I believe that cloning it solely for the purpose of referencing its contents is not appropriate.

[tyranron]

@RyogaK

Additionally, the name into_result suggests that it moves self, but GraphQLResponse needs to consistently be returned as a response after its contents are inspected by middleware. Therefore, I believe that cloning it solely for the purpose of referencing its contents is not appropriate.

No need to .clone(). let res = resp.into_result(); -> log::info!("{res:?}"); -> let resp = GraphQLResponse::from_result(res).

In Rust, pub values remain immutable unless marked as mut, ensuring that no logic can be violated.

It's not a mutability being a concern. publicity of fields is usually a concern of API future-proofing.

However, in GraphQLRequest (not GraphQLResponse), the internal values are exposed as pub.

That should be revisited at some point to.

[tyranron]

@RyogaK if you're not against the proposed solution, I'll get it done and merged.

[RyogaK]

@tyranron
I see. I have no objections to your suggestion. Since I have been occupied with other matters, I truly appreciate you handling the implementation on my behalf.