Does Dashboard backend need to define its own REST API about dashboard

[a-roberts]

Good point, I haven't coded against the Kubernetes UI server before but I think we've done it this way so we have power over matters such as the format of certain responses (making it noddy for our frontend code to parse) and control over return codes. We also get to do any additional error handling that we may like to do.

It also lets us do things a little more advanced (I like our TaskRun logs API and its response for example), but you're right, we're basically an indirection layer between the frontend and the Kube API server right now and perhaps we needn't be in all cases.

It's not much code for the get methods mind you, and it also does give us some power because we always know what our responses are going to look like (so in terms of returning lists for example, or arrays).

[AlanGreene]

Also see #35 (comment) (linking here so context isn't lost / conversation doesn't split)

[mnuttall]

Hi @gorkem the best reason I can give for the REST API is that we want the dashboard to work against clusters that do not expose the kubernetes API, or keep it very locked down. We don't currently have a plan to run a single dashoard against multiple clusters, and expect to use in-cluster securtity (service accounts and role bindings) to restrict what the dashboard is able to do on that cluster. Thank you for asking - it's a very fair question. We could start looking at edging the REST API out in some circumstances but it would help to have a clear need to do so. I hope you won't mind if I close this issue.

[gorkem]

@mnuttall I think exposing the kube api server and defining REST APIs are different concerns. For instance the backend for OpenShift's dashboard proxies the API calls to API server without implementing new REST APIs, therefore uses an internal end point to eliminate the need for exposing kubernetes API server.

[AlanGreene]

For tracking purposes: this was implemented beginning with #267 and #290, completed over a number of subsequent issues / PRs. This started in ~June 2019 and the last remaining vestiges of the legacy websocket API were removed ~August 2021.

The Dashboard now maintains a single custom API for retrieving install metadata, but otherwise proxies API requests to the Kubernetes API server.

This allowed for deletion of a large amount of code, uncoupled the Dashboard from Triggers / Pipelines releases (no longer uses their golang SDKs), and had a number of other benefits including:

• improved performance
• improved websocket support
• log streaming support
• ability to run the Dashboard as a local client without a deployment in the cluster
• etc.