Discussion for cache strategy

[thinkverse]

Figured I'd open an issue to discuss options for caching results from the GitHub API. While caching strategies aren't my strong suit, I had some ideas.

Years badge caching

1. Cache the created_at date, and set the age to the remaining days until the user celebrates its next year.
2. Save the created_at date fully in the DB, and cache the image the remaining days until the next increment.
3. Cache the SVG for the duration of the remaining days, then the next time it fetches display the new number and re-cache.

Those are all similar but my thought is that after we fetch the date the first time, we really don't need to fetch it again for that endpoint since it can be cached for the duration of the remaining days, then is just a simple increment by 1 and cache for another year right.

API caching

Another thought is to redo the endpoints entirely and follow an API structure and make the :user the root of the endpoints, that way we can save a copy of the result since we're only interested in two fields currently, the endpoints could be;

:user/repos/:repo/visists
:user/repos
:user/years

The only problem this idea though is the count of public repositories will be off when cached for an extended period of time.

Thoughts anyone? 🤔

[pujux]

I will add caching in the next days, going to use memory-cache module

[pujux]

I actually don't think we will need caching, do you?

[thinkverse]

Well, I wasn't sure at first, that's why I brought it up, but it seems GitHub itself saves the images and caches them for us, so this seems redundant right now, maybe later if requests pick up this could all be an option but for right know it doesn't seem necessary. 🤔

[pujux]

Can I somehow check how many requests are made using the token?

[thinkverse]

Actually looking at the docs, there is /rate_limit 👍