asked on
Does it make sense for a dashboard to call it's own widget APIs?
Maybe a stupid question - but I'm not a front-end guy, and my new front-end developer won't start for a couple of months.
I'm working on a solution for a microservices based data tool. Simply, this will be an interactive dashboard where users can add selected interactive widgets, from which they can select data to have a chart drawn. Sometimes the data needs to be sent directly from one widget to another widget - and sometimes an external microservice will need to do processing on the data before a new chart is drawn.
Based on this, I came up with the following schema (see image). I believe it makes sense to have the dashboard's API accept data from the external microservice, and then generate the interactive graph widget.
What I'm unsure of is; does it make sense to have the dashboard call it's own API for one widget to create another widget.
When I coded with Node.js, we did this all the time - but only with data and only in the backend (where one Node.js service just called another Node.js service - and they would talk back and forth via their APIs.)
Does this continue to make sense for a graphing frontend?
![selfcallingapispng.png]()
I'm working on a solution for a microservices based data tool. Simply, this will be an interactive dashboard where users can add selected interactive widgets, from which they can select data to have a chart drawn. Sometimes the data needs to be sent directly from one widget to another widget - and sometimes an external microservice will need to do processing on the data before a new chart is drawn.
Based on this, I came up with the following schema (see image). I believe it makes sense to have the dashboard's API accept data from the external microservice, and then generate the interactive graph widget.
What I'm unsure of is; does it make sense to have the dashboard call it's own API for one widget to create another widget.
When I coded with Node.js, we did this all the time - but only with data and only in the backend (where one Node.js service just called another Node.js service - and they would talk back and forth via their APIs.)
Does this continue to make sense for a graphing frontend?
* Software ArchitectureJavaScript
Last Comment
Julian Hansen
ASKER
@Julian Hansen
Thanks for the input. Honestly, I'm not sure if there IS a concern. I'm just not strong enough in front-end to know if this diagram makes sense (from a coding perspective.)
Maybe I should change the question a bit. I have written widgets in PhP, where the widget can be added interactively to the main PhP web page. I want to do something similar, where there is a main functional window (a dashboard) to which Widgets are added interactively. I'd like the widgets to be added by three methods.
1. The user clicks a dashboard button or drags a widget to the dashboard (I.e. dashboard code instantiating the widget.)
2. An interqactive, independently coded dashboard widget itself directly instantiating another dashboard widget (based on the widget's data requiring the new widget, or the user clicking a button within the widget to instantiate a different widget.)
3. An outside microservice (completely independent code, running as a service, talked to through its API) instantiating a widget for the user's existing dashboard based on code it has run. I.e. Widget 1 and Widget 2 send data to the microservice's API, the microservice crunches the data, and then the microservice instantiates a third widget within the dashboard.
Q1: I assumed I could give the dashboard its own API, that would accept "data" and "type of widget" as input, and the dashboard would then instantiate the widget. Is this a correct design pattern, or is there a better one?
Q2: If the above IS a valid design pattern, then does it make sense to have the internal widgets simply call the dashboards API to instantiate a new widget, or is there a more appropriate way to do it?
The dashboard and widgets will (likely) be coded in some form of Javascript (Node.js and/or React/Vue/Jquery) and should be an independent as possible, so widgets can be added easily in later developments.
The microsevices will all be independent services, likely running in Docker, with an API for passing data back and forth.
Thanks again!
Thanks for the input. Honestly, I'm not sure if there IS a concern. I'm just not strong enough in front-end to know if this diagram makes sense (from a coding perspective.)
Maybe I should change the question a bit. I have written widgets in PhP, where the widget can be added interactively to the main PhP web page. I want to do something similar, where there is a main functional window (a dashboard) to which Widgets are added interactively. I'd like the widgets to be added by three methods.
1. The user clicks a dashboard button or drags a widget to the dashboard (I.e. dashboard code instantiating the widget.)
2. An interqactive, independently coded dashboard widget itself directly instantiating another dashboard widget (based on the widget's data requiring the new widget, or the user clicking a button within the widget to instantiate a different widget.)
3. An outside microservice (completely independent code, running as a service, talked to through its API) instantiating a widget for the user's existing dashboard based on code it has run. I.e. Widget 1 and Widget 2 send data to the microservice's API, the microservice crunches the data, and then the microservice instantiates a third widget within the dashboard.
Q1: I assumed I could give the dashboard its own API, that would accept "data" and "type of widget" as input, and the dashboard would then instantiate the widget. Is this a correct design pattern, or is there a better one?
Q2: If the above IS a valid design pattern, then does it make sense to have the internal widgets simply call the dashboards API to instantiate a new widget, or is there a more appropriate way to do it?
The dashboard and widgets will (likely) be coded in some form of Javascript (Node.js and/or React/Vue/Jquery) and should be an independent as possible, so widgets can be added easily in later developments.
The microsevices will all be independent services, likely running in Docker, with an API for passing data back and forth.
Thanks again!
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
@Julian Hansen
Nice, and thank you for the detailed description. That was very helpful - and let's me know I'm (at least) on the right track :D
Best!
Nice, and thank you for the detailed description. That was very helpful - and let's me know I'm (at least) on the right track :D
Best!
You are welcome.
I am not following what the issue is. If you have a front end that needs server services then an API is required. This may comprise a single source or multiple.
Maybe outline what it is you think may be an issue.
From the outset I don't see any issues but I am not certain I understand the problem you are having.