Revisit rail landing data flow and freshness #1
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Watching trains in person, the rail landing page left me wondering: what is actually updating, and when? I assumed a poll every 10 seconds meant fresh data every 10 seconds.
The browser still polls every 10s, but the server uses a 9s cache and normally returns the expired snapshot while fetching its replacement in the background. That replacement arrives on a later poll. Live checks showed responses already about 10s old, aging further on screen—not a fixed 18s delay or a guarantee that every response is 9s+ old, but avoidable lag in the normal polling flow.
One concrete requirement: undo that stale-cache design. Once the cache expires, return refreshed data rather than the expired snapshot that triggered the refresh.
Beyond that, revisit the rail landing data flow with fresh eyes. Cleanup, refactoring, or a rewrite are all fair game; no prescribed architecture. The goal is a page that makes sense while you are actually watching the trains.
Starting points:
src/rail/api.tsandsrc/views/pages/rail/{client.ts,index.tsx}. “Live” currently means recently fetched from MARTA, not recently observed by MARTA, and rail ETAs only change on poll responses. GitHub PR #96 fixed stale reopening behavior but retained this polling design.