should probably cache them at least over some interval, since those will be the primary traffic drivers likely
[backend] Caching feeds #8
We can go for (削除) redis (削除ここまで) valkey or memcached for that, and then I think it would be great we start providing a docker compose if it needs to spin up a few different services (valkey for caching and possibly for rate limiting is a great solution I think).
What do you think about that?
I am a little hesitant to make docker the default way to deploy this, which is sorta what happens when you start bundling multiple services together, because that really raises the complexity and resource requirements of rehosting. Like the fastapi/htmx design rather than standard frontend/backend is intended to be very very deployable and resource light.
I would like to know if there is some caching service we can spawn from within python in a reasonable way, but I know redis/valkey is the standard and have used it to good effect in the past, so I also don't want my docker aversion to stand in the way of this getting done and invite proposals on what an impl might look like here
It can be in memory cache but it might grow a bit bigger in memory usage.
A first iteration can be with fastapi-cache in memory and if later there's a need for more, changing the caching backend is easy
hmm yeah, i'll keep my mind open and defer to running code over my aversion to docker in any case. it seems like we'll want to cache at the query level and at the response level esp as we move towards effectively implementing a tracker here. still trying to just get a MVP so i am trying to stay a little perf agnostic right now - get it working, then make it fast, but i admit i am esp vulnerable to the temptation to preoptimize
done awhile ago!
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?