[CLI] add lb4 repository command

[hacksparrow]

Description / Steps to reproduce / Feature proposal

lb4 repository command will generate the basic repository file for a given name. It is better than copy-pasting and editing files.

Current Behavior

There is no lb4 repository command.

Expected Behavior

We should have lb4 repository command.

Acceptance Criteria

• Add lb4 repository command to @loopback/cli. Works as follows:

  • DataSource Selection (Detect in project using https://github.com/strongloop/loopback-next/blob/master/packages/cli/lib/utils.js#L210). (Infer binding key based on Boot Conventions).

  • Detect the type of Repository (DefaultCrudRepository / KVRepository) based on the DataSource (No prompt).

  • Model Selection (Detect in project using https://github.com/strongloop/loopback-next/blob/master/packages/cli/lib/utils.js#L210). This will be a multiple choice question allowing a user to select multiple models to back to same DataSource. We will generate a new class for each selected model.

  • Prompt for type of id field in Model ... if we can't infer by inspecting the Model class ourselves (Ex: Check if id property exists and set as typeof Todo.prototype.id in model or check metadata for which field is the id ... if both fail then prompt the user.

  • Use templates to generate the appropriate repository artifact as /src/repositories/<modelName>.<dataSourceName>repository.ts

• Tests + Docs
  • Ensure --config mode is supported (Can pass in answers to all prompts using JSON).
• Blog

See Reporting Issues for more tips on writing good issues

[virkt25]

• Should allow selection of datasource from available datasources, model from available models and then the type of repository (CRUD, relation, etc).

[marioestradarosa]

Relates #1359 ? . This feature is complex but needed. It will have to generate the appropriate repository based upon a relationship (if it exists). Perhaps two PRS, a simple one (without relations) first?.

Also the controller generator will have to include this relationship!

[bajtos]

Instead of adding a new lb4 command, I am proposing to extend lb4 model to ask the user whether they want to create a repository to accompany the new model. I expect most models to be created together with a repository, let's make this most common scenario easy to follow.

Prompts to ask:

• Would you like to create a Repository class for your model? (Y/n)
• Select the datasource to use - offer only datasources using a data-access or key-value connector. Exclude service-connector backed datasources (REST, SOAP, etc.).

Depending on the datasource selected, we need to use a different base repository class. For example, mysql connector requires DefaultCrudRepository, while kv-redis connector requires KeyValueRepository (to be done - see #1539).

Relates #1359 ? . This feature is complex but needed. It will have to generate the appropriate repository based upon a relationship (if it exists). Perhaps two PRS, a simple one (without relations) first?.
Also the controller generator will have to include this relationship!

Let's work incrementally please.

As I see it, adding a generator for regular (CRUD, non-relational) repositories is a useful feature on its own. Once it done, we can perhaps leverage the implementation to generate relational repositories too.

As for the controller generator, our current approach is to have one controller for each relation. For example, when Customer has many orders, there will be three controllers: CustomerController, OrderController and CustomerOrderController. The reason for this split is to keep application code clean and avoid controllers with too many methods. Consider the case where a model has 3-5 relations. If we kept all relation endpoints in a single controller, the controller could easily end up with more than 20 methods. Let's keep this discussion in #1359 though.

[bajtos]

I am adding this story to GA scope (at least for consideration). The fact that lb4 tooling does not create any repository looks like an oversight to me.

[marioestradarosa]

From my user point of view I like both options. Albeit, The lb4 repository is more aligned with the lb4 controller and lb4 model in their current state in that they do only one task , however, I think including the repo inside the lb4 model is a good idea too.

As I see it, adding a generator for regular (CRUD, non-relational) repositories is a useful feature on its own. Once it done, we can perhaps leverage the implementation to generate relational repositories too.

I would like to contribute.

[bajtos]

Cross-posting #1587 (comment) by @virkt25

With LoopBack 4, one of the intentions is to move away from having a Model tied to a DataSource. We should be able to use model with multiple repositories if needed. As such I don't think lb4 model should be prompting for or trying to link a model to a repository but rather lb4 repository (when introduced) should be doing the linking between a model, and datasource to create an appropriate repository.

That said ... maybe this signifies that we eventually need a command to create a series of artifacts together since in most cases you'll want to create a model followed by a repository and controller for the model ... so a new command to streamline this process might be helpful but I don't know if it should be done via lb4 model ... maybe a new command of sorts but I can't think of a good name.

[marioestradarosa]

With LoopBack 4, one of the intentions is to move away from having a Model tied to a DataSource. We should be able to use model with multiple repositories if needed.

In that light, doesn't lb4 repository makes more sense ? and initially add the simple (CRUD, non-relational) but checking the type of the repository (ie: DefaultCrudRepository or KeyValueRepository).

[virkt25]

lb4 repository is a go, it’s behaviour is given in the acceptance criteria for this issue.

[marioestradarosa]

Someone working on this?. I would like to get my hands on it. With ALL your help of course 😄

[virkt25]

No ones picked it up thus far, be more than happy to help as needed :)

[marioestradarosa]

Thanks @virkt25 👍

[marioestradarosa]

@hacksparrow finally it is closed 👍

[hacksparrow]

Thanks @marioestradarosa, this is a very useful feature 🕺🏻

[dhmlau]

Thanks @marioestradarosa. Are you interested in creating a blog post for this feature?
We have CLI-related blog posts in the past. The goal is not to replace documentation but to give a bit more details on the use of the new command, the design decisions, etc. See this and this as examples.

If you're publishing in your own blog, please let us know too, we can help spreading the words!

[marioestradarosa]

hi @dhmlau ,

Sure I will send you the draft first 👍