Because AdminBro can be run under any Node.JS framework and feed with multiple kinds of data, it has to have a modular structure.
Furthermore, AdminBro Features are extending the basic feature set of the core package.
Let's see how it looks
This is the default flow from your data, to an actual rendering of the UI.
graph LR
O(ORM/ODM) --> C
A[[AdminBro]] --> |rendering| B[Plugins]
C[Adapters] --> |data fetching| A
B --> D(HTTP framework)
graph TB
O(ORM/ODM) --> C
A[[AdminBro]] --> |rendering| B[Plugins]
C[Adapters] --> |data fetching| A
B --> D(HTTP framework)
What happens here:
- You connect with the database, or any other data source, with your favorite ORM/ODM client
- Then, AdminBro Adapter takes control and translates all the calls like
save,updatefrom the ORM to AdminBro. - The core (admin-bro) package is an actual AdminBro - it handles all the backend and frontend logic, except it does not know anything about how to render itself by the HTTP framework.
- but Plugins know, they take all the routes definitions exported by AdminBro and simply render them within a given HTTP framework like express, koa, Hapi...
Modules types
To summarize, there are 3 kinds of modules which can be plugged into the AdminBro:
1. Adapters
Translates ORM/ODM interface to be compatible with the one used inside the AdminBro core
2. Plugins
Translates all the Routes provider by AdminBro so they can be rendered under the given HTTP framework
3. Features
Are external packages, which can be added to AdminBro config to extend its functionality.
Installation
To run AdminBro you have to use at least.
admin-brocore package- one of the plugins along with your HTTP framework (or write your own)
- one or more database Adapters along with the ORM they support (or write your own)