search

evoluteur / evolutility-server-node

Model-driven REST APIs for CRUD and more, written in Javascript, using Node.js, Express, and PostgreSQL.
GNU Affero General Public License v3.0
111 stars 33 forks source link

Some other possible features? (not an issue) #15

Closed lukzard closed 5 years ago

lukzard commented 5 years ago

hi Oliver,

I really like to Evolutility, congratulations for getting it so far!

Below are few question or suggestion about possible features, of both back-end and front-end solutions:

  1. Is there a way to configure the back-end across all databases withing a PG cluster, and all schemas?
  2. Is there a way to configure the solution to dynamically read all databases / schemas / tables and views within a PG cluster? Currently I notice that configuration is specific for a database, a schema, and even tables (through module specification). There would be an interesting scenarios in which all such resources would be exposed, directly, without need of configuring additional parameters in the solution.
  3. Any plans to develop a front-end based on ExtJS? They now launched an free Community Edition version, and I always appreciated Sencha ExtJS's UI components, especially their grids.
  4. Is there a plan to merge configurations for back-end and front-end parametrization? I.e. currently, at least under the modern framework of Evolutility, one needs to define the modules in the back-end solution, then configure the UI modules in the front-end one.

Thank you,

evoluteur commented 5 years ago

Hi Lucian,

Thanks. I'm happy you like my Evolutility.

1- Currently Evolutility works with a single schema from a single database (the DB and schema are specified in the config.js file for all applications). I agree, looking at multiple schemas and databases would be useful. It is possible to modify the code of Evolutility to specify the DB options for each model rather than globally.

2- I'm working on adding the ability to generate models directly from the database. It is possible to generate UI w/ only DB metadata but it needs some extra UI metadata to become user-friendly.

3- I had Blueprint in mind.

4- Yes, I plan to store the models in the database (like for the older Evolutility ASP.net). It will be the single source of truth for models on both back-end and front-end. It will be possible to edit the models with Evolutility and query it over REST.

david-pfx commented 5 years ago

1- Currently Evolutility works with a single schema from a single database (the DB and schema are specified in the config.js file for all applications). I agree, looking at multiple schemas and databases would be useful. It is possible to modify the code of Evolutility to specify the DB options for each model rather than globally.

You need a “table of tables”. When you have that, it’s easy enough to make connection details an attribute of the table.

2- I'm working on adding the ability to generate models directly from the database. It is possible to generate UI w/ only DB metadata but it needs some extra UI metadata to become user-friendly.

Right on. DB metadata and UI/view metadata is the way to go.

3- I had Blueprint https://blueprintjs.com/docs/ in mind.

Good choice.

4- Yes, I plan to store the models in the database (like for the older Evolutility ASP.net). It will be the single source of truth for models on both back-end and front-end. It will be possible to edit the models with Evolutility and query it over REST.

That’s what I’m on about. Happy to help.

lukzard commented 5 years ago

Thx both for the reply. Makes sense.

On topic 3, Sencha ExtJs is definitely a good alternative. Do explore the Data Grids available:

evoluteur commented 5 years ago

On topic 3. It is nice. I will check it out. On topic 4. I still plan to store models in the DB but until then you may find this useful. https://github.com/evoluteur/evolutility-models