Question about extending the repository

[ftomassetti]

In addition to the core features of the repository (storing/retrieving partitions) I would need other features. Some would be basic, like having the possibilities to know how many nodes of a given concept exists in the repository. Some could be more advanced, like identifying instances of a certain pattern in the model repository.

I think these extra features could be implemented: a. As part of this project, in the core module b. As part of this project, creating separete modules that someone could install or not c. As part of a separate project, implementing a sort of plugin mechanism, so that third parties (including me) could extend the features of the model repository d. As separate applications that just share the DB with the model repository

Which option do you think would make the most sense for this project?

[dslmeinte]

Being able to compute some statistics / meta-level introspection about the models stored in a repository is very useful. At the same time, we have to take care that anything we offer complies with an active authorization system. That more or less rules out option D because that basically shares everything. Option C would need to be designed carefully to not have the same problem. I think I like option B the best, since it's relatively simple to develop such modules in sync with the core repo module. Also, any separate module could serve as an example of how to implement your own module for your specific needs.

[joswarmer]

I agree that option B is the most practical one for development, while still enabling users to only install the modules they want. That make third party modules harder to support, but when there is demand for that we can always invent some plugin mechanism later. There is already an "additional" api in the current project, it will be good to flesh that out to a separate package (in the same repo).

[ftomassetti]

Are the npm workspaces the right solution for implementing option B? I am asking as I do not have much experience with web development. I am happy to look into it, but if you already know it is a bad choice and there are better alternatives I can look into those

[ftomassetti]

I started experimenting with npm workspaces in this branch: https://github.com/ftomassetti/lionweb-repository/tree/workspacesetup I thought it could be useful to take a look at what it would look like.

There is a separate module called db admin, which contains the init route. The module is registered in the server by calling a function it exposes:

registerDBAdmin(app, dbConnection)

This could be potentially controlled by a flag.

If this can roughly makes sense I can open a PR to look into the details.

[dslmeinte]

As I understand them, NPM workspaces are a way to support development of multiple, mutually interdependent NPM packages. Factoring a code base into multiple package is obviously a Good Thing™ to do for something like option B, but it also doesn't give anything more than that.

[joswarmer]

As I understand them, NPM workspaces are a way to support development of multiple, mutually interdependent NPM packages. Factoring a code base into multiple package is obviously a Good Thing™ to do for something like option B, but it also doesn't give anything more than that.

I am using them now in my branch. They do bring:

• a nice option to run an nmp script in multiple packages
• ensure that the references to the packages in the same git-repo are setup to use symlinks

[ftomassetti]

I think we got a solution for this, so this issue can be closed