Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Spike: Discover and define models at runtime #4235
This pull request implements a controller allowing clients to define models & expose their REST APIs at runtime, with no model/repository/controller source files required.
Cross-posting from #2484:
Please note that public database is no longer available. What I did instead:
Try it out
@bajtos Thank you for kicking off the topic.
I have been thinking about leveraging Kubernetes's
I'm NOT proposing to require Kubernetes. The intention is to use the similar design: CRD + Operator to extend LB4 for such resources.
We can have an extension point for Operators, each of them can handle a specific kind/version of CRDs.
- Accept a MySQL connection string (host+port+database+credentials) and a list of table names. - Connect to the specified MySQL database. - Discover model schemas from the given tables - Define LB4 models for the given tables - Expose these models via REST API - Return a list of URL paths of the newly added models Signed-off-by: Miroslav Bajtoš <firstname.lastname@example.org>
In a878d83, I have simplified the demo controller implementation using the recently released features strongloop/loopback-datasource-juggler#1807 and #4266. I have also reorganized the code to make it more clear how a model can stay private (not exposed via REST API).
I consider the demo app as done and proposing the following follow-up stories:
In my demo, I have a comment mentioning that it would be nice to have a LB4-native method for discovering model schemas, a method that return LB4
@strongloop/sq-lb-apex Please take a look and let me know if you have any comments or suggestions. I'd like to get at least one approval and then I'll move on to create the follow-up story/stories.
agnes512 left a comment
I only have one suggestion. If I were a user who uses this feature a lot, I'd like to know how I can modify/config the controller to match my requirements. It'd be good if we can make this part of documentation clear/detailed in the follow-up story.
jannyHou left a comment
(maybe another story)From UX's perspective...shall we create another endpoint that prints out the generated model def, like
Let's include #2740 in the follow-up stories for this spike.
I see your point. At the moment, you can find model properties in OpenAPI schema.
It is possible to build an endpoint you have described, or perhaps add the model definition to the response returned by
IMO, real world applications will never follow exactly our demo version, they will always combine these blocks in unique ways.