Spike: From datasource config to Service REST API with no proxy/controller classes

[bajtos]

In LoopBack 3, it was very easy to get a fully-featured CRUD REST API with very little code: a datasource configuration for a 3rd party webservice (REST, SOAP, etc.) and an empty model attached to that datasource.

Let's provide the same simplicity to LB4 users too and build on top of the mechanism implemented for models in #2036.

• User creates a datasource using a web-service connector like REST or SOAP. (No change here.)
• User declaratively defines how to expose this service via REST API. At minimum, we need a model name or URL path where to mount the service API.
• @loopback/boot processes this configuration and registers appropriate service proxies & controllers with the app.

Note: having config for multiple services in a single JSON file can quickly become a maintenance nightmare, see strongloop/loopback#1316. It will be better to have one config file per service, e.g. public-services/geocoder.json.

See also

• From model definition to REST API with no repository/controller classes #2036

• 1889:

  provide a set of extensions in order to keep the simplicity of LB3, without the needed to creat e repository, controller for default CRUD actions (only if we need custom actions) ?

• 565 Declarative Support

Acceptance criteria

A pull request with a proof-of-concept implementation showing how to achieve the goals listed above.

• [ ] A new extension (npm package living in loopback-next monorepo) mapping strong-remoting metadata to OpenAPI spec. Connectors are using strong-remoting metadata to describe the shape of the remote API. In LoopBack4, we are using OpenAPI spec instead, and thus need a bridge that will allow LB4 to understand metadata provided by connectors.

  Implementation-wise, the PoC can leverage the code from #2274, see lb3-openapi.ts. That code is based on loopback-swagger package from LB3.

  In this spike, we should figure out how to package this code into a standalone extension, how to migrate the test suite from loopback-swagger and also what we need to implement on top of the current PoC version to make it good enough for SOAP/REST/Swagger connectors.

  IMPORTANT: In #2274, we are using strong-remoting's SharedClass and SharedMethod APIs to process remoting metadata. IIRC, connectors don't use those APIs and put remoting metadata directly into properties of a remote method (this is an older flavor from LB 1.x). If that's the case, then the new extension should process the remoting metadata directly, so that we don't have to re-create SharedClass/SharedMethod classes in LB4 again.

• [ ] A component to build a controller class or a set of route handler for given remoted class (data-access-object constructor as provided by a connector).

  In this spike, start by reusing and repackaging the existing code in #2274, see lb3-model-controller.ts and rest-adapter.ts.

  Again, try to find a solution that does not need SharedClass and SharedMethod classes.

• [ ] A new extension providing a booter that parses public-services JSON files and exposes the services as configured.

• [ ] An example application using REST or SOAP connector and demonstrating the PoC solution end-to-end.

• [ ] A list of follow-up stories for the actual implementation. In addition to runtime parts, these stories should also cover:

  • A new CLI command that will ask the user for an existing datasource, model name or URL path, and then generate the corresponding public-services entry.

  • Documentation

  • Blog post

[jannyHou]

time box it to 8 days

[stale[bot]]

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[bot]]

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.