Improve project structure

[mauriciovieira]

The current project filesystem has about 30 directories and does not seem to follow any guideline. This makes the code difficult to understand and evolve. The meteor website has some guidelines to structure a meteor app using ES 2015 modules, but there might be other good ways as well.

What I envision for tidying up the filesystem is:

• list all directories that can be structured using ES 2015
• open an issue for refactor each of these modules
• update the documentation accordingly and incrementally

[mauriciovieira]

@brylie @bajiat my first big suggestion.

[brylie]

For what it's worth, we did put some thought into the current structure, and documented it in our contributor guidelines. This is not to say our structure will never change, but rather we intentionally grouped code into feature modules at the root level of the project.

When viewing the root level of the project, you can see our feature modules such as dashboard, catalog, api, etc. We also started using ES2015 import/exports, but have not transitioned to a fully modular structure. In the long run, we have envisioned that each of these modules, outside of core, might end up as its own NPM package.

[mauriciovieira]

I understand, but still it seems to much for the root directory. What about moving all modules into a modules subdirectory, leaving public, docker, modules (and maybe a few other directories) in the root?

[brylie]

Sure, we might even convert the modules to git submodules.

A 'grand vision' would be to architect Apinf in a similar manner to Drupal, where each feature is a module and can be managed from a 'Modules' administrative view.

The NodeRed platform has a similar module management UI, including fetching and installing modules from NPM.:

[ilarimikkonen]

wow