We help IT Professionals succeed at work.

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
Comment
Watch Question

Most Valuable Expert 2017
Distinguished Expert 2019

Commented:
What are your concerns?

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.

Author

Commented:
@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!
Most Valuable Expert 2017
Distinguished Expert 2019
Commented:
First up PHP is server side - so if you are talking dynamic creation of widgets then you are probably looking at a JavaScript implementation if you don't want your page to go bouncing back to the server every time you create a widget.

The basic idea would be to have a widget Factory module (JavaScript) that accepts the type of widget (plus any supplementary data required to create it) and this module uses AJAX to send this information to a server based API (which can be written in pretty much anything).

The API accepts the request for a new widget and (potentially - just one design pattern) looks for an instantiates an object (derived from a general widget object) that then does one of two things
a) Either it renders out the widget HTML and sends this back
b) It sends back meta data (as JSON) which is then used by a module on the client side (Javascript) to render the widget.

I would probably go with a combination of the two - pass the rendered widget back with meta data so that the client side code knows how to interact with the widget.

An API (in this context) is just an HTTP endpoint that accepts (GET/ POST / PUT / DELETE) submissions along with data. How you implement that on the receiving end can be done in a myriad of ways and there is no right or wrong way - there is a way that make sense for your application design.

For instance - I have a PHP based API framework I developed that runs off micro services - small PHP classes that are bound by a route (in the URL) and internally can do further routing. Each Verb (GET / PUT / POST ...) + action is uniquely bound to a method in the service class (which in turn is derived from the base Service class).

Each time I need a new endpoint I either add to an existing service (if it makes sense to put it there - group like with like) or I create a new service.

I use sp_autoload on another class folder where I place helper classes that are used by the services to do what they need to do.

The framework handles logon and security and who may or may not access an endpoint.

That is just my particular implementation. As I said you build the API that works for you.

Author

Commented:
@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!
Most Valuable Expert 2017
Distinguished Expert 2019

Commented:
You are welcome.