-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spike: Discover and define models at runtime #2484
Comments
Things to consider when do the spike:
|
Here is a code snippet/mock-up that I wrote while discussing this feature recently: const ds = new DataSource({/*config*/})
const discovered = await ds.connector.discover();
/*
{
name: 'Product',
properties: {
'name': {
type: 'string'
}
}
}
*/
// we need to transform modelDefinitionData slightly
for (prop of discovered.properties) {
if (Array.isArray(prop.type)) {
prop.type = {
type: 'array',
itemType: prop.type[0],
}
}
}
// Create model definition
const modelDef = new ModelDefinition(discovered);
// Create model class
// FIXME: create a named class using a template Function factory
const modelCtor = class extends Entity {};
modelCtor.modelName = discovered.name;
modelCtor.definition = modelDef; |
Spike in progress: #4235 |
Follow-up stories:
I am closing this spike as done. |
I don't think we will have time to look into this in the next 3-6 months. Let's wait until there is user demand. |
Certain applications don't use static JSON files to define their models, they create model definitions at runtime, often by running model discovery to obtain the model schema. Once the model is defined, the application usually exposed it via REST API.
This can be easily done in LB 3.x as follows:
Let's find out how to allow LB 4.x users to do the same.
The scope of this spike is to research solutions for discovering and defining models in such way, that the infrastructure implemented in #2036 can pick up new definitions and build REST APIs.
Acceptance criteria
A proof-of-concept implementation of the necessary run-time parts.
A demo application providing a new REST API endpoint that will:
/Products
,/CoffeeShops
)We can use the public database from loopback-getting-started) when testing this new endpoint manually.
List of GitHub issues - follow-up user stories covering the implementation. Documentation and blog post should be included in the implementation plan.
Decide what to do about relations. The story [EPIC] From relation definition to REST API with auto-generated repository/controller classes #2483 is tracking REST API for relations, but I don't think it's a good idea to include relations in the first iteration. Create a new GH issue to add support for discovery & definition of relations, this new issue can be a spike or the real implementation, depending on whether the implementation would be clear enough.
The text was updated successfully, but these errors were encountered: