## Phase 1: UI Dependencies is a Mess

Any UI project can come at this phase if no dependencies strategy present for it. Node dependency resolution algorithm allows having multiple dependencies of the same library in the same application. This is a great flexibulity, but can backfire with increased bundle size for UI applications.  Another issues is security vulnerabilities present in duplicated libraries.  These issues are multiplied if for the same task multiple librariesa re used. 

The biggest risk to most enterprise applications is it’s complexity.
A bloated dependency tree with multiple versions of the same library is a source for unpatched vulnerabilities. You cannot patch a security hole if you don't even know which version of the library is actually running in production.

This diagram outlines the workflow I use to regain control over a chaotic dependency tree, using `lodash` as the classic example.

## Phase 2: Remove Duplications

It is common to find three different versions of `lodash` and a standalone `lodash-debounce` in one project. This inflates bundle size and triples the attack surface.

The Fix:

- **Audit:** Identify the multiple versions of the same library.

- **Dedupe:** Remove duplicated library versions, and use the latest define one. At this step do not use dependency “pinning” features of package managers like pnpm.overrides or yarn.resolutions.

## Phase 3: Unify Library Usage

For the same task we may use multiple libraries. Each library may have transitive dependencies. All this caues load on your CI, performance and increases security attack vector. To fix this need to audit libraries used and group those by the same task. Dedupe libraries in the group and leave one per usage group.  For example `lodash` and  `lodash-debounce` must be deduped and only `lodash` must be left.

## Phase 4: Update Version

At this step we need to find latest “safe” version for the `lodash` library, to get latest bugfixes and security patches. 

## Phase 5: Forbid Adding Other Versions

This is critical step, which will prevent dependency decalrations, degrading to the Phase 1. In order to prevent degrading, we need to setup dependencies whitelist, capturing this state. Pipeline must match used dependencies against the whitelist. The process of adding a new dependency is controlled through the whitelist. You need to add library to the whitelist first, then it can be used. This “proactive” way of adding dependencies allows to evaluate the nescesity for the library, check versions and present vulnerabilities with the complete dependency tree. Oposed to “reactive” approach, when library is added, and then you need to review the impact of new library. 

## Phase 6: Scan Vulnerabilities

Security is a continuous process, not a one-time fix. Integrate vulnerability scanners (Snyk, SonarQube, npm audit) into every pull request. At this step you will reduce the noise-to-signal ratio with a minimal set of dependencies used in the project. Use this data to capture the currect state and report vulnerabilities to the project task tracker system. 

- **Auto-Update:** Use tools like Renovate or Dependabot to automate the patch cycle (4.17.21 → 4.17.22).

## Phase 7: Auto Update

Use tools like Renovate or Dependabot to automate the patch cycle. If you are usign pnpm or npm use command `pnpm audit --fix` to fix your vulnerabilities. At this step pnm may add pinning versions for security reason using pnpm.overrides mechanism. This is a correct usage of this feature of package manager. Integrate updating your dependncies with your CI lifecycle. Merge new dependencies only when Commit Gating succeeded. This approach allows safe and automatic remediation from security vulnerabilities. 

## Conclusion

Projects can become messy when they use many versions of the same libraries, which creates bigger bundles and hidden security issues. Cleaning this up means removing duplicates, picking one library per task, and keeping everything updated. After that, a small allowed-list and regular security checks help keep the dependencies under control.

Securing the UI Supply Chain

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.