Ionic Angular HttpClient concurrent GET request deduplication

Question

Ionic Angular applications using HttpClient do not include a built-in mechanism to deduplicate identical in-flight GET requests. When multiple components trigger the same request within a short window, each request is sent independently to the server.

The framework level provides no default caching or request coalescing, so deduplication must be considered at the application configuration layer, typically via an interceptor or external library. The decision boundary is unclear regarding whether deduplication should be global, module scoped, or opt-in per request, and what permission constraints should apply to cache keys and response reuse.

Documentation does not specify a planned default behavior for automatic request deduplication in future Ionic releases, leaving the choice to project teams.

Should request deduplication be treated as a framework-provided configuration option or remain an application-level concern? What permission boundary should govern which requests are eligible for coalescing? Is there a documented stance on default deduplication behavior for Ionic Angular HttpClient?

Tasadduq Burney · Answer

Answer

Request deduplication should remain an application‑level concern; Ionic Angular does not provide a built‑in or planned automatic coalescing of identical GET requests.

Likely explanation

Angular’s HttpClient treats each http.get() call as an independent observable. Ionic adds no extra HTTP layer, so without extra code every caller gets its own network transaction. The framework documentation presents caching/coalescing as a pattern you implement yourself with an interceptor, and there is no statement about a future default.

Confirmed facts

Angular HttpClient (and thus Ionic Angular) issues one request per subscription unless the observable is shared.
The Angular HTTP transfer cache (withHttpTransferCacheOptions) is for SSR hydration replay, not runtime deduplication.
Community libraries (e.g., @ngneat/cashew) provide deduplication via interceptors, confirming that the pattern lives in user code.

Permission boundary for coalescing

Only idempotent GETs may be deduplicated. The cache key must include everything that can change the response:

HTTP method (GET)
Full URL with query string
Response type (responseType)
Headers that affect semantics – primarily Authorization, Accept‑Language, Range, and any custom headers that the server uses to vary the response.

Never coalesce requests that differ in authenticated user identity or that could return non‑idempotent data.

Steps to implement an opt‑in deduplication interceptor

Create a token for opt‑in:

import { HttpContextToken } from '@angular/common/http';
export const DEDUP = new HttpContextToken(() => false);

In the interceptor, keep a Map<string, Observable<HttpEvent<unknown>>> keyed by a string that concatenates method, URL, responseType, and the relevant headers.
For each request, if req.context.get(DEDUP) is true and a matching entry exists, return the stored observable (using share() so late subscribers get a fresh request after completion).
Otherwise, start the request, store the observable, and use finalize to delete the entry when the observable completes or errors.
Provide the interceptor in the root module (or a feature module) with HTTP_INTERCEPTORS or the functional withInterceptors API, depending on your Angular version.

Missing diagnostic detail

To know whether to use the class‑based HttpInterceptor provider or the functional HttpInterceptorFn with withInterceptors, please confirm the major Angular version used in your project (e.g., Angular 14 vs 17).