GET /v1/fiat is called far more often than its content changes. It returns a parameterless, unauthenticated master-data list — the same 7,632 bytes for every caller.
Measurement
Production logs, 6 h window ending 2026-07-30 23:00 CEST:
|
|
| GET calls |
3,891 (~10.8/min, peak 30/min) |
| median |
19.3 ms |
| p95 |
2,487 ms |
| p99 |
5,777 ms |
| max |
16,772 ms |
| over 1 s |
555 (14.3%) |
Responses: 3,386×200, 505×304, plus 860 OPTIONS preflights.
Why 304 does not help much
The endpoint sends an ETag but no Cache-Control (verified against production):
HTTP/2 200
content-length: 7632
etag: W/"1dd0-STGBBsBtray5xZU9Gh6rZwQsp6g"
A conditional request does return 304 with an empty body, so bandwidth is saved. Server time is not: the response has to be built in full before the ETag can be compared. With no Cache-Control, the browser revalidates on every use, so almost every call reaches the application.
Where the calls come from
Not from DFXswiss/services — a search across src finds no request to this route, so the call originates in the API client package rather than in screen code. Which callers trigger it, and how often per session, is not established here.
Scope
Server-side cost of a single call is addressed separately (caching the assembled response in the API). This issue is about the call frequency itself.
GET /v1/fiatis called far more often than its content changes. It returns a parameterless, unauthenticated master-data list — the same 7,632 bytes for every caller.Measurement
Production logs, 6 h window ending 2026-07-30 23:00 CEST:
Responses: 3,386×200, 505×304, plus 860
OPTIONSpreflights.Why 304 does not help much
The endpoint sends an
ETagbut noCache-Control(verified against production):A conditional request does return 304 with an empty body, so bandwidth is saved. Server time is not: the response has to be built in full before the ETag can be compared. With no
Cache-Control, the browser revalidates on every use, so almost every call reaches the application.Where the calls come from
Not from
DFXswiss/services— a search acrosssrcfinds no request to this route, so the call originates in the API client package rather than in screen code. Which callers trigger it, and how often per session, is not established here.Scope
Server-side cost of a single call is addressed separately (caching the assembled response in the API). This issue is about the call frequency itself.