Research and architect module management pattern, with eventual UI

[brylie]

Context

Over the past few months, we have reorganized our code into feature module folders. This basic work was done to prepare our project for a module management workflow, where each deployment administrator could choose which modules to enable.

Examples

The module management workflow/UI is inspired by the following projects (in alphabetical order):

• Atom packages
• Drupal modules
• NodeRed packages/flows
• WordPress plugins

All of the above solutions have a common theme: an end user/administrator can install, uninstall, and sometimes search for modules via a user interface.

Related discussions

There are a few related discussions among the Meteor/JavaScript community, where larger projects are planning to support custom/community modules:

• Rocket.Chat: New Plugin/Package managment system
• Wekan: RFC: The plugin system

[brylie]

Ping @apinf/design @apinf/developers

[brylie]

NodeRed package management UI

NodeRed has a user interface to search, install, and uninstall packages from NPM:

[brylie]

Atom package manager

Atom editor allows users to search, install, and uninstall packages via the user interface:

[philippeluickx]

+1 on the issue, definitely a good time to take this into consideration!

Should the same level of modularity also apply on the API owners level? E.g. one owner wants to activate the "discussion, code examples,..." modules while another API owner only wants "docs"? I am assuming this would be more of a design challenge than a code challenge though (I can open a new ticket?)

[brylie]

Should the same level of modularity also apply on the API owners level? E.g. one owner wants to activate the "discussion, code examples,..." modules while another API owner only wants "docs"?

That is a good idea, but not directly related to this task. E.g. we would design that as part of the API Settings tab, similar to Github repository settings for wiki, etc. Please do open a ticket to discuss the 'modular API profile page design'.

[jykae]

@brylie Node RED installer: https://github.com/node-red/node-red/blob/49f72881f481bed94f4ffbd12369136bc751ffb0/red/runtime/nodes/registry/installer.js

Looks like it's executing npm install --production <package>

[mauriciovieira]

Basically we will have to decide which are the points of extension on the main package. This will be the basic contract. The extension packages, or plugins, would have to use dependency injection to loose the relationships between different packages.

This would solve the problem of Feedback module affecting the API Profile templates. And if API Profile was not part of the apinf-core, apinf-feedback would depend on apinf-profile and extend it.

[brylie]

@mauriciovieira are there any tutorials or open source projects that we can use as a reference for dependency injection?

[mauriciovieira]

@brylie Dependency Injection is a technique to implement Inversion of Control. Splitting a monolithic code using this architecture will increase the complexity, but makes it easy to test everything isolate.

I just found meteor space. It can also serve as inspiration.

[mauriciovieira]

@brylie Take also a quick look on the FosWiki Extension Developer Guide. FosWiki has been there for more than 10 years. The basics of creating a plugin is written in a how to. Notice that all plugins share a common anatomy, including the same interface (the method params).

[frenchbread]

Hyper terminal is my favourite example of how packaging can be build. It uses NPM as a store for its plugins, at the same time all hyperterm related packages should contain hyperterm key word before the actual package name e.g. hyperterm-<plugin_name>. So basically you just edit JS config file, add some packages to the array, and once you save the file, these plugins are instantly fetched from NPM and deployed.

Worth checking out. (There is a short DEMO on the home page)

[brylie]

Sounds cool. Keep in mind we have worked in other areas, such as Branding, so that configuration can be done via UI. So, the high level goal is to have a module management UI. The package.json is a good goal though.

[mauriciovieira]

I think we should, as a first step, restructure the modules (and root filesystem directory) to have an idea of how difficult would it be to modularize.

I proposed the steps on https://github.com/apinf/platform/issues/1958

[ilarimikkonen]

after next