search

tektoncd / dashboard

A dashboard for Tekton!
Apache License 2.0
873 stars 265 forks source link

Does Dashboard backend need to define its own REST API #50

Closed gorkem closed 5 years ago

gorkem commented 5 years ago

I was looking at the dashboard and I am wondering If there is a need for REST endpoints on the dashboard backend? Kubernetes already has an API server and tekton does everything as CRDs, wouldn't it be easier and more portable to develop the UI against kubernetes API server and tekton CRDs? What is the added value of the new REST endpoints?

a-roberts commented 5 years ago

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 commented 5 years ago

Also see https://github.com/tektoncd/dashboard/issues/35#issuecomment-482718784 (linking here so context isn't lost / conversation doesn't split)

mnuttall commented 5 years ago

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 commented 5 years ago

@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 commented 1 year ago

For tracking purposes: this was implemented beginning with https://github.com/tektoncd/dashboard/issues/267 and https://github.com/tektoncd/dashboard/issues/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: