HttpClient Today: Fetch by Default In short: is one of the most stable parts of Angular — the API you learned years ago still works. But what runs underneath changed in v22, and there are two things you will see warnings about. Fetch is now the default (v22) was built on the browser's older request method. v17 added the modern as an option. v22 made it the default and marked the option as going away: now produces a warning. Delete it. Why it matters: Server rendering works properly. The old method does not exist on a server, so Angular had to ship a stand-in. is built into modern Node, so server rendering uses the real thing. Cancelling is standard. uses the browser's standard cancel mechanism, which is what and already give you as . Unsubscribing now actually cancels the request rather than just ignoring the reply. Streaming replies are possible. The old method could not do this cleanly. Smaller. One fewer layer over what the browser already provides. When to keep One case, and it is real: upload progress. can report download progress but not upload progress. If you have a file upload with a progress bar, you need the old method for that request. Progress reporting split in two (v22) The old single setting covered both directions, which no longer works since the two methods differ: needs the old method. Set that up only where you need it — do not switch your whole app to the old method for one screen. Where sits now Chapter 4 introduced , which is built on — same interceptors, same setup. They are layers, not alternatives: — reading data driven by signals: — actions and one-off calls: The rule of thumb: if it is a whose address depends on signals, it is a resource. If a user action triggers it, it is . After a successful change, call on the affected resource: Interceptors — the current shape Interceptors run in list order going out and reverse order coming back. Because they are functions with access to services, they combine with everything else: That line is worth learning by heart. A retry that repeats a can create duplicate records — and it only happens under network trouble, which is exactly when nobody is watching. Reusing server data Requests made while rendering on the server are saved into the HTML and reused, so a server-rendered page does not fetch everything again. This is automatic, and from v22 does it too. To leave a request out — anything personal that should not be baked into HTML a cache might keep: Or set it up once: This is worth checking on any server-rendered app. Saved data ends up in the HTML, and if that HTML is cached somewhere shared, one user's data can be served to another . Changes are left out by default for exactly this reason, but personal requests are not. Testing The old testing module is going away in favour of a function: Order matters — the test version replaces the real one, so it has to come second. This trips people up because the old module had no such rule. The architect's view The layering to be clear about. is built on — same interceptors, same configuration, same backend. They are layers, not competitors, and picking between them per call is a routine decision your team should be able to make without discussion: Shape Tool --- --- Describing — "this data is that URL" Commanding — "go do this now" The one-line test: could this run twice with no harm? A resource re-runs whenever its signals change. That is exactly right for reading and exactly wrong for anything that changes data. Two rules that prevent data damage , and both belong in code review rather than in someone's memory: 1. Never retry anything except and . A retried can create duplicate records — the server may have succeeded while the reply was lost on the way back. This only happens on poor connections, so it survives testing and appears in production. 2. Audit on any server-rendered app. Data fetched during server rendering is embedded in the HTML so the browser does not fetch it twice. That is a genuine performance win and a genuine risk: if that HTML is cached anywhere shared, one user's data can be served to another. Angular excludes by default for this reason. Personal endpoints are not excluded, and you have to say so: This is the kind of thing that is invisible until it is a security incident. Put it on your SSR checklist. On . Fetch cannot report upload progress. That is the single legitimate reason to opt back into the older transport, and it should be scoped to the screen that needs it. Switching the whole application backwards for one file-upload feature trades a real capability — proper request cancellation everywhere — for a progress bar in one place. On migration. The v22 deprecations are all mechanical: delete , split , swap the testing module for . Do them in one pass while the warnings are visible, rather than leaving them to accumulate. Mentoring note. Give juniors the resource-versus-client rule as a single sentence — driven by signals is a resource; anything triggered by a click is…