This post isn’t about caching _strategies_ like cache-aside or cache-through.

It’s about storage — where can I keep my cache in the browser, and what trade-offs come with each option?

Why does this matter?

Because where you store the cache affects your app’s architecture, performance, and security. If you’re designing a new system, this choice can even shape how your frontend interacts with the backend.

---

## Cache Storage Characteristics

To make the options easier to compare, let’s define key characteristics as questions:

- **Persistence** — Can the data survive page reloads or browser restarts?

- **Sync vs. async** — Does the API return values directly or via `Promise`?

- **Capacity** — How much data can we store before hitting limits?

- **Security** — How exposed is the data to JavaScript or potential attacks?

- **Shared across tabs** — Can multiple tabs see the same cache?

- **Isolated per tab** — Is each tab sandboxed with its own cache?

- **Performance** — How fast are reads and writes under normal load?

- **API accessibility** — From where in the runtime can the API be used?

- **Offline availability** — Is the data available without a network connection?

---

## Cache Storage Options

### In-Memory Cache

The simplest option is an in-memory cache — data stored in a JavaScript `Map` (or `WeakMap`) that will be empty when the tab reloads.

You can store any structure — objects, classes, arrays — and you can control expiration manually.

Check out example:

```javascript
class MemoryCache {
  constructor({ ttlMs = 60_000 } = {}) {
    this.ttlMs = ttlMs;
    this.map = new Map();
  }
  _now() { return Date.now(); }

  set(key, value, ttl = this.ttlMs) {
    this.map.set(key, { value, expiresAt: ttl ? this._now() + ttl : null });
  }

  get(key) {
    const e = this.map.get(key);
    if (!e) return;
    if (e.expiresAt && e.expiresAt < this._now()) {
      this.map.delete(key);
      return;
    }
    return e.value;
  }

  has(k) { return this.get(k) !== undefined; }
  delete(k) { this.map.delete(k); }
  clear() { this.map.clear(); }
}

// Example
const cache = new MemoryCache({ ttlMs: 5 * 60_000 });
cache.set('user:123', { id: 123, name: 'Ada' });
console.log(cache.get('user:123')); // { id: 123, name: 'Ada' }
```

---

### In-Memory Cache in a Web Worker

This is similar to the previous approach but runs inside a Web Worker, which isolates cache memory from the main thread.

It’s like a locked drawer managed by an assistant — main scripts can’t access directly inside; they have to ask via messages.

However, this isn’t full protection against XSS. If an attacker can run JavaScript in your page, they can still message the worker and steal data unless you authenticate requests.

```javascript
// cache.worker.js
const cache = new MemoryCache();
self.onmessage = ({ data }) => {
  const { id, op, key, value, ttl, opts } = data;
  if (op === 'init') Object.assign(cache, new MemoryCache(opts));

  let result;
  switch (op) {
    case 'set': cache.set(key, value, ttl); result = true; break;
    case 'get': result = cache.get(key); break;
    case 'has': result = cache.has(key); break;
    case 'delete': cache.delete(key); result = true; break;
    case 'clear': cache.clear(); result = true; break;
    default: result = null;
  }

  postMessage({ id, result });
};
```

```javascript
// main thread
const worker = new Worker(new URL('./cache.worker.js', import.meta.url), { type: 'module' });
let nextId = 1;
const pending = new Map();

worker.onmessage = e => {
  const { id, result } = e.data || {};
  if (!pending.has(id)) return;
  pending.get(id).resolve(result);
  pending.delete(id);
};

function call(op, data = {}) {
  return new Promise(resolve => {
    const id = nextId++;
    pending.set(id, { resolve });
    worker.postMessage({ id, op, ...data });
  });
}

// Example
await call('init', { opts: { ttlMs: 5 * 60_000 } });
await call('set', { key: 'user:123', value: { id: 123, name: 'Ada' } });
console.log(await call('get', { key: 'user:123' })); // { id: 123, name: 'Ada' }
```

---

### In-Memory Cache in a Shared Worker

A Shared Worker extends the Web Worker idea by allowing multiple tabs (from the same origin) to share one worker and its memory.

It’s like a hallway locker that several rooms can access asynchronously.

> Shared Workers are not supported in all browsers. Consider BroadcastChannel or Service Workers as fallbacks.

```javascript
// shared-worker.js
const cache = new MemoryCache();

onconnect = event => {
  const port = event.ports[0];
  port.start();

  port.onmessage = ({ data }) => {
    const { op, key, value, ttl, opts } = data;
    let result;

    switch (op) {
      case 'init': Object.assign(cache, new MemoryCache(opts)); result = true; break;
      case 'set': cache.set(key, value, ttl); result = true; break;
      case 'get': result = cache.get(key); break;
      case 'has': result = cache.has(key); break;
      case 'delete': cache.delete(key); result = true; break;
      case 'clear': cache.clear(); result = true; break;
      default: result = null;
    }

    port.postMessage(result);
  };
};
```

```javascript
// main thread (any tab)
const worker = new SharedWorker(new URL('./cache.shared.js', import.meta.url), { type: 'module' });
const port = worker.port;
port.start();

function call(op, data = {}) {
  return new Promise(resolve => {
    port.onmessage = e => resolve(e.data);
    port.postMessage({ op, ...data });
  });
}

// Example usage
await call('init', { opts: { ttlMs: 5 * 60_000 } });
await call('set', { key: 'user:123', value: { id: 123, name: 'Ada' } });
console.log(await call('get', { key: 'user:123' })); // { id: 123, name: 'Ada' }
```

---

### Local Storage

Local Storage is like a sticky-note pad — small, simple, and persistent between reloads, but visible to any script on the same site.

- **Data limit:** ~5–10 MB (varies by browser).

- **Keys/values:** strings only.

- **Scope:** per origin (not shared between different sites).

- **Security:** accessible by any script on the same origin. Never store secrets here.

```javascript
class LocalStorageCache {
  constructor({ prefix = 'cache:', ttlMs = 60_000 } = {}) {
    this.prefix = prefix;
    this.ttlMs = ttlMs;
  }

  _now() { return Date.now(); }
  _key(key) { return this.prefix + key; }

  set(key, value, ttl = this.ttlMs) {
    const expiresAt = ttl ? this._now() + ttl : null; // null = no expiry
    const record = { value, expiresAt };
    localStorage.setItem(this._key(key), JSON.stringify(record));
  }

  get(key) {
    const raw = localStorage.getItem(this._key(key));
    if (!raw) return;
    try {
      const record = JSON.parse(raw);
      if (record.expiresAt != null && record.expiresAt < this._now()) {
        localStorage.removeItem(this._key(key));
        return;
      }
      return record.value;
    } catch {
      localStorage.removeItem(this._key(key)); // corrupted entry
    }
  }

  has(key) { return this.get(key) !== undefined; }
  delete(key) { localStorage.removeItem(this._key(key)); }

  clear() {
    for (let i = localStorage.length - 1; i >= 0; i--) {
      const k = localStorage.key(i);
      if (k && k.startsWith(this.prefix)) localStorage.removeItem(k);
    }
  }
}
```

Use this for low-volume, non-sensitive, global data such as user preferences.

---

### Session Storage

Session Storage works like Local Storage but with two key differences:

- Data is wiped when the tab or browser closes (short-lived).

- Each tab gets its own isolated copy.

It’s good for temporary data (form state, navigation cache) but still vulnerable to XSS.

---

### Cache API

The Cache API is a persistent, async key–value store designed for HTTP requests and responses.

Think of it as a pantry for packaged goods — great for caching network assets, but not ideal for arbitrary data.

- **Persistence:** On disk; survives reloads and restarts.

- **API shape:** Promise-based. Works with `Request` and `Response` objects.

- **Capacity:** Large, browser-managed (may evict under pressure).

- **Security:** Same-origin; avoid storing secrets in plain text.

- **Shared across tabs:** Yes, per origin.

- **Best for:** Offline assets, prefetching, API response caching.

```javascript
// Minimal Cache API wrapper with stale-while-revalidate
async function cacheFetch(request, { cacheName = 'app-v1', revalidate = true } = {}) {
  const cache = await caches.open(cacheName);
  const req = typeof request === 'string' ? new Request(request) : request;

  const cached = await cache.match(req);
  if (cached) {
    if (revalidate) {
      fetch(req)
        .then(res => { if (res.ok) cache.put(req, res.clone()); })
        .catch(() => {});
    }
    return cached.clone();
  }

  const res = await fetch(req);
  if (res.ok) await cache.put(req, res.clone());
  return res;
}

// Usage
const res = await cacheFetch('/api/users/1');
const data = await res.json();
console.log(data);
```

Further reading: [MDN Cache API](https://developer.mozilla.org/docs/Web/API/Cache)

---

### IndexedDB

**I**ndexedDB is the browser’s built-in NoSQL database — powerful, persistent, and async.

Imagine a warehouse with labeled shelves — slower to reach but can hold huge, organized collections.

- Persistence: On disk; survives reloads and restarts.

- API shape: Promise-based (with wrappers).

- Capacity: Tens to hundreds of MBs, depending on browser and user settings.

- Security: Same-origin; still accessible to any same-origin script.

- Shared across tabs: Yes.

- Use cases: Large datasets, offline apps, queues, sync replicas.

```javascript
// idb.js — minimal helper
function openDB(name, version, upgrade) {
  return new Promise((resolve, reject) => {
    const req = indexedDB.open(name, version);
    req.onupgradeneeded = e => upgrade(req.result, e.oldVersion, e.newVersion);
    req.onsuccess = () => resolve(req.result);
    req.onerror = () => reject(req.error);
  });
}

function tx(db, store, mode, fn) {
  return new Promise((resolve, reject) => {
    const t = db.transaction(store, mode);
    const s = t.objectStore(store);
    const request = fn(s);
    request.onsuccess = () => resolve(request.result);
    request.onerror = () => reject(request.error);
  });
}

// One-time setup
const db = await openDB('app-db', 1, db => {
  if (!db.objectStoreNames.contains('users')) {
    const s = db.createObjectStore('users', { keyPath: 'id' });
    s.createIndex('by_name', 'name');
  }
});

// Put and get
await tx(db, 'users', 'readwrite', s => s.put({ id: 1, name: 'Ada' }));
const user = await tx(db, 'users', 'readonly', s => s.get(1));
console.log(user);
```

---

## Browser Cache Options — Comparison Table

| **Characteristic**       | **In-Memory (Tab)** | **Web Worker**     | **Shared Worker**         | **Session Storage** | **Local Storage** | **Cache API**    | **IndexedDB**      |
| ------------------------ | ------------------- | ------------------ | ------------------------- | ------------------- | ----------------- | ---------------- | ------------------ |
| **Persistence**          | ❌                   | ❌                  | ❌                         | ❌                   | ✅                 | ✅                | ✅                  |
| **API Sync?**            | ✅                   | ❌                  | ❌                         | ✅                   | ✅                 | ❌                | ❌                  |
| **Shared Across Tabs**   | ❌                   | ❌                  | ✅                         | ❌                   | ✅ (per origin)    | ✅                | ✅                  |
| **Capacity**             | RAM-bound           | RAM-bound          | RAM-bound                 | Small               | ~5–10 MB          | Medium/Large     | Large              |
| **Relative Speed**       | ★★★                 | ★★★                | ★★                        | ★★                  | ★★                | ★★               | ★                  |
| **Security Notes**       | Origin JS access    | Needs API auth     | Needs API auth            | Same                | Same              | Avoid secrets    | Avoid secrets      |
| **Offline Availability** | ❌                   | ❌                  | ❌                         | ❌                   | ✅                 | ✅                | ✅                  |
| **Best For**             | Hot ephemeral data  | Isolated hot cache | Multi-tab ephemeral cache | Per-tab temp data   | Small settings    | HTTP/asset cache | Complex/large data |

---

## Choosing the Right One

- Just need fast temporary lookups in one tab? → In-memory.

- Want isolation from the main thread? → Web Worker.

- Need multi-tab sharing? → Shared Worker or `BroadcastChannel`.

- Small, non-sensitive persistent data? → Local Storage.

- Short-lived tab data? → Session Storage.

- Cache fetch responses or assets offline? → Cache API.

- Need structured, large, or relational data offline? → IndexedDB.



Each browser storage mechanism is a trade-off between speed, persistence, and isolation.

Think of them as layers:

- RAM caches (fast, temporary)

- Web/Shared Workers (isolated, async, optional sharing)

- Web Storage (Local/Session) (simple, limited)

- Cache API (network-oriented, persistent)

- IndexedDB (structured, large-scale persistence)

Choose the one that matches your data lifetime and security model, not just convenience.

Cache Storage in UI

Module federation is a webpack 5 features. It allows independent deployments for you different applications. Same as [HTML import map](https://www.buzzchart.info/post/html-import-map)? Yes but it allows more flexible configuration and reuse not only JavaScript files.

## **What Module federation can do?**

- Can share individual JS modules together with it's dependencies. You can share a react component together with styles and static data.

- Can share any module, that webpack supports.

- Can share the whole application as a micro-front-end

- Must share a common libraries like react, react-dom and/or components library

## **Use cases**

- Independent applications deployment

- Independent pages deployment (aka mfe)

- Independent components deployment. To share components library for other "containers" to use.

Webpack Module Federation

How to load JS in the runtime, from a separate server? Browsers provide a native feature called [HTML importmap](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap). It is supported and works across all latest devices and browser versions.

**`importmap`** HTML feature is useful because:



- it allows to load modules by our specified rules and create a declarative configuration in the HTML.

- This configuration cannot be overriden and serves as a source of truth to our modules resolution configuration defined in on place.

- allows different modules to be loaded from the different sources. It enables independent deployment. Because we can specify different modules to be loaded from the different urls.

- when all JavaScript modules are loaded to the same main thread, conflicts can appear. this means, that for some imports we need to have one library resolved, for example **`react`** and **`react-dom`**.

- when we are referencing the same libraries from different modules, we may want to specify different urls to resolve these libraries. For example billing is using **`lodash@13`** and customer is using **`lodash@14`**. These versions are not compatible. To load each version for each module we can use **`scopes`** feature in the **`importmap`**.

## **What is an "importmap"?**

Importmap is a JSON declaration of imports and actual paths to be replaced in the JavaScript. We can declare an importmap as follows:

```html
<script type=importmap>
    {
      "imports": {
        "circle": "https://example.com/modules/circle.js",
      }
    }
</script>
```

With this declaration we can use **`import`** expression in our javascript just referencing **`circle`** as:

```javascript
import circle from 'circle'
```

## **What are the rules using importmap?**

- **`<script type='importmap'>`** must be defined before other scripts. This is the quote from a [HTML spec](https://html.spec.whatwg.org/multipage/webappapis.html#import-map)

> Import maps are currently disallowed once any module loading has started, or once a single import map is loaded. These restrictions might be lifted in future specification revisions.

- no other properties cannot be specified in this script tag. **`src`** property cannot be specified also.

- importmap impact only **`import`** and **`import()`** expressions in the JavaScript

- import map cannot be dinamically modified. Once it is loaded to the browser, it cannot be reloaded in the runtime.

## **Scopes**

Scopes feature allows to resolve different modules depending on the current module, from which the import is resolved. The scoping is achieved by specifying the "scopes" object in the import map, where each key is a scope URL, and its value is an object of import mappings that apply to that scope.

Consider this configuration of imports and scopes:

```json
{
  "imports": {
    "a": "/a-1.mjs",
    "b": "/b-1.mjs",
    "c": "/c-1.mjs"
  },
  "scopes": {
    "/scope2/": {
      "a": "/a-2.mjs"
    },
    "/scope2/scope3/": {
      "b": "/b-3.mjs"
    }
  }
}
```

results in the resolutions of modules:

```bash
"a"         "b"         "c"
/scope1/r.mjs           /a-1.mjs	/b-1.mjs	/c-1.mjs
/scope2/r.mjs	        /a-2.mjs	/b-1.mjs	/c-1.mjs
/scope2/scope3/r.mjs	/a-2.mjs	/b-3.mjs	/c-1.mjs
```

HTML Import Map

## **Overview**

[NPM](https://www.npmjs.com/) stands for Node Package Manager. It is the largest package registry in the world. It contains hundreds of thousands of packages uploaded to it.

NPM uses SemVer by default. It allows only [SemVer](https://www.buzzchart.info/post/semantic-versioning) syntax in the package version declaration. SemVer is very powerful and simple at the same time. NPM packages using SemVer enhanced syntax to declare package dependencies. This concept makes the dependency declaration very powerful and flexible. At the other hand it can be complex to comprehend how dependencies are resolved.

## **Dependency declaration**

NPM package can define dependency as a strict version (**`1.2.3`**) or a range of versions (**`1.2.x`**, which is resolved to **`1.2.0`**, **`1.2.1`**, **`1.2.3`**, **`1.2.4`**). You can define a range for a newest patch versions or newest minor version, [or other crazy definitions are available](https://docs.npmjs.com/about-semantic-versioning). Using a version range definition, you have multiple versions applicable for you your dependencies or transitive dependencies. NPM will resolve a tree of dependencies according to the version declaration in the dependencies and its dependencies. Dependencies are evolving and releasing new versions constantly. Depending on the point in time, different dependencies will be resolved. How to know what dependencies are resolved? How to lock the dependencies and have a reproducible build? **`package-lock.json`** solves this problem.

## **package-lock.json**

**`package-lock.json`** is a file ([npm reference](https://docs.npmjs.com/cli/v10/configuring-npm/package-lock-json)), generated in the root of a workspace/monorepo or in the package root. It contains all information about the used dependencies used in the project. It captures the concrete versions at the time it was created. This allows to:

- have reproducible build

- prevent npm from resolving the tree of dependencies

- understand/introspect what is used in the project and track the evolution of dependencies

## **Same dependency, different version**

Different dependency branches may have different versions. For example one branch using **`lodash@14.16.x`**, other brach uses **`lodash@14.17.x`**. This means that project will contain different versions of the **`lodash`**. This gives lots of flexibility in the dependency management. Because npm solves the compatibility problems and choses the right version for you. It comes with a cost of:

- increased bundle size

- complexity in observing the whole picture of dependencies

- security vulnerabilities might not be fixed withing the defined ranges.

## **Conflicts and overrides**

Conflicts can occur for an incorrect dependency declaration. Consider the case when you need to have one library in the runtime(**`react`** or components library for example). And for some reason you will have 2 libraries in the runtime which will cause discrepancies in the JS or CSS evaluation.

Another reason already mentioned in the previous section. Security vulnerability fix. For example we have a declared version of **`lodash@14.17.20`**. **`lodash@14.17.21`** contains critical security fix, but you have no control over transitive dependency declaration.

The melanism to solve this problem is npm "[overrides](https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides)".

> Overrides provide a way to replace a package in your dependency tree with another version, or another package entirely. These changes can be scoped as specific or as vague as desired.