Auth, retry, logging: three interceptors, zero classes

Interceptors used to be the most ceremony-per-feature API in Angular: a class, an interface, a multi-provider registration with HTTP_INTERCEPTORS and multi: true — the line everyone copy-pasted and nobody could write from memory. The functional version is just... a function, registered in order:

provideHttpClient(
  withInterceptors([authInterceptor, retryInterceptor, loggingInterceptor]),
)

Here are the three I end up writing on basically every project, with the details that distinguish "works in the demo" from "works in production".

Auth: clone, don't mutate — and let some requests through

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  if (req.context.get(SKIP_AUTH)) return next(req);

  const token = inject(TokenStore).token();
  if (!token) return next(req);

  return next(req.clone({
    setHeaders: { Authorization: `Bearer ${token}` },
  }));
};

Requests are immutable, so it's clone() or nothing. The part worth copying is the first line: SKIP_AUTH is an HttpContextToken, and it solves the "but the login call itself shouldn't carry a token" problem without the URL-matching if-chains that grow hair over time:

export const SKIP_AUTH = new HttpContextToken<boolean>(() => false);

// at the call site that needs the exception:
this.http.post('/auth/login', creds, {
  context: new HttpContext().set(SKIP_AUTH, true),
});

The exception is declared where the exception is, not in a growing denylist inside the interceptor. Six months later, that's the difference between reading one line and archaeology.

Retry: the interceptor that can double-charge someone

export const retryInterceptor: HttpInterceptorFn = (req, next) => {
  if (req.method !== 'GET') return next(req);

  return next(req).pipe(
    retry({
      count: 2,
      delay: (error, retryCount) => {
        const status = error instanceof HttpErrorResponse ? error.status : 0;
        if (status > 0 && status < 500) throw error; // 4xx: our fault, don't retry
        return timer(1000 * Math.pow(2, retryCount)); // 2s, 4s
      },
    }),
  );
};

Two guards carry all the weight. Only GETs: a POST that times out may have succeeded server-side — retry it and you've created the duplicate order / double payment incident that ends up with your name on the postmortem. Only 5xx and network errors: retrying a 401 or a 404 is asking the same question louder. With those two rules, automatic retry goes from scary to boring — and a flaky corporate proxy mostly disappears from your error tracker.

Logging: only the requests that deserve it

export const loggingInterceptor: HttpInterceptorFn = (req, next) => {
  const started = performance.now();
  return next(req).pipe(
    finalize(() => {
      const ms = performance.now() - started;
      if (ms > 1000) {
        console.warn(`[slow] ${req.method} ${req.urlWithParams} — ${Math.round(ms)}ms`);
      }
    }),
  );
};

Logging every request is noise nobody reads. Logging requests over a threshold gives you something I've found disproportionately useful: the slow-endpoint report assembles itself in the console while you develop, and the worst offenders become impossible to not know about.

Order is not a detail

The array order is execution order on the way out, reversed on the way back. With [auth, retry, logging]: auth runs first, so every retry attempt carries the token — flip them and a token refresh between attempts can send a stale header. And because logging sits innermost, it times each attempt rather than the sum. When an interceptor chain misbehaves, the order is the first thing I check, and it's the thing the type system can't check for you: the array compiles in any order. It just doesn't work in any order.