I probably was a bit unclear.
Lets say I've got a family tree stored in a db that goes back 1000 years.
Through graphql I want to find my first ancestor following all mothers backwards. The query would be:
query familyTree {
name,
mother {
name,
mother {
..and so on for an unknown number of nestings
}
}
}
Dataloader solves batching of the nested query on the server, but doesn't solve the problem of not knowing what the correct number of nestings the query should have.
Of course it's possible to create a new graphql endpoint for this type of query, but then we've just recreated REST in graphql.
Absolutely. Personally I haven't made much use of NoSQL, I'm sure there are plenty of use cases, but for ancestry I would still use a relational db.
I do see how nested objects might look like a perfect fit for this, since families are literally "nested objects". Perhaps there are plenty of advantages to using NoSQL and shaping the data this way... but the thought of creating an API With that structure is terrifying to me, haha.
Question to OP: are you using this structure for a live api/website I can take a look at? Does each node have an absolute ID? Do you normalize your data? Maybe I'm thinking too much in relational terms here? I'm genuinely curious about this.
Through graphql I want to find my first ancestor following all mothers backwards. The query would be:
Dataloader solves batching of the nested query on the server, but doesn't solve the problem of not knowing what the correct number of nestings the query should have.Of course it's possible to create a new graphql endpoint for this type of query, but then we've just recreated REST in graphql.