Add feature flag for replacing Applications and Sources with query service backend

[jpellizzari]

Closes #2727
Closes #2759

Adds a feature flag to swap out the UI/Backend of Applications/Sources with the query service backend. Set the WEAVE_GITOPS_FEATURE_QUERY_SERVICE_BACKEND flag to enable it. The UI is roughly the same, although it is simplified to accommodate our querying system.

[enekofb]

lgtm!

Some thoughts to catchup later on:

• to instrument the switch to understand users behavior, to provide info on whether we improve their situation and whether there is still some feature gap that customers might require (this sounds like a ticket)
• when used the applications or sources based on explorer, how the user could search or navigate the collection.
• how to cover user documentation (another ticket or same issue)
• add some unit tests

i could read and understand the UI code but not fully reliable for reviewing the lower details for the UI, we might want also to add some FE as a reviewer

[enekofb]

if we are able to enable that switch out of the deployment context + captured that behaviour via events (see my comment on pendo), we could have greater insight on which one has more adoption and measure that over time to help us with Objective 1

something like https://flaviocopes.com/react-show-different-component-on-click/

[enekofb]

it could also helps framing the maturity message of swich to new experimental UI or similar

[jpellizzari]

If this were an open source feature, I would be more inclined to collect usage metrics at scale with Pendo. Since it will only be a couple customers at the start, we can probably skip metrics for now.

[enekofb]

👍 on pendo,

if we are able to enable that switch out of the deployment context

do you think that putting the switch logic in the UI vs as Feature Flag at deployment time could be beneficial at this stage?

My hypothesis is that if we put it as feature flag, the journey for the platform admin would be like

1. I deploy with useQueryServiceBackend=true
2. I go to applications or sources
3. I use it in my regular workflows

• if I find limitations using it (which is expected given its maturity)
  • I will report the feedback, switch back to the old experience and wont try it again until that feedback is addressed
• If i don't find limitations, we are happy

In the context of having the feature flag in the UI, the journey could be the same but given that flipping to the old one does not require deployment, it is less effort for the platform admin to try it back and forth so more chances to get better feedback.

[jpellizzari]

We aren't really equipped to do a button-press feature-enable. We would need to persist that and the only option available to us would be the user's localStorage.

Given that the customer probably cannot even load the other experience, I don't know how useful that would be.

[jpellizzari]

Added UI tests

[jpellizzari]

@enekofb PTAL Added sync controls and the backend logic necessary for scoped querying, so the text input is back:

[enekofb]

The backend changes looks good
In the UI, when tested locally with queryBackendEnabled

i could see how from the app and sources experiences there are calls to the old endpoints

I've pointed our integration environment to the branch to test it

https://wge-2448.eng-sandbox.weave.works/applications

It has the same behaviour

[enekofb]

Doing some searches i could see how the data from the backend comes correctly but the UI has some unexpected rows

[jpellizzari]

Doing some searches i could see how the data from the backend comes correctly but the UI has some unexpected rows

@enekofb Could you provide a link? Or is this in local dev.

[jpellizzari]

The backend changes looks good In the UI, when tested locally with queryBackendEnabled

I've pointed our integration environment to the branch to test it

https://wge-2448.eng-sandbox.weave.works/applications

It has the same behaviour

Have the pods been bumped?

[jpellizzari]

i could see how from the app and sources experiences there are calls to the old endpoints

@enekofb This part of the code is requesting sources, so this is not coming from the table but from another component that needs that data:

weave-gitops-enterprise/ui-cra/src/components/Clusters/OpenedPullRequest.tsx

Line 68 in 100f521

const { gitRepos } = useGitRepos();

[enekofb]

i could see how from the app and sources experiences there are calls to the old endpoints

@enekofb This part of the code is requesting sources, so this is not coming from the table but from another component that needs that data:

weave-gitops-enterprise/ui-cra/src/components/Clusters/OpenedPullRequest.tsx

Line 68 in 100f521

const { gitRepos } = useGitRepos();

@jpellizzari thanks for looking

Not sure if you have also experienced but that seems to block the page loading some times (given the feeling that is the data table which is slow). Not sure if we could / should do something about it but just pointing out.

[jpellizzari]

@enekofb This should fix the issue of weird rows showing up: c55dd89

PTAL

[enekofb]

LGTM

Tested locally with a few queries around apps v2, sources v2 and explorer and everything looks good to me

I realised that given the calls to the v1 objects endpoint loading apps page it takes longer than explorer or sources (added ticket to follow up #2769 (comment))

I was not able to do a thorough look into the UI code so suggested to get some other reviewer for this part to validate the configuration logic around apps and sources UI