Fix: Display beta resources subgroups for admin group

[MaryannGitonga]

Overview

Closes #2356

Demo

Notes

Optional. Ancillary topics, caveats, alternative strategies that didn't work out, anything else.

Testing Instructions

• Checkout to this branch.
• Load local instance of GE.
• Navigate to the Resources Explorer tab
• Toggle the Switch to beta toggle button
• Observe groups under the admin group

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://jolly-sand-0ac78c710-2364.centralus.azurestaticapps.net

[Onokaev]

Nice catch. Could we also update the fallback resources.json file. I noticed that it doesn't have the new beta nodes that prompted for this fix.
Get a new copy here:https://graphexplorerapi.azurewebsites.net/swagger/index.html on the openapi/tree endpoint

[Onokaev]

Looks good!

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://jolly-sand-0ac78c710-2364.centralus.azurestaticapps.net

[darrelmiller]

@thewahome @gavinbarron Why is the resources tree being populated from a static JSON file? This information should come from DevX API. Microsoft Graph is updated weekly. We cannot wait until the next Graph Explorer release to get the latest version of the available resources. We also can't add an 8MB payload to every user of Graph Explorer regardless of whether they look at Resource Explorer or not.

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://jolly-sand-0ac78c710-2364.centralus.azurestaticapps.net

[MaryannGitonga]

@darrelmiller, the update in the resources.json file is for the cached resources, in case GE cannot fetch the resources from DevX API. The resources in the file were outdated hence why I did an update. In normal cases, the resources should be fetched from the API. And that works fine now.

I am currently looking into a periodic comparison that can be done on the resources.json to check if it's outdated and if that is the case, it is updated with the latest resources. It could be resource-intensive hence why I think it would be a better idea if it were after a significant period of time (eg. a few days). Feel free to share your thoughts on this.

I hope I have answered your question.

[darrelmiller]

Hi @MaryannGitonga Thanks for the clarification. A few things. I don't believe the caching is working as intended. I just went to Graph Explorer, called Microsoft Graph, showed the permissions tab, which returned results from DevX API and still the resource explorer does not show the additional endpoints under admin.

Secondly, I don't believe that packaging a cached copy of the resources.json as part of the GE deployment is an effective way to handle DevX API outages. If a customer has no connection, then they will not be able to use Graph Explorer to make calls, so the value of having the resources tab is severely limited. If DevX API is down then I would be perfectly fine in degrading the experience to indicate that the resources tree is not currently available. If we choose to use caching to provide some kind of offline mode, then we should leverage one of the many caches that exist in the browser, we should not be inventing our own.

Adding resources.json to the GE component would significantly increase its download size for every customer, regardless of whether they used the resources tab or not. That doesn't seem customer friendly to me.

I believe this is a similar solution to what we do for samples today. For the same reasons, I don't think we should continue with that approach.

[MaryannGitonga]

@darrelmiller, this is well noted. I will work on the in-browser caching on a separate PR. Thanks

[thewahome]

@thewahome @gavinbarron Why is the resources tree being populated from a static JSON file? This information should come from DevX API. Microsoft Graph is updated weekly. We cannot wait until the next Graph Explorer release to get the latest version of the available resources. We also can't add an 8MB payload to every user of Graph Explorer regardless of whether they look at Resource Explorer or not.

@darrelmiller, GE fully depends on the DevX API to get the resources. The JSON was initially used to have a local copy of it so that we can have a cached version to show in case of inconsistencies with the DevX API.

I understand what you are saying about caching. We have a better mechanism when handling the sample queries which we will use here and remove the local JSON files.

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://jolly-sand-0ac78c710-2364.centralus.azurestaticapps.net

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://jolly-sand-0ac78c710-2364.centralus.azurestaticapps.net

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[gavinbarron]

@darrelmiller I agree that we should be using DevX API as a primary source, anything else is unacceptable.

Having a fallback to use should we not get a response from DevX API is a good idea in my opinion to prevent providing a poor user experience. We can and should be loading that resource using an awaited import() function, thus the weight is only placed on the browsing experience when DevX API has failed to respond.

Now if we were to leverage some of the browser storage APIs and cache the response from DevX API indefinitely but keep a refresh period to update the cache I'd be totally comfortable with dropping the static JSON file altogether and providing a degraded experience if the user has never loaded GE on that browser and DevX API fails to respond.