Improve your Angular app performance by using this simple Observable cache decorator

Tue, 29 Sep 2026 10:53:16 +0000

When we were about to finish development of our applications in SwiftViews we noticed a pattern in all our data-fetching user flows. In spite of the fact that the apps are all data-driven and looked really dynamic, what really was changing in the same user session wasn’t that much, but we were making http requests for new content regardless.
The easiest solution was caching
Caching where? On the server? We already have that, but this doesn’t stop all our apps hitting our services and thus — increasing the load on them.
Maybe we could use service worker since it allows caching API calls?
Yes, that was one of the options since it already has a pretty nice integration with Angular and allowed for a simple solution to selectively cache resources and APIs. However, what we wanted is to be able to not only choose what to cache, but also when to do it.
Just to give you a quick example — we basically wanted to cache all API call results for the page below, but only if we were certain that the data source did not change in some way.

Since this is my personal inventory page, the only way it can actually change is if I add an item from this platform (currently the only way to do so), so I have the information about when this page will change and how long I can return cached content for.
We figured the best way to apply this caching in a selective and configurable way will be to use what the platform already gives us
Since we are using Angular and Typescript ❤️, and all our data calls go through RxJs, we figured that we can create a Cache Observable decorator, which we’d use to only give the caching power to certain methods.
So, before, this was our method which called our server to get the products on the page above:

and that became:

Notice that the @Cacheable() has been applied just to the method we wanted and was also passed cacheBusterObserver which is basically our Subject-based mechanism to tell this exact decorated method to relieve all its caches, when any value is emitted in that stream.
For example, the method below will “cache-bust” the caches of the method above, if the Observable it returns emits a value

This might be the most complex example we have but we also have other configurations implemented like maxCacheCount, maxAge, slidingExpiration and custom cache deciders and resolvers which give us a fine-grain control on what, when and how to cache. See those in the README file.
In the two gifs below, you can see the difference between our app’s performance without and with caching.

https://www.loom.com/share/71a03e4cd478407fa53f131fc112e09a
No Cacheable
The cacheable decorator is not applied yet, so every page load will actually fetch data from the server

https://www.loom.com/share/380a1fa93a9c42d0a5adaa987cd51efb
Cacheable decorator applied
The cacheable decorator is applied and we can see that all consecutive page loads are faster. Also the user profile page loads instantly, because we have already called the /user/{id}endpoint on the inventory page. Also, the cache busts after we add a new item so our user gets fresh data
So, to sum up, this simple decorator allowed us to:
Selectively cache observable methods (not just endpoints, but maybe also computation-heavy calculations in streams)
Improve the performance of our app, without any business logic refactoring (thanks TS decorators ❤️)
Greatly reduce the load on our servers
If you want to use this decorator in your project, just install it from NPM!
npm install ngx-cacheable
If you have any questions about it or want to contribute, don’t mind opening a pull request @github or commenting below.
Also, if you liked the application, please register and build your own inventory @ swiftviews.
Thank you!

Deep Dive: Solving Race Conditions and Concurrency with RxJS Operators

Tue, 25 Nov 2025 05:39:27 +0000

Race conditions are the nightmares of frontend development. They happen when your code assumes that network request A will finish before network request B, but the internet decides otherwise.

In React or Vue (without RxJS), managing complex concurrency often requires boolean flags (isLoading), timestamp checks, or AbortControllers.

In Angular, we solve this elegantly with RxJS Mapping Operators.

But RxJS gives us four different tools: mergeMap, switchMap, concatMap, and exhaustMap. Choosing the wrong one isn't just a style choice; it determines whether your app creates bugs or prevents them.

Let's break down exactly which concurrency strategy each operator uses.

1. `switchMap`: The "Latest and Greatest" (Fixing Read Races)

The Strategy: Cancel the previous request if a new one arrives.

The Scenario:
Imagine a user is on a "User Details" page.

They click "User A". (Request A starts - Slow Network).
They get bored and click "User B" immediately. (Request B starts - Fast Network).

The Bug (without switchMap):
Request B finishes first and shows User B. Then, Request A finishes and overwrites the screen with User A. The URL says "User B", but the screen shows "User A". This is a dirty UI state.

The Fix:

this.route.params.pipe(
  // When params change, cancel any pending request!
  switchMap(params => this.userService.getUser(params.id))
).subscribe(user => {
  // We are GUARANTEED that 'user' matches the current URL.
  this.displayUser(user);
});

Best For: GET requests (Search, Route Params, Filters).

2. `concatMap`: The "Single File Line" (Fixing Write Races)

The Strategy: Wait for the current request to finish before starting the next.

The Scenario:
An "Auto-Save" feature in a text editor.

User types "Hello". (Request A sent).
User immediately types " World". (Request B sent).

The Bug (with switchMap):
If you used switchMap, Request B would cancel Request A. The server only receives " World". The word "Hello" is lost forever.

The Fix:
We need a Queue. Request B must wait in line.

this.textInput.valueChanges.pipe(
  // Queue the requests. Request B waits for Request A to complete.
  concatMap(text => this.api.saveDraft(text))
).subscribe();

Best For: PUT/POST requests where order matters (Auto-saves, sequential steps).

3. `mergeMap`: The "Free-for-All" (Parallel Execution)

The Strategy: Run everything immediately. I don't care about order.

The Scenario:
A "Bulk Delete" feature. The user selects 5 items from a list and clicks "Delete Selected".

The Strategy:
We don't want to wait for Item 1 to delete before starting Item 2 (too slow). And we certainly don't want to cancel Item 1 if Item 2 starts (bug). We want them all to fly to the server at once.

The Fix:

const idsToDelete = [1, 2, 3, 4, 5];

from(idsToDelete).pipe(
  // Fire 5 network requests in parallel
  mergeMap(id => this.api.deleteItem(id))
).subscribe(deletedId => {
  console.log(`Deleted ${deletedId}`);
});

Best For: DELETE requests or fetching unrelated data (e.g., getting Widget A and Widget B at the same time).

4. `exhaustMap`: The "Do Not Disturb" (Spam Prevention)

The Strategy: Ignore new requests while I am busy.

The Scenario:
A "Pay Now" button or a Login form.
A nervous user clicks the button 10 times in one second because the spinner didn't appear instantly.

The Bug (with mergeMap):
You charge the user's credit card 10 times.

The Bug (with switchMap):
You cancel the payment 9 times, and only the 10th one works (maybe).

The Fix:
We want to completely ignore clicks 2 through 10.

fromEvent(this.payButton, 'click').pipe(
  // If a payment is processing, IGNORE this click.
  exhaustMap(() => this.paymentService.chargeCard())
).subscribe();

Best For: Non-idempotent POST requests (Login, Payment, Submit).

Summary Cheat Sheet

Operator	Concurrency Strategy	Ideal Use Case
switchMap	Kill the previous	Reads (Search, Routing)
concatMap	Wait in line	Ordered Writes (Save)
mergeMap	Run in parallel	Parallel Writes (Delete)
exhaustMap	Ignore the new	Submit Buttons (Auth)

RxJS operators are tools for managing time. Master these four, and you master concurrency.

Coder Legion - Recent posts tagged rxjs

Improve your Angular app performance by using this simple Observable cache decorator

Deep Dive: Solving Race Conditions and Concurrency with RxJS Operators

1. switchMap: The "Latest and Greatest" (Fixing Read Races)

2. concatMap: The "Single File Line" (Fixing Write Races)

3. mergeMap: The "Free-for-All" (Parallel Execution)

4. exhaustMap: The "Do Not Disturb" (Spam Prevention)

Summary Cheat Sheet

1. `switchMap`: The "Latest and Greatest" (Fixing Read Races)

2. `concatMap`: The "Single File Line" (Fixing Write Races)

3. `mergeMap`: The "Free-for-All" (Parallel Execution)

4. `exhaustMap`: The "Do Not Disturb" (Spam Prevention)