From 85e098ea24465b479667e82d65a5354719ca771b Mon Sep 17 00:00:00 2001 From: Emil Lerch Date: Wed, 11 Mar 2026 13:20:13 -0700 Subject: [PATCH] add todo about the server cache --- TODO.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/TODO.md b/TODO.md index 38956eb..7c82637 100644 --- a/TODO.md +++ b/TODO.md @@ -58,6 +58,28 @@ exported as a public constant. Callers currently pass the default. `default_risk_free_rate` in `src/analytics/risk.zig`. Eventually consider making this a config value (env var or .env) so it doesn't require a rebuild. +## On-demand server-side fetch for new symbols + +Currently the server's SRF endpoints (`/candles`, `/dividends`, etc.) are pure +cache reads — they 404 if the data isn't already on disk. New symbols only get +populated when added to the portfolio and picked up by the next cron refresh. + +Consider: on a cache miss, instead of blocking the HTTP response with a +multi-second provider fetch, kick off an async background fetch (or just +auto-add the symbol to the portfolio) and return 404 as usual. The next +request — or the next cron run — would then have the data. This gives +"instant-ish gratification" for new symbols without the downsides of +synchronous fetch-on-miss (latency, rate limit contention, unbounded cache +growth from arbitrary tickers). + +Note that this process doesn't do anything to eliminate all the API keys +that are necessary for a fully functioning system. A more aggressive view +would be to treat ZFIN_SERVER has a 100% record of reference, but that would +introduce some opacity to the process as we wait for candles (for example) to +populate. This could be solved on the server by spawning a thread to fetch the +data, then returning 202 Accepted, which could then be polled client side. Maybe +this is a better long term approach? + ## CLI/TUI code review (lower priority) No review has been done on these files. They are presentation-layer code