Project architecture design document #32
Conversation
This is architecture proposal for MVP version of the product. When MVP is done it'll be revisited to verify whether it (still) works well.
|
@bgrant0607 @PeWu @mgr01 @gmarek @jwforres @lavalamp @jimmidyson @preillyme @emacias CCing folks that expressed interest in this project and its architecture. |
|
LGTM |
|
👍 |
|
LGTM |
| Rationale for having a backend that implements business logic: | ||
|
|
||
| * Clear separation between the presentation layer (frontend) and business logic layer (backend). | ||
| This is because every action goes through well defined API. |
There was a problem hiding this comment.
Private API only for backend<->frontend communication. It has to be well defined, though. As every API.
There was a problem hiding this comment.
Do you expect the frontend and backend to be deployed together in the same pod? That would make upgrades simpler.
There was a problem hiding this comment.
IIUC the next paragraph frontend will run in browser.
There was a problem hiding this comment.
The plan is to have everything in a single package running in a single pod. In the pod, backend serves JavaScript frontend to the user and then the browser JavaScript communicates with the backend.
| The backend runs in a Kubernetes cluster as a kubernetes service. Alternatively, it may run anywhere | ||
| outside of the cluster, given that it can connect to the master. The backend is a HTTP server that | ||
| proxies data requests to appropriate remote backends (e.g., k8s apiserver or heapster) or implements | ||
| business logic. The backend implements business logic when remote backends APIs do not |
There was a problem hiding this comment.
instead shouldn't we be pushing back on the api to support the use cases consoles want/need so that everyone can benefit from it instead of writing one-off versions just for kube dashboard?
There was a problem hiding this comment.
Yes, though that takes longer.
A Go server could also reuse our client-side caching library.
There was a problem hiding this comment.
But it's worth trying other caching solutions.
There was a problem hiding this comment.
@jwforres Yes, changes to API should be pushed whenever possible. The UI will, however, contain business logic, no matter what is in the API. We need to place the business logic somewhere and Go backend is a good place for it.
You might as, why business logic in the UI? Imagine a page that displays services, replication controllers and pods at the same time. The data has to be fetched from the apiserver with multiple requests, then joined and then perhaps processed. This is business logic the UI will have.
There was a problem hiding this comment.
Relevant:
kubernetes/kubernetes#12143
kubernetes/kubernetes#7311
So far, nobody has had the time to move these forward, unfortunately.
|
Merging this, as this is the architecture we ended with. |
Project architecture design document
Fixed project name. changed primeng to opensds-dashboard
This is architecture proposal for MVP version of the product. When MVP
is done it'll be revisited to verify whether it (still) works well.
This change is