hasura / ndc-spec

NDC Specification and Reference Implementation
http://hasura.github.io/ndc-spec
20 stars 5 forks source link

RFC: Relationships and nested objects #157

Closed paf31 closed 4 months ago

paf31 commented 4 months ago

This RFC is added to illustrate the undocumented functionality of relationships in a nested field context.

Rendered RFC


rahulagarwal13 commented 4 months ago

@paf31 @codedmart In terms of the two different ways discussed to structure relationships in API responses - 1) As Nested Fields and 2) As Top-Level Entities. I believe the second approach is more modular but has the problem for supporting deeply nested arrays. I found these two related open engine Github Issues which mention the use-case of deep nesting:

daniel-chambers commented 4 months ago

I believe the second approach is more modular

@rahulagarwal13 What do you mean by "modular"?

In my opinion, only being able to mount a relationship field at the top level and not inside a nested object would be the opposite of what I would want as a user. As a user, I would want my relationship field to sit next to the foreign key property that it maps from. This is not to say I couldn't see a use case for wanting it at the top level (not nested), but I think that most of the time, users will want it nested and placed next to the nested foreign key.

rahulagarwal13 commented 4 months ago

@daniel-chambers @paf31 By modular I was referring to it being less redundant on the API response and managing related data separately and referencing it as needed. For eg. having a key relationships in the JSON object. I agree nested relationships are more intuitive and something that the user would need. On top of that supporting deeply nested arrays, is important. So the first approach of having nested fields sounds good to me.