Dashboard panel pluggability

[rashidkpc]

Currently only two types of panels can be placed on a dashboard: visualizations and searches. We need a way for plugins and apps to register new types. @simianhacker can you fill in your thoughts around filtering here?

[simianhacker]

I'm assuming these panels will make their own separate requests and we are giving up on the notion of one request to the backend and then distributing the results. From a filtering perspective, I would say that there needs to be a way for a panel to receive the list of filters being applied and then leave it up to the panel to honor them or not. Each panel might have a completely different backend or they might not even be relevant to the filter.

[spalger]

These panels could choose to use a different fetching mechanism, the dashboard doesn't actually implement any of the request logic. The request logic is all handled by the courier and these panels, regardless of where they come from, can still use the courier.

[simianhacker]

@spalger Courier is only useful if they are making a request to ES through the proxy. What about plugins that make requests to HTTP API endpoints on the Kibana server?

[spalger]

Then they can't participate in filtering, but if #4921 is completed (which I closed for some reason) then they could participate in filtering and be fetched at the appropriate time

[stacey-gammon]

To give an update on our thoughts on this, we would very much like to see dashboard pluggability but I think the implementation of it is dependent on the outcome of #9675.

The plugin system will be tackled as part of that re-architecture. Rather than implement a second plugin system separately for dashboards, I think the Sharing team should be involved in that discussion and make sure that the new plugin system can also support custom dashboard panels as plugins.

[stacey-gammon]

Closing in favor of #19875

The embeddable API work is in the very early stages, but it is underway and being discussed and actively developed.