Serverboards Core Architecture
Serverboards architecture is based on several layers:
Serverboards is divided into the Core and the Plugins. Internally each of the is divided into the backend code and frontend code.
There is always a strict communication between frontend and backend using JSON RPC. There is also support for downloding static assets at backend, necesary to download frontend code.
The core frontend communicates using Websockets with the code backend, which will perform the desired actions internally or delegate the commands to the plugins.
The Serverboards backend is a communication hub for the plugins. It contains some necessary information to allow this communication, and some extra information that requires to be in a central place. Mainly this means the plugin repository, with information about each plugin and waht they do, users and its permissions, and so on.
The backend always tries to delegate the real work to plugins, but some things are better centralised.
The frontend is a Single Page Application that communicates with the backend using Websockets and JSON RPC. It can download static assets from the backend, as the frontend iteself, and data from the plugins, mainly the frontend code of the plugins.
The frontend itself is downloaded fully on the users browser, and have zero or very little business logic in it.
The frontend itself is just a middle layer between the user and the backend; it does not manage anything about permissions. Everything that the frontend does can be done manually using the CLI.
When the frontend is asked to run some plugin it does ask the backend to run it, keeps a pointer to the running code by the backend, and sends commands to the plugin via the backend.
There is a simple Command Line Interface that allows easy executing of RPC commands. It is mostly used for testing and developing, and allows, for example, to test plugins behaving as a human managed Serverboards Core.
Plugins are composed of three parts: The manifest, backend code and frontend code.
The only required part is the manifest; there may be plugins with no frontend nor backend (pure definition plugins), only backend (sensors, actuators), only frontend (only visualization) or both (full plugins).
The manifest defines what the plugin has, and there are many kinds of components.
A plugin may have many components. Check the list of components here.
The components may have an active part (called plugin backend), that will be an executable program that communicates via stdin/stdout using JSON RPC. It can perform any active action required from the plugin, from gather some dynamic data for documentation pourposes, watching for status changes and notifing them, or performing actions.
The plugins may have also some frontend data, that will be some HTML and/or JS. The new snippets will be shown where appropiate, as in widgets in the dashboards, or as full screens. It is recommended that the JS code uses React (from Serverboards.React), but its in no way required.
There are Python bindings for easy creation of Python based plugins. Other languages support is coming.
If a plugin has both a frontend and backend part, the frontend will communicate with the backend via the Core, using some identifier for the plugin session. Check the plugin developer documentation for more details.
The plugins are free to do everything their own style, but using the provided JSON RPC is the recomended and easier way to ensure communications.