Quicker loading for github logins on the Claims Progress dashboard

[FlacoJones]

It appears the API calls are made for these, but the UI takes quite a while to update, or never updates at all.

One idea: if the nodes([nodeIds]) request in Github returns the logins in order, maybe we can fetch these all with a single call?

[ArcAnya]

I am not sure what you mean with "in order"? Basically the entire (filtered and unique) github ids array of the winners is fetched all at once to limit the number of calls to the github api - later the sorting happens based on each specific id in a line

The problem I think is that we have 800+ github logins and a limit of 100 ids we can fetch at a time. I wonder whether we reach the api rate limit quite quickly when several users go on the overview a couple of times in a row, and hence it doesn't fetch anymore

[ArcAnya]

A few things I could think of to improve this:

• allow for winners to show in batches of 100: would allow for some logins to show but I guess this still might be facing risks of rate limits?
• add the github login to our own API: (we already have github ids linked to users) I guess we might have the same constraint of 100 arguments at a time (?) but at least less rate limit risks? Guess we would only need to make sure the github login stays up-to-date in case users change it?
• an automatic "bunch refetch" after a timeout and in case the github logins are still not showing - or a "refetch github data" button that re-triggers the entire fetching process for the logins?
• or the same but on an individual level so that we can only fetch the logins for the necessary users
• link the github id to the user's profile on OpenQ - where the github login should show (if there is no rate limit at that moment)