[SPIKE] HasMany relation definition to REST API with auto-generated repository/controller classes

[emonddr]

In LoopBack 3, it is very easy to get a fully-featured relational REST API with very little code: a model definition describing model relations + a model configuration specifying which datasource to use.

Let's enhance the solution provided by #2036 to include support for relations too.

This spike will focus on the hasMany relation, and will serve as an example of how to approach the other relations (supported by LB4).

• User creates a model class and uses decorators to define a hasMany model relation

• User declaratively defines what kind of data-access patterns to provide (CRUD, KeyValue, etc.) and what datasource to use under the hood - will be provided by From model definition to REST API with no custom repository/controller classes #2036

• @loopback/boot processes this configuration and registers appropriate repositories & controllers with the app.

Acceptance criteria

• A design proposal and PoC implementation showing how can extensions contribute changes needed to expose relation APIs, e.g. register inclusion resolvers and expose new controller methods. This should build on top of From model definition to REST API with no custom repository/controller classes #2036 (see also the proposal from spike Spike: booter for creating REST APIs from model files #3617).

• Updated examples/todo-list showing the proposed solution in practice. You can use the modifications from Spike: booter for creating REST APIs from model files #3617 to convert the current todo-list app to leverage ModelApiBooter.

• A spike document (a markdown file in your spike branch) explaining the proposal, documenting which different options were considered (and why they were rejected), etc. The document should also outline follow-up implementation tasks.

[emonddr]

@bajtos ^

[jannyHou]

Team has different opinions on the how to resolve the relational path.

Copied from #2855

Before we construct the relation controller from the static file, we need to decide where to define the relation endpoints(in a new controller class or in "modelFrom"'s controller), and how to resolve the relational path's url.

This story may need a spike to figure out how to map the relational paths to REST endpoints.

Reference story:
Hierarchical resource locator: #802

/Users/{id}/orders

* delegate to user controller

* user controller interprets the `/orders`, resolve the url

* delegate to order controller

Proposal:
Delegate the url resolve to controller, instead of defining the path pattern in relation controller

And @bajtos 's reply in #2483 (comment):

We should be using the same approach we already have in place for relations, where a new controller class is created for every relation. E.g. UserOrdersController to handle all endpoints in /Users/{id}/orders path space.

Let's make a decision in this spike for ^

[bajtos]

Acceptance criteria

• Implementation
• Automated tests
• Update API docs
• Update appropriate README files

@emonddr those acceptance criteria make sense for the real implementation. Spike stories have different goals, we want to explore & experiment with different approaches without having to pay the cost of full test coverage & docs.

Here is a better list based on #2738:

• A design proposal and PoC implementation showing how can extensions contribute changes needed to expose relation APIs, e.g. register inclusion resolvers and expose new controller methods. This should build on top of From model definition to REST API with no custom repository/controller classes #2036 (see also the proposal from spike Spike: booter for creating REST APIs from model files #3617).

• Updated examples/todo-list showing the proposed solution in practice. You can use the modifications from Spike: booter for creating REST APIs from model files #3617 to convert the current todo-list app to leverage ModelApiBooter.

• A spike document (a markdown file in your spike branch) explaining the proposal, documenting which different options were considered (and why they were rejected), etc. The document should also outline follow-up implementation tasks.

I am going to update acceptance criteria with the list.

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.