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

HTTP caching layer directly in the gateway #15

Open
hsanjuan opened this issue Oct 6, 2023 · 1 comment
Open

HTTP caching layer directly in the gateway #15

hsanjuan opened this issue Oct 6, 2023 · 1 comment
Labels
need/triage Needs initial labeling and prioritization

Comments

@hsanjuan
Copy link
Contributor

hsanjuan commented Oct 6, 2023

Caching on top of rainbow means we cannot effectively integrate the content-blocking layer as the cache would bypass it.

If we can introduce an HTTP cache directly at the gateway handlers that performs moderately well then we could resolve this problem. Investigate what options exist in go.

@hsanjuan
Copy link
Contributor Author

So, it seems most caching options out there focus on in-memory caching, or sending the data to redis. I mean, it's not like everyone stores their files on disk chunked into a key-value store and have to recompose files from it.

If we put a cache in there, perhaps we can make a flatfs datastore and store the re-assembled files with it. In any case we would have to write this somewhere inside the gateway code boxo so that it sits after blocking-checks and before hitting unixfs. I don't think caching makes sense for individual car blocks, we can go do disk for those already.

@lidel lidel added the need/triage Needs initial labeling and prioritization label Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization
Projects
None yet
Development

No branches or pull requests

2 participants