Rate limits?

[phiwut]

Github's abuse detection mechanism gets triggered in the racing mode (Link). I think that you should reduce the number of requests per second.
The Requests return the following message:

{
  "documentation_url": "https://developer.github.com/v3/#abuse-rate-limits",
  "message": "You have triggered an abuse detection mechanism. Please wait a few minutes before you try again."
}

[SevenOutman]

@phiwut Did a dialog show up telling you rate limits was exceeded and you could provide an access token to get over it?

[indus]

Even with extended rate limits it is hard to use hubble for medium or big project. I would suggest to use the latest number of stars and count backwards from there to draw the chart. So a user would at least get the latest results.

You can even use the current starcount as a test to decide wich way to go...

[SevenOutman]

@indus Good advice. Yes this way user can see latest results. However, the user that requests this race feature #3 wants to see them "race each other", and I feel it means a process from the beginning. 😂 So I should probably focus on controlling the request rate, it’s the key problem itself after all.
Actually I have encountered "rate limit exceeded" but never an "abuse rate limit". Maybe it’s happening under a faster network speeds. 😂

[indus]

@SevenOutman Then maybe there is some way to set up a cronjob on a pc or server that fetches old star data for repos with over 1000 stars https://github.com/js-org/stats.js.org/tree/master/_data once a week or so that gets pushed in this repo and that gets used a primary source keeping API requests to a mimimum.
Thats what I used to feed the tables of stats.js.org (https://raw.githubusercontent.com/js-org/stats.js.org/master/_data/recs.csv History: https://github.com/js-org/stats.js.org/commits/master/_data/recs.csv). The data was preprocessed by jekyll.

[SevenOutman]

@indus I see. Disadvantage is that the repo is then getting too big. But I'll still consider it as an alternative.