thermograph/frontend/server/internal
emi da82abda27
All checks were successful
secrets-guard / encrypted (push) Successful in 8s
shell-lint / shellcheck (push) Successful in 14s
Build + push frontend image (Forgejo registry) / build-push (push) Successful in 42s
Deploy frontend to beta VPS / deploy (push) Successful in 1m5s
frontend: fetch City() concurrently with the page's primary API call (#37)
MonthPage and RecordsPage each made two backend calls sequentially
(CityMonth/CityRecords, then City) where the second never depended on the
first's result. fetchWithCity launches both concurrently via goroutines
and a WaitGroup.

Verified live against a stub with an injected 400ms delay on both
endpoints: city page (1 call) and month/records pages (2 calls each) all
cost ~0.404s now, not double for the two-call pages.

Error priority preserved exactly: primary's error wins even when City
also fails, matching the old sequential code. One trade-off: City() is
now always launched even on a request about to 404 from primary, costing
one extra cheap lookup on that rare path.

Tests include a deterministic concurrency proof via rendezvous channels
(the old sequential code would deadlock this test, not just run it
slower). Full suite green under -race -count=2.
2026-07-24 06:25:06 +00:00
..
config frontend: rewrite the SSR content service in Go (#28) 2026-07-24 00:53:48 +00:00
content frontend: fetch City() concurrently with the page's primary API call (#37) 2026-07-24 06:25:06 +00:00
contentapi frontend: rewrite the SSR content service in Go (#28) 2026-07-24 00:53:48 +00:00
contentdata frontend: rewrite the SSR content service in Go (#28) 2026-07-24 00:53:48 +00:00
format frontend: rewrite the SSR content service in Go (#28) 2026-07-24 00:53:48 +00:00
handlers frontend: rewrite the SSR content service in Go (#28) 2026-07-24 00:53:48 +00:00
render frontend: rewrite the SSR content service in Go (#28) 2026-07-24 00:53:48 +00:00