Move Self Service UI to Node Application about manageiq-ui-service

[himdel]

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..

[chriskacerguis]

@himdel @AllenBW @chalettu opinions and/or thoughts?

[himdel]

Euwe or euwe+1?

[chriskacerguis]

May release (F release?), unless I'm off by a letter.

[himdel]

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..

[chriskacerguis]

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:

1. It more fully separates UI / API, I feel that it's "clunky" to load it the way we are.
2. 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?

[himdel]

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 :)

[Fryguy]

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?

[chessbyte]

@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.

[chalettu]

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.

[chessbyte]

@chalettu btw - really, really like your avatar!

[chriskacerguis]

So, my thoughts are as follows:

1. Easy of debugging / development; we can use the node debugging, and (as Chris Hale) we can isolate the traffic easier.
2. 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).
3. 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.

[chalettu]

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.

[himdel]

Easy of debugging / development

Just a note.. we're already doing that in development, so this benefit seems rather ..empty :).

[chriskacerguis]

Dubugging also applies to production.

[AllenBW]

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.

[himdel]

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..)

[chriskacerguis]

@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.

[himdel]

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)

[chriskacerguis]

In talking with @Fryguy we will need a /ping endpoint (maybe call it /health-check) for the health check from the UI worker.