Declarative Support

[raymondfeng]

LoopBack manages a set of artifacts, such as models, relations, datasources, connectors, ACLs, controllers, repositories, actions, sequences, components, utility functions, and openapi specs. In addition to the programatic approach to describe these artifacts by code (apis and decorators), we would like to add declarative support so that they can be declared in JSON/YAML files.

There are multiple tasks involved:

1. Define a LB Next definition language (DSL) in JSON/YAML format and corresponding templates. See New DSL and Template Support #120. We need to come up a list of artifacts and metadata schema for each of them.

2. Define the project layout to organize LB next artifacts

3. Leverage the IoC Context to manage metadata/instances of such artifacts following the extension point/extension pattern.

4. Define the lifecycle and serialization/deserialization requirements for each type of artifact.

5. Add @loopback/boot to discover/load/resolve/activate the artifacts. See [SPIKE] Create @loopback/boot to support declarative JSON/YAML files #441. The boot process can be tailored for both tooling and runtime.

6. Build tools (CLI/UI) to scaffold LB next applications and render/manipulate LB next artifacts.

[dhmlau]

To be discussed with @raymondfeng and possibly other stakeholders:

High level requirements

When creating LB4 app, LoopBack users can:

• define the artifact declaratively (besides programmatically)
• reuse LB3 artifact json/yaml files with no or minimal changes
  • If the artifact schema is different from that in LB3, need to document it

List of artifacts that have declarative support in LB3

• model
• datasource
• controller
• repository
• anything else?

What we need to do

• Define the artifact schema
• create corresponding booters
• ... plus the list from the original description

List of artifacts that will have declarative support

• model
• datasource
• controller (WIP) [Boot] Automatic configuration of controllers in Application #780
• repository (WIP) [Boot] Automatic configuration of repositories in Application  #781
• anything else?

[dhmlau]

just realized this story is sort of groomed in #441. please ignore my comment above.

[slathrop]

I'm a very happy dev on LB3 right now with a sizable investment in the declarative, model-driven approach.

So I'd just like to say:

• Please, please invest in keeping the LB3 simplicity of all out-of-the-box API endpoints "just working" based solely on the JSON models (or whatever data/metadata format)
• I definitely "get" the idea of controllers and repositories in LB4, but please don't require that sort of boilerplate code and ceremony simply to get basic APIs up-and-running
  • To me, the "hooks" approach in LB3, where you don't need to write any code "until you really need to" must still be possible in LB4
• When I saw the onboarding, "Getting Started With LB4" TODO scenario with the TypeScript classes for controllers and repositories my heart just sank!
• The onboarding experience in LB3 is absolutely phenomenal... the no-code support in LB3 for quickly standing-up an API server is awesome
• I know that the full LB3 feature parity on LB4 is still a WIP, but please, keep that awesome model-driven, no-code support from LB3 when you finish the feature parity work!

Thanks! And keep up the awesome work on LB!

[raymondfeng]

Great feedback! We’ll definitely want to keep the simiplicity for common patterns. The idea of LB4 is to create the primitive building blocks first and add composite ones on top of them based on our users’ need. Ideas of such high order commands are welcome!

[dhmlau]

@slathrop, thanks for your feedback. To add on @raymondfeng's comment, I'm in the process of cleaning up the steps in the TODO tutorial to demonstrate the "no-code support" to start up something simple. Feel free to comment on my PR: #1846.

[bajtos]

Related discussions: #695 and #1889

[elv1s]

I want to second what @slathrop wrote.

Loopback is an awesome framework! I think frameworks like loopback, and others like expressjs, owe their popularity in large part to their simplicity.

[beriberikix]

For "6. Build tools (CLI/UI) to scaffold LB next applications and render/manipulate LB next artifacts," have you see https://github.com/mermade/openapi-gui? It has been pretty handy when I was trying to learn OAS3 and seems extendable.

[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.