- Ya
- 19 Agosti 2026, 15:41 UTC
- Mwandishi
- Kamo
- Ahadi ya
- a469ffc
Every visitor was fetching this number themselves. PreviewBanner lives in the shared layout, so on every page it hit /api/changelog/today after hydration, waited, then grew to fit the answer and shifted the page. Caching that route (d3de447) spared the backend but left the request, the wait and the shift exactly where they were, on a value that is identical for every visitor and changes a handful of times a day. It is read on the server now, so the count is already in the prerendered HTML and the browser makes no request at all. /api/changelog/today had no callers left and is deleted. The banner no longer renders conditionally on the count having arrived, which also removes the late reflow — it was resizing after --banner-h had already been measured, and the (pages) layout pads its main element from that variable. Freshness is now an event, not a poll: the fetch is tagged and POST /api/revalidate expires it, so publishing a changelog entry pushes the new count to every page. Wire SecurityService's publish path to call it. The endpoint requires REVALIDATE_SECRET, fails closed when that is unset rather than open (an unauthenticated cache-buster is a free way to make every page re-render on demand), compares the secret without leaking its prefix through timing, and only accepts tags from an allowlist. Verified all four cases: unset -> 401, wrong -> 401, correct -> 200, unknown tag -> 400. Two things a publish event cannot cover, hence a ten-minute backstop: "today" rolls over at midnight silently, and the build container cannot reach SecurityService, so every image bakes a 0 into the pages. The deploy job now calls /api/revalidate once the new pods are serving to correct that immediately — best effort and continue-on-error, because a stale banner must never fail a deploy. Pages stay static: 190 prerendered, still only the two KB routes dynamic, now with a 10m revalidate window rather than a per-visitor round trip.