julien
c8e2fba13e
Rewrites all 12 frontend ADRs from a custom structure to the MADR 2.1.2 template required by the VS Code ADR Manager extension: bullet metadata (Status/Date), standardised section headings, "Chosen option: X, because Y" wording, and explicit Pros/Cons blocks per option.
1.7 KiB
1.7 KiB
Handle API base URL, auth token, and errors via HTTP interceptors
- Status: accepted
- Date: 2026-04-26
Context and Problem Statement
Every API call requires three cross-cutting concerns: prepending the API base URL, attaching the JWT bearer token, and unwrapping error responses into a consistent shape. How should these be applied across all HTTP calls without duplicating logic in each service?
Considered Options
- Three chained HTTP interceptors
- Per-service base URL and token handling
- Single utility wrapper function
Decision Outcome
Chosen option: "Three chained HTTP interceptors", because they centralise cross-cutting concerns transparently and require no changes to individual services.
Positive Consequences
- Services use relative paths (e.g.
/skydive/jumps) — environment-agnostic. - Auth header injection is transparent to all services.
- Uniform error payload shape across the entire application.
Negative Consequences
- Services must always use relative paths starting with
/. Passing an absolute URL would cause the base URL to be prepended twice.
Pros and Cons of the Options
Three chained HTTP interceptors
- Good, because zero duplication — logic defined once, applied everywhere.
- Good, because services remain unaware of environment or auth details.
- Bad, because interceptors apply globally — opting out requires explicit handling.
Per-service base URL and token handling
- Good, because each service controls its own behaviour explicitly.
- Bad, because duplicates the same logic across every service.
Single utility wrapper function
- Good, because more explicit than interceptors.
- Bad, because all service calls must go through the wrapper — easy to bypass accidentally.