Comments (20)
Another thing just came up on gitter... pictures/
If we ever start having SSUI run separately from the main UI, we'll need to solve how to show pictures/
.. that is, user-uploaded icons.
Right now, the only way these work is that SSUI runs on the same domain as manageiq and generates an url that is served by the rails app (/pictures/10r4.jpg
for example). These never work in devel mode and won't work if we ever separate the two.
Probably need to expose them via the API or something like that..
EDIT: should be resolved now..
from manageiq-ui-service.
@himdel @AllenBW @chalettu opinions and/or thoughts?
from manageiq-ui-service.
Euwe or euwe+1?
from manageiq-ui-service.
May release (F release?), unless I'm off by a letter.
from manageiq-ui-service.
Ah, thanks .. then it's probably doable 😓 :)
Will that application be running on a different appliance, or on the same one, except served by apache redirecting to node instead of apache directly?
And.. what's the point? I mean, SSUI is some static files and the manageiq api, do we really want that extra complexity on the appliance? I'm not seeing any reason why we should do that so far..
from manageiq-ui-service.
It will run based on how the end-user sets up things...so during the install they can say what it is, and MIQ will set things up.
As for point, as we expand things, here are the more "larger" thoughts:
- It more fully separates UI / API, I feel that it's "clunky" to load it the way we are.
- It will allow us to do things the "node way" more easily.
I feel that this will more simplify the loading of the appliance, not complicate it. Why do you feel that it will make it more complicated?
from manageiq-ui-service.
Well, right now, the build process is "compile everything to that directory", and the appliance config related to ssui is "serve /self_service from that directory". That's it.
Now, we'll need to actually run the node process, that means manually setting up either a systemd service, or installing supervisord or something similar to run the node server. Then the server has logs, so setting up logrotate for these too. Then you still need it to listen on that same URL so that apache config will stay, except it will use mod_proxy_http
to redirect that sub-url to the node process.
And then finally, we need to resurrect the node server's production mode handling (it is there in some form but hasn't been used and is probably not quite ready), we'll definitely need #44 resolved so that it doesn't break the consoles.
And all that just to get where we are now :). But obviously if we want to leverage the node server to ..do something else than redirecting to api and serving files, it does start to make sense :)
from manageiq-ui-service.
I am also question the gains from doing this. I can see if we did something with the node server where the client talks with the server, but all we do with our applications right now is a single-page-app, which doesn't need a server (aside from the manageiq API). Is the goal to get away from a SPA?
from manageiq-ui-service.
@chriskacerguis I think you need to state the reasons for such a proposal. Without concrete reasons, I am a definite 👎 on change for the sake of change.
from manageiq-ui-service.
So there are some advantages of separating out the UI into its own running process. By running as its own process, it allows you to separate basic http traffic from the backend Ruby API process itself. This can be useful if traffic can get pretty heavy on one or both of those processes. I think some of the advantages are that it would bring unity to our current development workflow because in order for us to develop locally we launch the UI onto a small node server process as it is. I think it makes sense to just package it up that way as well.
from manageiq-ui-service.
@chalettu btw - really, really like your avatar!
from manageiq-ui-service.
So, my thoughts are as follows:
- Easy of debugging / development; we can use the node debugging, and (as Chris Hale) we can isolate the traffic easier.
- As we have move forward with more UI's and advanced UI's we can load them easier than we would with the current process. For example, during the build, making sure that we don't "clobber" other "UI's" (without this we will need some way to manage UI URLS vs. just normal "port" management).
- I think it will make the "Core" build process easier as we split things out more...core is just API. Then during the install you "select" with UI workers you want...which just spawns the correct node apps.
tl;dr - Immediate goals would be ones that help increase development velocity vs. more long term goals of UI separation.
from manageiq-ui-service.
Oh, another advantage to splitting these two components apart is it would allow for two potentially different release schedules and break apart coupling the UI from the backend. This is useful for quick bug fixes, patches, etc. I know we currently have everything on a regimented release schedule but it does allow from some flexibility and looser coupling with the backend components release cycle.
from manageiq-ui-service.
Easy of debugging / development
Just a note.. we're already doing that in development, so this benefit seems rather ..empty :).
from manageiq-ui-service.
Dubugging also applies to production.
from manageiq-ui-service.
Gonna confess a wee bitta room for learning on my behalf, so everything I say that's incorrect treat as a question rather than an assertion 😛 😝
Present state For the SUI, shove processed assets into a folder and serve the entry point. Appears to be the same for MIQ.
Desired state I have no idea where we want to be. Is decoupled api/ui desired? Totally gotta grasp on next few months vision for SUI, blueprints, not so sure on architecturally the vision for MIQ product as a whole. Introducing different products that interact with a core api in different ways? (side thought, decoupled api/ui might be neat, turns one products into two, if someone wants to bring their own front-end no problem!)
Anywho, in summary, I wouldn't mind a recorded 👖 sesh to talk this through if 🐣's are able support. I find myself attempting to address this question, does transition to node make sense with this present state, desired state, does this change get us there approach, but I don't have enough information about the latter state to reach a position.
Semi related note, there is nontrivial overlap of libraries between MIQ and SUI, would be kinda neat for the both to pull from a common pool, 💀 the duplication.
from manageiq-ui-service.
Semi related note, there is nontrivial overlap of libraries between MIQ and SUI, would be kinda neat for the both to pull from a common pool, 💀 the duplication.
That common pool should be patternfly, angular-patternfly, and ManageIQ/ui-components ;) (yup, we're not using ui-components in the SSUI yet, but so far we had no reason to..)
from manageiq-ui-service.
@himdel something we will need to address for sure. I suspect there will be a few things like this that we will need to address if we go down this path.
from manageiq-ui-service.
Another thing to check for after.. same origin policy for websocket connections (related: ManageIQ/manageiq#11616)
(probably not a problem, just.. adding to the checklist)
from manageiq-ui-service.
In talking with @Fryguy we will need a /ping endpoint (maybe call it /health-check) for the health check from the UI worker.
from manageiq-ui-service.
Related Issues (20)
- WS-2022-0284 (High) detected in moment-timezone-0.4.1.tgz, moment-timezone-0.5.33.tgz HOT 3
- WS-2022-0280 (High) detected in moment-timezone-0.4.1.tgz HOT 1
- WS-2022-0322 (High) detected in d3-color-1.4.1.tgz HOT 4
- CVE-2022-3517 (High) detected in minimatch-3.0.4.tgz - autoclosed HOT 1
- prepare the development environment to make code changes HOT 5
- CVE-2022-24999 (High) detected in qs-6.5.2.tgz - autoclosed HOT 1
- Unable to open a Native Console for a RHV VM in the Service UI
- CVE-2022-25881 (Medium) detected in http-cache-semantics-4.1.0.tgz - autoclosed HOT 1
- CVE-2023-28155 (Medium) detected in request-2.88.2.tgz - autoclosed HOT 1
- CVE-2023-26117 (Medium) detected in angular-1.8.3.tgz HOT 1
- CVE-2023-26118 (Medium) detected in angular-1.8.3.tgz HOT 1
- CVE-2023-26116 (Medium) detected in angular-1.8.3.tgz HOT 1
- CVE-2022-25883 (High) detected in semver-7.3.8.tgz - autoclosed HOT 1
- CVE-2020-23064 (Medium) detected in jquery-3.4.1.tgz, jquery-3.2.1.tgz - autoclosed HOT 1
- Opening the service ui results in downloading app.js over and over HOT 2
- CVE-2024-21490 (High) detected in angular-1.8.3.tgz
- CVE-2023-42282 (Critical) detected in ip-2.0.0.tgz - autoclosed HOT 1
- CVE-2024-28863 (Medium) detected in tar-6.2.0.tgz - autoclosed HOT 1
- Button role-based visibility rules do not work in UI Service HOT 2
- CVE-2023-44270 (Medium) detected in postcss-7.0.39.tgz
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from manageiq-ui-service.