Let’s not do this for UX performance. I am afraid Foreman is a kind of application where SPA won’t necessary help to improve loading times, we have resources being loaded from backend systems and some pages in Katello are exceptionally slow in some cases. SPA is good if you keep your browser tab opened, like your gmail. But if you are Foreman user who visits an instance three times a day, SPA can actually lead to the opposite - slow initial loading time. Remember Google Groups and its terrible loading time? That kind of experience is possible with the new Foreman, we must be very aware of this and avoid it. Google Groups are dead by the way.
Let’s set an initial loading time goal and never exceed it.
What matters these days is coding effectivity - if SPA can deliver in this regard, that’s more important than loading times if we keep the initial load on reasonable level (let’s set a goal in advance). Every development team or community is different, we must make sure most of us will be effective enough delivering patches, changes or understanding how things works. We need to keep this in mind when going forward. This is the biggest threat of all I think. We will need a lot of new components, tests, demos and documentation.
Let’s make sure we are all able to deliver quickly.
I like the idea of single API for both CLI and web, also I think that REST is weird idea and I always preferred RPC. If GraphQL solves some problems, sure I’d be very careful tho with Rails integration - to me it looks like we are skipping controllers in MVC pattern. This can easily lead to code duplication in web/cli layers. What works for a web app doesn’t need to work for us, we have the rule: if it has UI, it has also CLI. To me it looks like GraphQL will likely be a complementary API, not a replacement. But we don’t want revolution, but evolution. So part of our app in ERB, part in React. Then we would end up with controllers, API controllers and GraphQL code logic on clients. This smells.
Let’s make sure GraphQL works nicely with CLI and web portions.
Let’s create an extensive UI prototype of most Foreman pages in advance.
Let’s keep accessibility in mind.
Last but not least, if we pick a component for migration to some different stack, let’s actually do the most challenging one - new/edit host form/wizard rather than doing things like subnets. Because if it works for host form, it probably works for the rest.
Let’s start with the most challenging parts.
Long term, I’d love Foreman UX to be simplified and converging to a single stack. But last couple of years, I’ve only seen adding more technologies and it was rather frustrating. I am all for convergence, whatever this is, but I am afraid that evolution will be long and painful. So with this regard:
Let’s execute fast.
Once it’s all set, let’s set a goal of two Foreman releases for the transition period. We are on a roll, let’s not ruin current user experience.