...
Specific to the backend, this is intended as both storage for the dashboard, and also to include a "frontend registry. The idea here is that mod-service-interaction ". This registry will be able to act as a point of interaction between the frontend and backend, able to return information about differing frontend apps, such as how their url filtering is built, allowing other apps then to make a call to mod-service-interaction and use that information to create pre-filtered links on the fly. Similarly we can use this in the dashboard to offer solutions such as custom display components from apps within tables.
...
The dashboard is not tied exclusively to ERM in any way. This way any build can potentially make use of this service/app, and we can attempt to have cohesion and similarity of design no matter which users are using this app, and which module's widgets they're attempting to add to their dashboard.
As part of this we aim to build The overall aim is for a system where new definitions can be added automatically by other modules, requiring absolutely zero work from the ERM team. Simply send your New Definitions for a Type and see your widgets can be POSTed on the fly, and they will appear as options in your systemconfiguration options for users without any development work besides the JSON file.
We hope the backend module mod-service-interaction can become a storage point for certain frontend information, allowing this kind of inter-app interaction as smoothly as possible for both the dashboard, and also any other apps which need this information.
...