[Discussion] Dynamic data model support

[mrjmd]

This was a topic of a lot of discussion with the Angular team. The basic premise is that building an app to consume and display known and established data models (a recipe site) is all well and good, but the ideal scenario is a (service / library / application / whatever) that can respond to changing data models and whole new data models dynamically.

On the Drupal side, this means that for each data model we would want a schema exposed, which should already be being generated by the OpenAPI integration, we'd just need those to be directly addressable / linked to from the /api endpoint perhaps.

On the front end side, there were two possible approaches to this that we discussed, which can be broken into the runtime approach vs the build time approach.

Runtime approach: A (very) rough sketch of this already exists, we hacked it together yesterday here: StephenFluin@e2af530

This approach ~ works, but has drawbacks in terms of potential scaling issues, inability to customize templates per data model, etc.

Build time or CLI approach: This idea would be to query for our schemas as a CLI command or build step, and then build out d.ts, component, and template files based on the currently active schemas. This would obviously force a new build each time a field/bundle was added to the site, but would also grant far more customization ability to the user, type checking of templates, etc. Most likely this is the better long term approach but we might want to diagram out a design doc to make sure the idea is fully fleshed out before attempting an implementation.

[joaogarin]

This sounds like a really great idea.. I feel like the second option is more appealing.as the first one probably will hit the wall on some users. I dont feel like having to build the app once you design a new model or change existing ones. But yeah designing this is probably a good idea.

In the end people need to build an app, they have requirements from their bosses in terms of not only design but features etc so contenta needs to be able to provide that, so probably having this as a "kick off" point for development on a new feature is more suitable.

I have two questions though maybe regarding it..and the more generalized "who is this for"..in terms of not only the frontends but also contenta itself.

1 ) Does this change in some way who we are targeting with contenta? I mean the idea from what I get of the out-of-the-box initiative plays really well with this idea. It doesnt really get more out-of-the-box then you are describing, but does it require a really well rounded developer to use it? And if so, does that go against contanta's use case. Lets maybe discuss it in the channel.

2 ) Regarding configuration, how much does this go in terms of configuration for the user. Contenta as I read from the channel is a configuration free solution. that sounds like the golden rule from what I read so again maybe something to check on the channel

In general I think this is a great idea, if we can pull it off this would be really an amazing solution. I think all frontends should probably go in the same direction so there might be interest in other frontends to follow this approach and we could all work in this design document?

[e0ipso]

Contenta is for developers that know little about Drupal and want to experiment with a decoupled CMS. The front end demos are for Drupal (or not) developers that want to figure out best practices in the consumer side without crazy complexity.

That should not change anything fundamental. Just use your knowledge and best practices, and build it as if it was for client work. That's how people will probably want to use it.

[mrjmd]

A small update here. Yesterday I got a demo of the Colmena project, an open source API-first CMS being built in Angular (https://github.com/colmena/colmena). Of particular interest to us is the way it is integrated with the LoopBack SDK Builder, which explores API schemas (LoopBack specific, obviously) and scaffolds out Angular applications based on them.

From their Github (https://github.com/mean-expert-official/loopback-sdk-builder): "The LoopBack SDK Builder will explore your LoopBack Application and will automatically build everything you need to start writing your Angular 2 Applications right away. From Interfaces and Models to API Services and Real-time communications."

Probably some digging through the code is in order to see just how much of that we could potentially re-use, or where the points of divergence are.

[mrjmd]

Here's another example approach to this kind of idea. The repo goes with this presentation slide deck, given at the June SF Angular Meetup.