-
Notifications
You must be signed in to change notification settings - Fork 498
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
Proposal: cache the /list endpoint for a short period of time? #893
Comments
I think some level of caching would be a big bonus here. Could we have manual invalidation on new version pushes? |
@robjloranger yea, I think we could definitely have that. Maybe some variation on the webhook that got proposed in #104 could do the invalidation - what do you think? |
Exactly 😁 some endpoint to say some module was "updated" and we can even check to see if it does have a new version, and if so update the list cache. |
Update: #1068 is the endpoint that @robjloranger talks about in #893 (comment) I am going to start prototyping this now |
We've discussed this a few times and decided this caching logic shouldn't live inside of Athens. We are discussing an "offline mode" in #1506, which will treat the list endpoint as immutable. If Athens gets an offline mode, then caching will become unnecessary if you run it in that configuration. If you were to still run it in online mode configuration and still want caching, the best thing to do would be to use a caching proxy. There are several widely used open source ones and several cloud based ones. I have also built a "toy" one here for reference. I am going to close this. |
Is your feature request related to a problem? Please describe.
The
/list
endpoint contacts the upstream VCS to get version numbers, so that corresponds to onegit
(orhg
etc...) operation per dependency. For a public deployment of athens, I believe that's untenable.Describe the solution you'd like
I think it'd be a good idea to add an option to the proxy to cache the
/list
endpoint. That would mean that it fetches the version list directly from storage until a TTL expires. At that point it would do the list request to the upstream once, refresh storage, and reset the TTL. If there are multiple proxy servers running in a cluster, they would use #760 to ensure only one refresh is done after the TTL.If we did this, we would need to tell package authors that if they push a new commit or release a new tag, it won't show up in Athens until the TTL expires. We could let them trigger a refresh for their module with #104, but I'm not sure if that's a reasonable solution.
Describe alternatives you've considered
I haven't thought of anything else that would reduce upstream requests for each
/list
call.Additional context
I'm researching and preparing for #772 and found that some way to tell whether a response was cached or not would be really helpful for us.
The text was updated successfully, but these errors were encountered: