Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Spike] Explorer the way to resolve inclusion property #2152
Description / Steps to reproduce / Feature proposal
A follow-up story of the relation traverse spike #1952
The previous spike story turns out that we could improve our design of describing&defining model properties.
Copied the discussion and proposal from it:
Thanks for all the feedback!
I understand that the best outcome of a spike is a concrete solution, but I am afraid the inclusion story is more complicated than we expect, and it would be better to create separate stories to explorer different potential approaches.
Like what @raymondfeng points out, GraphQL's query system has two features we could borrow:
And a overall design question to consider (from @bajtos ) :
How are we going to generate JSON Schema and OpenAPI schema for payloads containing both model properties (Customer's id, name, email) and data of related model (Customer's orders, addresses, etc.). At the moment, we are leveraging @Property metadata. If we choose a different approach for describing model+relations in TypeScript, then we also need a new way how to obtain JSON Schema for such new types.
Here is a proposal of the next steps:
As I understand LB4 design, the Model class is describing shape of the data only, it does not deal with obtaining that data (fetching it from a database or resolving a model relation). It's the Repository that deals with resolving model relations and fetching related data.
We are following this design in HasMany/BelongsTo relation too. You can think of
I feel that your proposal proposal to move resolvers to model classes is violating this design constraint and we should investigate different approaches.
Re-posting the code sample from the problematic proposal: