AdminX anatomy

The purpose of this document is to outline and describe what adminx will be and how it will be structured.

Philosophy

The philosophy for AdminX helps us make decisions when designing the platform. With every approach we consider, we will keep in mind these simple guidelines.

• The system is opinionated. We try to fit the needs of the 90%, and adjust only when needed.
• Plugins are the main ingredient, the core is relatively small.
• Stability.
• Document everything. Every change, every PR will come with documentation for the thing.

Plugins

The system is a core that can be extended upon. It provides a defined API to register, and load plugins. Even core components will be built as plugins, to enable swapping them out at any point. Examples of these plugins are:

• User management
• Preferences / settings
• Authentication

Plugins depend on other plugins when needed. For instance, the settings plugin provides an API for other plugins to register their settings with it. A blog plugin can depend on a user plugin to enable authors, etcetera.

Plugin plugin

There will be a plugin plugin. Yes, a plugin called plugin. This plugin will tie into the backend, which will be sails.js. This plugin will allow managing plugins server side. This is needed for components such as blogs, which require models to be defined. We'll use sails hooks to provide these functionalities.

Mid-rant-rant

The admin can have a "repository browser" to make it possible to install plugins from a UI. We could use npm and jspm to install the deps as needed. However, we still have to figure out how to exactly do this. If we really use npm and jspm, we might cause conflicts. Or won't be able to persist the dependencies to VC. We could store the plugins in the database, and use npm to create our own dependency system (so we don't conflict with other dependencies).

Note: Different backends are supported on adapter level, in aurelia-api. Sails is the default, but adapters for other backends (such as strongloop) can be built, too. As long as they follow the preset adapter API, all plugins should still work. Otherwise the plugin must define specific adapters as dependency.

Templates

Figure out a way to unify the user interface in some way. Perhaps everything is a component? Use less /scss with variables to force same colors? Bootstrap did a nice job with this.