Spike: Booter for creating REST APIs from model files

[bajtos]

Part of From model definition to REST API with no custom repository/controller classes #2036

In #2736, we will implement a component providing CRUD REST Controller class that can be used to expose models via REST API.

In this spike, we will find out how to implement a booter that will read model configuration from JSON files, load controllers contributed by extensions, and connect those two parts together to expose REST APIs.

Prerequisites

(1)
An extension exporting a Controller, e.g. #2736. We can build a minimal version of such extension as part of this spike if needed.

(2)
Configuration format. Let's start with the convention described in #2036. If it turns out to be difficult to implement, then propose a better one.
For example, to create a Product model, attach it to a db datasources and expose a CRUD REST API, all that the developer needs is to add the following two files to their project (plus any npm packages that implement this functionality):

src/models/product.ts:

@model()
export class Product extends Entity {
  @property()
  name: string;
}

public-models/product.json:

{
  "model": "Product",
  "pattern": "Crud",
  "dataSource": "db",
}

Note: having config for multiple models in a single JSON file, as we do in LB 3.x, can quickly become a maintenance nightmare - see strongloop/loopback#1316. It will be better to have one config file per model.

An example file for a model using KeyValue pattern (not CRUD) - public-models/cache-entry.json:

{
  "model": "CacheEntry",
  "pattern": "KeyValue",
  "dataSource": "redis"
}

IMPORTANT: Keep in mind that TypeScript compiler does not copy arbitrary JSON files from src to dist. A possible solution is to keep model configuration files in /public-models directory (outside of /src).

Acceptance criteria

• A design proposal and PoC implementation showing how extensions can contribute controllers that can be picked by a Booter. Preferably leverage ExtensionPoint/Extension pattern as shown by our greeter example.

• A PoC implementation of a booter parsing model configuration files, gathering controllers contributed by extensions, and using this information to build REST APIs for models as configured. Implementation-wise, start with the approach outlined in From model definition to REST API with no custom repository/controller classes #2036 (comment).

• How to deal with Repositories? CrudRestController requires CrudRepository, CrudKeyValueController requires KeyValueRepository. We need a way (or a convention) allowing extension developers building different controller implementations to specify which repository should be used.

[b-admike]

Timebox for a week and a half. @bajtos question from estimation (Janny); Does the spike's scope have generation of relational APIs for the models if they're defined? Estimation is based on not including relational APIs.

[bajtos]

Generation of relational APIs is out of scope of #2036, see #2483. I updated the description of #2036 to make it more clear.

I think it makes sense to leave out generation of relational APIs out of scope of the spike too 👍

[bajtos]

WIP proposal: #3617

[bajtos]

Follow-up stories:

• Implement TestSandbox.writeTextFile Implement TestSandbox.writeTextFile #3731
• Improve defineCrudRestController to create a named controller class Improve defineCrudRestController to create a named controller class #3732
• Add defineCrudRepositoryClass - a helper to create a named repository class Add defineCrudRepositoryClass - a helper to create a named repository class #3733
• Model API booter & builder Model API booter & builder #3736
• Add CrudRestApiBuilder to @loopback/rest-crud Add CrudRestApiBuilder to @loopback/rest-crud #3737
• Example app showing CrudRestApiBuilder Example app showing CrudRestApiBuilder #3738

I am closing the spike as done.