[Dashboard v1] Rewrite the backend for Central-Dashboard to Node.JS

[avdaredevil]

Child issue of #2361

Goals

• Rewrite the dashboard backend in Node.JS
  • Wire in Express
  • Wire in Jade / Pug
• Add a readme
• Set up authentication / required setup for Kubernetes deployment
• Set up Babel / Webpack for Transpilation (possibly worked on by @prodonjs)
• Link Data Endpoints / serve over REST
  • Build Version data
  • Namespaces
  • Activities tab data

[k8s-ci-robot]

@avdaredevil: GitHub didn't allow me to assign the following users: prodonjs.

Note that only kubeflow members and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign avdaredevil
/assign prodonjs

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[avdaredevil]

/priority p1
/area front-end

[prodonjs]

I've been able to spend a little time in the past two days getting back into the swing of FE work as I ramp down on my current team. A few thoughts/questions come to mind before I hopefully take a stab at some of the items here.

• NodeJS server
  • In a production configuration, would we have any need for a template engine? My thoughts would be that we would have our build process package the front-end assets and serve them all as static files from Express
  • That would make surfacing an API into the K8s layer the primary purpose of the server and make it easy to keep PRs independent from one another.
• Polymer 3
  • It seems that moving from Polymer 2 to Polymer 3 is fairly trivial, particularly since the footprint isn't massive yet and there's virtually no major backwards-incompatible changes that we would need to make.
  • This seems like a reasonable step to take before getting too deep into the development.
  • With respect to Webpack, it seems like the Polymer CLI already has pretty good support for productionizing a build.
    • There are other tutorials where people used webpack. The biggest advantage I could see is that we could separate templates and styles into separate files and use ES6 imports in the main component.js file, but I don't know how valuable that is as it seems to encourage overly complex components.

In any case, those are my first thoughts as I think about how we can take on this one together.

[avdaredevil]

@prodonjs Great ideas, so the Polymer3 part crossed my mind, and I think we probably should go with that approach. However, I still feel strongly about the templating engine. However we can still minify and bundle our source (by not running the templating on runtime, but rather before building the prod/dev build. Something like:

npm run
OR
npm run dev

• Jade -> HTML
• Serve directly from components.html (or components.js eventually with polymer3)

npm run [build / prod]

• Jade -> HTML
• Vulcanize / minify components.[html/js]
• Version the bundle, and preprocess the code, to disable _devMode

[prodonjs]

SGTM. I'm working on two PoCs, one with Webpack and one using Polymer CLI. I think the webpack version will end up being the better solution of the two and converting what you already have to Polymer3 is already mostly there.

I'm still a little bit uncertain of why we want to have server-side rendering of the front-end templates. It seems like we'd accomplish the same thing using webpack in our production build task that would package all of the static assets into a folder and then we'd just make sure that we serve that statics folder with express. Are there pieces in the server runtime that we'd expect to need to pass to the template when it's first rendered?

[avdaredevil]

Let's do a quick meeting to discuss the templating part. I don't plan on having node / express doing any of the templating. So this is not what I mean:

app.set('templating_engine', 'jade')

I meant webpack would parse jade so we can write symantically sound and condense HTML and have it preprocessed and minified for us by webpack.

---

I also think Webpack is probably the better / more scalable way to go. To my knowledge Polymer CLI is better for static web builds?

[prodonjs]

Created #2572 which addresses the following

• Rewrite the dashboard backend in Node.JS
  • Wire in Express
  • Wire in Jade / Pug
• Add a readme
• Set up Babel / Webpack for Transpilation

[avdaredevil]

@prodonjs How are we looking with the Build Information API?

[prodonjs]

With respect to build version, do you know what the authoritative source of obtaining this is? In my cluster, I see the following.

This feels like a top-level object to retrieve information from but I'm not sure. Any thoughts?

[avdaredevil]

So according to my conversation with @kunmingg it seems we want to add a new optionalParam with the name kf_version and use a default of 0.5.0. And create an issue to update the deployment script which will pass the correct version to dashboard upon deployment. File in question: centraldashboard.jsonnet on line 7.

I have a feeling, in that case, we could just have our webpack read the root-level version info, or use git ls-tag on build and store that.

[avdaredevil]

Any thoughts on this @prodonjs?

[prodonjs]

It seems like doing some statically during build time would be the best option. The command that already lives in the Makefile git describe --abbrev=0 --tags seems like it gives us what we're looking for. We could have that be set as an environment variable only in the Makefile.

[k8s-ci-robot]

@avdaredevil: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.