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

proposal: recommend bored-engineer/github-conditional-http-transport for conditional requests #3468

Closed
bored-engineer opened this issue Feb 8, 2025 · 1 comment · Fixed by #3469

Comments

@bored-engineer
Copy link
Contributor

bored-engineer commented Feb 8, 2025

Currently the go-github documentation suggests using the (archived) gregjones/httpcache library for conditional requests:

The GitHub API has good support for conditional requests which will help prevent you from burning through your rate limit, as well as help speed up your application. go-github does not handle conditional requests directly, but is instead designed to work with a caching http.Transport. We recommend using gregjones/httpcache for that. For example:

Recently, I've done some work reverse engineering the GitHub ETag algorithm and written a *http.RoundTripper that is specialized for the GitHub REST API. You can find more details/results in the README: https://github.com/bored-engineer/github-conditional-http-transport

I wanted to open an issue/discussion first before just opening a PR adding my library to the documentation as another option/recommendation, especially given it is not a RFC 7234 compliant cache. Instead it relies on (undocumented) GitHub API behavior to achieve a higher hit rate than a typical HTTP cache, in particular when combined with dynamic credentials such as a GitHub app.

However because it relies on undocumented behavior I wanted to collect any thoughts/input on recommending it first. The worse case behavior here is that if the ETag algorithm changes in the future, all requests will be become cache misses which is already the case if you are using dynamic credentials anyway...

@gmlewis
Copy link
Collaborator

gmlewis commented Feb 8, 2025

I'm happy to review a PR that updates the README.md in this repo to more clearly describe the current state of affairs and explain what your transport offers, how to get it, and how to use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants