Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

caching strategy #24

Open
juliangruber opened this issue Apr 16, 2018 · 8 comments
Open

caching strategy #24

juliangruber opened this issue Apr 16, 2018 · 8 comments
Labels
bug Something isn't working help wanted Extra attention is needed question Further information is requested

Comments

@juliangruber
Copy link
Contributor

@MarshallOfSound very well analyzed:

From the looks of it, the cache expires every 15 minutes, that means we have a maximum number of apps as 1250 (5000 rate limit / 4 requests per hour). According to apps-using-electron at the time of that packes generation (a while ago) there were 13455 repos on github that used Electron as a dependency. That number is probably way up now so we're probably gonna need a SUPER TOKEN from GH 😉 @zeke

@juliangruber juliangruber added bug Something isn't working help wanted Extra attention is needed question Further information is requested labels Apr 16, 2018
@juliangruber
Copy link
Contributor Author

juliangruber commented Apr 16, 2018

we might be able to slightly improve the number by at the end of each token quota period fetching as many extra repos as possible, and pre fill the cache. That's not going to be of help though if we don't have any requests left anyway.

@juliangruber
Copy link
Contributor Author

Can we use the GraphQL api to update many repos at once?

@mathieudutour
Copy link

How about asking for the dev to add a webhook for the release event pointing to update.electronjs.org and be a lot more aggressive for the caching? Like 2 or 3 hours?

@zeke
Copy link
Contributor

zeke commented Apr 20, 2018

That's an interesting idea, @mathieudutour. More work on the part of the app developer, but could be worth it for scalability.

@mathieudutour
Copy link

Indeed, might be a little bit more work (even tho it takes literally 30s to add a webhook) but at the same time, the cache would be invalidated instantly (instead of potentially having to wait 15min) so it’s a win-win

@juliangruber
Copy link
Contributor Author

I like that! Seems like we could add it next, and then make this simpler by turning this into a GitHub app maybe? Also, with webhooks, the cache can expire never I think.

@mathieudutour
Copy link

mathieudutour commented Apr 21, 2018

If it’s a requirement to use this service, yes it could never expire. But we could also have a mix: if you want the cache to update directly when there is an update, then you need to add a webhook. But maybe we want to make it super simple to start and only have it as an optional (but strongly recommended) step

@MarshallOfSound
Copy link
Member

We could also make a small FE for users to set up their repo's.

GH API has a webhook endpoint so if we oAuth in we can set it all up for them:

https://developer.github.com/v3/repos/hooks/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants