Interceptors for request modification in Angular - Deep Dive

Overview - Interceptors for request modification

What is it?

Interceptors in Angular are special pieces of code that sit between your app and the server. They can look at and change outgoing requests before they go out, or incoming responses before your app uses them. This helps you add things like security tokens or logging without changing every request manually.

Why it matters

Without interceptors, you would have to add the same code to modify every request or handle every response, which is repetitive and error-prone. Interceptors let you centralize this logic, making your app easier to maintain and more secure. They also help handle errors or add headers automatically, improving user experience and developer productivity.

Where it fits

Before learning interceptors, you should understand Angular services and HTTP client basics. After mastering interceptors, you can explore advanced topics like error handling strategies, authentication flows, and custom HTTP handlers.

Mental Model

Core Idea

An interceptor is like a security guard who checks and modifies every outgoing and incoming message between your app and the server.

Think of it like...

Imagine sending letters through a mailroom where a clerk stamps each letter with a return address or checks for forbidden content before sending it out. Interceptors act like that clerk for your app's network messages.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Angular App   │──────▶│ Interceptor   │──────▶│ Server        │
└───────────────┘       └───────────────┘       └───────────────┘
       ▲                      │                        ▲
       │                      ▼                        │
       └───────────────── Response ─────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is an Angular Interceptor

Concept: Interceptors are classes that implement a specific interface to catch HTTP requests and responses.

In Angular, an interceptor is a class that implements the HttpInterceptor interface. It has a method called intercept that receives the outgoing request and a handler to continue the request chain. You can modify the request or response here.

Result

You get a single place to modify or inspect all HTTP requests and responses.

Understanding that interceptors act as middleware for HTTP calls helps you see how to centralize request logic.

2

Foundation

Basic Interceptor Setup

Concept: How to create and register a simple interceptor in Angular.

Create a class implementing HttpInterceptor with an intercept method. Register it in the providers array with multi: true to add it to the chain. For example, add a console log for every request.

Result

Every HTTP request logs a message automatically without changing the calling code.

Knowing how to register interceptors properly ensures they run for all HTTP calls.

3

Intermediate

Modifying Outgoing Requests

🤔Before reading on: Do you think interceptors can change the request URL or headers? Commit to your answer.

Concept: Interceptors can clone and modify requests to add headers or change URLs before sending.

Requests are immutable, so you clone them with changes. For example, add an Authorization header with a token before forwarding the request.

Result

All requests automatically include the token header, improving security without manual changes everywhere.

Understanding immutability and cloning requests prevents bugs and enables safe modifications.

4

Intermediate

Handling Incoming Responses

🤔Before reading on: Can interceptors modify the response body or only inspect it? Commit to your answer.

Concept: Interceptors can inspect and transform responses before they reach your app code.

Use the RxJS pipe and map operators on the response observable to change data or handle errors globally.

Result

You can format data or catch errors in one place, reducing repetitive code in components.

Knowing that interceptors work with observables lets you handle asynchronous data streams elegantly.

5

Intermediate

Chaining Multiple Interceptors

🤔Before reading on: Do interceptors run in the order they are provided or randomly? Commit to your answer.

Concept: Multiple interceptors run in the order they are registered, each passing the request/response to the next.

Register interceptors in providers with multi: true. The first interceptor modifies the request, then passes it on. Responses flow back through the chain in reverse order.

Result

You can separate concerns like logging, authentication, and error handling cleanly.

Understanding the chain order helps avoid conflicts and design clear interceptor responsibilities.

6

Advanced

Using Interceptors for Authentication

🤔Before reading on: Should token refresh logic be inside an interceptor or a service? Commit to your answer.

Concept: Interceptors can add tokens and handle token expiration by triggering refresh flows.

Intercept requests to add tokens. On 401 errors, pause the request, refresh the token via a service, then retry the original request with the new token.

Result

Users stay logged in seamlessly without manual refresh or repeated login prompts.

Knowing how to coordinate interceptors with services for async token refresh avoids common authentication bugs.

7

Expert

Performance and Side Effects in Interceptors

🤔Before reading on: Can heavy logic in interceptors slow down all HTTP calls? Commit to your answer.

Concept: Interceptors run on every HTTP call, so inefficient code or side effects can degrade app performance.

Avoid blocking operations or heavy computations inside interceptors. Use lightweight logic and delegate complex tasks to services. Also, be careful with retry loops to prevent infinite requests.

Result

Your app remains responsive and stable even with multiple interceptors active.

Understanding interceptor performance impact helps build scalable and maintainable apps.

Under the Hood

Angular's HttpClient sends requests through a chain of interceptors before reaching the backend. Each interceptor receives an immutable HttpRequest object and a handler to pass control. Interceptors clone and modify requests, then forward them. Responses flow back through the chain in reverse order as observables, allowing interceptors to transform or handle them asynchronously.

Why designed this way?

This design follows the middleware pattern common in web frameworks, enabling modular, reusable request logic. Immutability ensures safe concurrent operations and predictable behavior. The observable pattern fits Angular's reactive programming style, allowing asynchronous and cancellable operations.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ HttpClient    │──────▶│ Interceptor 1 │──────▶│ Interceptor 2 │
└───────────────┘       └───────────────┘       └───────────────┘
       │                      │                        │
       ▼                      ▼                        ▼
    Backend <─────────────────────────────────────────────
       ▲                      ▲                        ▲
       └───────── Response flows back through chain ─────┘

Myth Busters - 4 Common Misconceptions

Quick: Do interceptors modify the original HttpRequest object directly? Commit to yes or no.

Common Belief: Interceptors can change the original HttpRequest object directly.

Reality: HttpRequest objects are immutable; interceptors must clone and modify copies.

Why it matters: Trying to modify the original request causes runtime errors and unexpected behavior.

Quick: Do interceptors run only on outgoing requests or also on incoming responses? Commit to your answer.

Common Belief: Interceptors only affect outgoing requests, not incoming responses.

Reality: Interceptors can inspect and modify both requests and responses.

Why it matters: Missing response handling in interceptors leads to duplicated error handling code.

Quick: If multiple interceptors are registered, do they run in parallel or in sequence? Commit to your answer.

Common Belief: Multiple interceptors run in parallel and independently.

Reality: Interceptors run sequentially in the order they are provided, forming a chain.

Why it matters: Misunderstanding order can cause bugs when interceptors depend on each other's modifications.

Quick: Can interceptors cause infinite loops if not careful? Commit to yes or no.

Common Belief: Interceptors cannot cause infinite loops because they only modify requests once.

Reality: If an interceptor retries requests without limits, it can cause infinite loops.

Why it matters: Infinite loops can crash the app or overload the server.

Expert Zone

1

Interceptors share the same instance across the app, so avoid storing per-request state inside them.

2

The order of interceptors affects both request and response flow, so carefully plan registration order for predictable behavior.

3

Interceptors can short-circuit requests by not calling next.handle(), useful for caching or blocking unauthorized calls.

When NOT to use

Avoid using interceptors for complex business logic or UI state changes; use services or state management instead. For non-HTTP tasks, interceptors are not suitable. Also, if you need fine-grained control per request, manual modification might be better.

Production Patterns

Common patterns include adding authentication tokens, global error handling with user notifications, logging request timing for performance, and retrying failed requests with exponential backoff.

Connections

Middleware in Web Servers

Interceptors are Angular's version of middleware that process requests and responses in sequence.

Understanding middleware in backend frameworks helps grasp how interceptors chain and modify HTTP traffic.

Reactive Programming with Observables

Interceptors use RxJS observables to handle asynchronous request and response streams.

Knowing observables clarifies how interceptors transform data and handle async flows elegantly.

Assembly Line in Manufacturing

Interceptors act like stations on an assembly line, each adding or checking something before the product moves on.

Seeing interceptors as sequential processing steps helps design clear, modular request handling.

Common Pitfalls

#1 Trying to modify the original HttpRequest directly inside an interceptor.

Wrong approach:

intercept(req: HttpRequest, next: HttpHandler) {
req.headers.set('Authorization', 'token');
return next.handle(req);
}

Correct approach:

intercept(req: HttpRequest, next: HttpHandler) {
const cloned = req.clone({ headers: req.headers.set('Authorization', 'token') });
return next.handle(cloned);
}

Root cause:

HttpRequest objects are immutable; direct modification is not allowed.

#2 Not registering the interceptor with multi: true, causing only one interceptor to work.

Wrong approach:

providers: [{ provide: HTTP_INTERCEPTORS, useClass: MyInterceptor }]

Correct approach:

providers: [{ provide: HTTP_INTERCEPTORS, useClass: MyInterceptor, multi: true }]

Root cause:

Angular requires multi: true to allow multiple interceptors in the provider array.

#3 Performing heavy synchronous work inside interceptors, blocking requests.

Wrong approach:

intercept(req, next) {
while(true) {} // infinite loop or heavy blocking
return next.handle(req);
}

Correct approach:

intercept(req, next) {
// lightweight logic only
return next.handle(req);
}

Root cause:

Interceptors run on every HTTP call; blocking code slows down the entire app.

Key Takeaways

Angular interceptors let you modify and handle all HTTP requests and responses in one place.

Requests are immutable; always clone them to make changes inside interceptors.

Interceptors run in the order they are registered, forming a chain for requests and responses.

Use interceptors for cross-cutting concerns like authentication, logging, and error handling.

Be mindful of performance and avoid heavy or blocking code inside interceptors.