## 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.

Cache Storage in UI

Is it popular? As of September 2025  it has 23 millions downloads per week. Which is huge compared to other mature components libraries, like antd(2M) or mui(1,5M).

Let’s try understand why it popular.

## What Design Prinicples are used in Radix UI?

- Headless: components itself does not contain any styles included. Radix UI components can be styled with whatever styling approach you will select: tailwind-css, css-in-j or pure css. It is important when you do not want to grapple with the default styles overrides.

- Uncontrolled: components are maintaining internal state, which allows developers focusing on features, they need to deliver, instead of managing core components state. If there is a need to controll componnts state, you can do it with props.

- Composable: multiple components are defined as “compound components”, which allows customize components and compose the UI you need. This is a goto pattern for complex components opposed to monolithic components. Another unique feature of Radix UI components is “asChild” property of component. You can turn your add behaviour of Radix UI component to the child component:

```javascript
import * as React from "react";
import { Tooltip } from "radix-ui";

export default () => (
	<Tooltip.Root>
		<Tooltip.Trigger asChild>
			<a href="https://www.radix-ui.com/">Radix UI</a>
		</Tooltip.Trigger>
		<Tooltip.Portal>…</Tooltip.Portal>
	</Tooltip.Root>
);
```

- Modular components: you can use package with all components exposed or you can adopt Radix UI component by component without bloating your bundle size.

```javascript
npm install @radix-ui/react-dialog
```

## Characteristics of Radix UI

- Headless: no default sttyles.

- Strong Accesibility Support: designed with the accesibility in mind for you to have WCAG compliant web app.

- Granular Components Composition: web app can adopt component by component, having multiple component libraries in place. composable also on low level assigning behaviour to your components with composition.

- Fully Typed: Built with typescript.

- ES Modules: Exported as Ecma Script Modules enabling tree shaking OOTB with modern bundlers.

- Ecosystem: Has ecosystem with prebuilt design systems (Radix Themes), colors (Radix Colors) and icons library (Radix Icons). Radix UI is a library that backs up shadcn UI library, which is also very popular in react community. Vercel implemented v0 (app vibe coding app) using shadcn.

## Personal Feeling

I’ve tried Radix UI briefly for a cople of evenings. And started rigth from the radix-theme package. It is a package with preconfigured styles (which I was able override only with inlince CSS). Learning curve is steeper than Tailwind CSS. Component API is consistant and contains util types like in tailwind (`mt=”4”`). But it is a subset of tailwind alternative props. Any customization is either limited or not documented. Adding custom font, custom background was a challenge to me. I was forced to reach out GPT. 

## Summary

UI community values are represented by a downloads count of Radix UI, which shows trend to customizable low level primitives with built in accesibility.

On the other hand it has steeper learning curve,  documentation and components count has room for improvement.  

Together with compatibility with modern tooling and good DX - Radix UI still gains popularity, leaving mature prestyled libraries behind. 



Why Radix UI Is So Popular?

Radix UI: A Modern Headless Component Library (LLM-Research)

Session state is a concept in the software applications to share a user-specific data across multiple actions or requests during a single user session. User session can contain:

- User authentication information

- User preferences

- Form data, navigation history, shopping cart contents or any other application state, that user do not want to lose

- Temporary data

- Security tokens

## **Client Session State**

It is a practice to store session to the browser cookies or localStorage.

- ✅ Reducer server load. Do not need to share the data between the requests. Reduces memory footprint.

- ✅ Scalability. When server is stateless you can scale it horizontally.

- ✅ Simplified Session management. Frontend developer controls session timeouts and session data.

- ❌ Security risk. Sensitive data may be expose to the XSS attacks. Sensitive daa must be encrypted.

- ❌ Data integrity. User can modify session data. All data and server requests must be validated.

- ❌ Cross device usage. Session data is available only per one device. You can sync session data across devices, but it comes with a cost.

- ❌ Privacy issues. Regulations such as GDPR require explicit consent from user. It adds additional complexity and impacts the user experience.

## **Server Session State**

It is a practice to store session on the server side.

- ✅ Security. Sensitive data is kept on the server, which is harder for an attacker to manipulate data.

- ✅ Data Integrity. Server can validate and manage data without relying on untrusted client.

- ✅ When session is kept in memory, it is fast to resolve and update the session. Also you do not need to serialize and deserialize the session data, if you are keeping it in memory.

- ❌ Scalability. If you want to scale the server in case of high load, this can cost more, than to scale a stateless server. More complex scalability patterns must be applied depending on where session data is kept.

- ❌ If session is kept in memory, that Availability becomes very important. If server is down, user will lose his session.

## **Database Session State**

- ✅ Persistance. The user session data will survive server crashes and restarts.

- ✅ Scalability. It allows data to be stored and accessed in centralized manner. This is beneficial for a scaled instances of the same application.

- ✅ Security. Databases can provide out of the box features for encryption, access control and audit trails.

- ✅ Data Integrity. Data is managed centralized.

- ❌ Performance overhead . Retrieving data from the database costs more, that from the in memory object.

- ❌ Increased complexity. Maintain session data in the database, requires additional database configuration, connection management and abstractions resolving this data.

- ❌ Dependency. Database becomes a critical dependency for an application to operate. Database is made a SPOF (Single Point of Failure). Database performance becomes critical for an system availability.

Session State

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

The challenge of rendering HTML markup has been present since the inception of the web. This problem is solved by a multiple patterns mostly on the server side. Such patterns as Template View, Two Step View and Transform View are described in the Martin Fowler's book (2002) Patterns of Enterprise Application Architecture. Depending on the complexity of UI and the domain model Martin suggests different patterns. All these patterns work with [MVC] (https://www.buzzchart.info/post/model-view-controller) very well.

What I found peculiar, in the pattern Transform View, that it has very similar principals to all modern component base web frameworks.

This is the quote from a book:

> Using Transform View means thinking of this as a transformation where you have the model's data as input and its HTML as output.

In comparison to React, the Transform View concept can be reimagined as using React to transform model data into JSX output.

The React has broader and more abstract definition. It's main concept to have a UI as a composition of small components, that can be reused. This paradigm empowered by JSX creates flexible and system of defining and reusing components.

Transform View pattern is focused on the Domain model rendering. In this case class method, that corresponds to the Domain model entity or attribute knows how to create HTML. Back in the 2002, when the book was written, to solve this problem another "language" was used called XSLT, which stands for Extensible Stylesheet Language Transformations. XSLT is a language, XML based, which allows you to define transformations. XSLT supports elements like if, else, for, choose template, choose stylesheet.

In Transform View pattern you will combine your transformations defined XSLT and render those to the HTML.

I am comparing here XSLT and JSX. XSLT can include another XSLT, which provides nesting capabilities. But defining components together with the JavaScript code in the JSX and reusing components in the JSX, was the reason React has such a widespread adoption. I think that Developer Experience DX, dictates what technology is used in the long run. Despite being an appropriate choice at the time, XSLT was eventually sidelined because of its cumbersome XML syntax and lack of development tooling.

Transform View

Model View Controller is a well known pattern, which was described in the late 1970s. Since then, it is widespread architectural pattern, which influenced many frameworks and applications. For example in Java's well known framework [Spring](https://spring.io/guides/gs/serving-web-content) has element which is called **`@Controller`**, which represents a group of endpoints to handle input. Laravel is a PHP framework which is based on the MVC architecture.

MVC implies separation of concerns, where each element is responsible for a specific role.

**Model** - Model is responsible for managing data, business logic, business rules. Commonly used pattern, Domain Model, perfectly fits into MVC. Model is represented in the user interface(UI). UI in MVC is View.

**View** - View is responsible only for a rendering of a model. It can be a single template or by UI framework (library) rendered HTML. In MVC UI layer must not contain business logic, routing, orchestration, database querying. Only rendering the model representation. All these concerns are handled by a Controller element.

**Controller** - Controller accepts input, queries domain model object from a Model, calls services(notifications, logging, mutates data, queries other data sources). Prepares model for the UI, gets the View element. Combines View with the Model and returns HTML to the user.

Separation of an application code to different elements, has multiple benefits:

- each element can be tested in isolation, without a big effort. You can test your Model and View as a pure function. Model can be a complex component, with thousands of business rules and interrelated domain entities logic. Defining and testing those can become challenging. If you will add another layer of complexity, testing it in the presentation layer, you will lose the ability to test or to maintain tests.

- The concerns are fundamentally different. In enterprise applications, separate roles of employees are developing separate layers. For example business analysts will define the domain and business rules. UI developer will develop UI components/views to render a model. Backend developer will manage input to the controller.

- Having separate View from Model layers provides a possibility to implement different representations for different user groups. For example front office with customers, and back office with the employees working on a product, will have different representation of the Model and different application capabilities.

Since the 1970 pendulum swings from the server rendered application to the client rendered application (SPA, single page application), back and forth. MVC is not always applicable, though it even not always can be applied. This architectural pattern must be used to maintain application complexity. If the application is very small and there is no plans to grow this application, the MVC is a complexity itself, that needs to be managed. The majority of the internet is simple representational pages, created with Wordpress on PHP with a help of UI style utils/components like bootstrap and wordpress PHP plugins. On the other side enterprise application with a terabytes of data and millions of users with myriads of roles/privileges/use cases which you (as a developer/architect) need to handle.

MVC is about the separation of concerns, this means that you need to work hard to enforce it. Enforcing the separation can become challenging. On one hand you have requirements for complex interface, where developer wants to include the domain logic in the representation. On another hand you have a requirement to isolate business/domain logic from the representation. Which is possible, but it can become difficult, if incorrect abstraction is used. This separation can fail if:

- there is not architectural governance in the development process.

- developer will chose the environment, which is know for him. If he needs to switch tools/programming languages/repositories, most likely he will avoid it and mix the concerns.

- tools provided for developers are flexible enough to mix concerns. React with JSX, as an example, is the most powerful templating language for HTML (comparing to mustache, pug or others).

- time constraints are dictating the technical decision.

- current architecture does not support (or the complexity is too high to implement in other environment/tool/place) the required feature to be implemented in the Controller or Model.

Model View Controller MVC

In the book Patterns of _Enterprise Application Architecture by Martin Fowler_ two patterns are defined to handle business logic in the system. I do not think that much have changed since then. The IT industry evolved, but these patterns are still applicable to this day. I will unpack what those patterns mean and how they are applicable now.

**Domain model** is a pattern where object representing the model also contains the behavior and/or business rules in itself.

- ✔️ data together with the behavior

- ✔️ easy to extend

- ✔️ easy to comprehend / observe if applied correctly

- ❌ requires more effort and experience to implement

- ❌ may be overhead for a simple domain

**Transaction script** is a pattern where a separate script/object/function/service loads the data validates/modifies it and saves to the database.

- ✔️ requires less effort and experience to implement

- ✔️ fits simple domain applications

- ❌ anemic model, which is considered as an anti-pattern by a Martin Fowler

- ❌ hard to maintain / extend / observe on a more complex domain

Both of these patterns are pretty abstract and can be applied today with other architectural and design patterns. Each of those has pros and cons. You can use these pattern in your server side rendered UI MVC application with, react server components, PHP or Java server pages.

## **Difference**

The difference between those patterns is complexity. Complexity of implementation, extensions and support. Domain model can harder to implement initially. But it reduces the complexity, when the model is evolving, getting more complex. Keeping business logic in one place with the domain reduces the complexity of extension and refactoring. On the other hand transaction script separates data from the behavior. At the start it is easier to model you data and write a transaction script to handle business rules. But this approach will not scale, with the size of your model and the domain complexity.

## **Challenges**

At the time _Martin Fowler wrote the book Patterns of Enterprise Application Architecture_ was written, the standard UI architecture was HTML rendered on server with a small amount of interactivity sprinkled by javascript. All logic could be handled by both patterns on the server. Mostly it is MVC pattern for a web server with a input controller acting as a mediator. Today the expectations of the UI/UX have changed. UI is way more interactive - UI applications handles routing, validation, data initialization and manipulation, UI flow management, security and whats not. Previously UI was not responsible for all those things. This is why implementing business logic in the maintainable manner is crucial for a modern UI application. Domain model is one of the options, which must be considered. If you will leave the majority of these concerns on the server, then UI will request those. Multiple requests will degrade the responsiveness of an application.

## **Examples**

For example consider case when you need to validate the 1mb json data. You have thousands of business rules, which must be evaluated, to ensure the data is valid. During the data gathering process you will make thousands REST API calls to the server to validate the data, to provide instant feedback on entered values. If you will choose to make validation once per tab/dropdown/card/step, then user will have a bunch of errors after he completed the step. This can be a tradeoff of keeping the logic on the backend and requesting this logic from the server.

- using transaction script you will end up with thousands of functions, with duplicated logic between those and the code which is hard to comprehend.

- using the domain model pattern your business rules will be "managed" together with the model. Rules will be kept with the domain which matches the Single responsibility principle.

Domain Model vs Transaction Scripts

- Page based decomposition - each microservice has ts own dedicated page. This pattern enables vertical slice of an application. ✔️ You can deploy your UI and backend for a vertical slice of an application independently from other microservices. ❌ Has limited capabilities creating complex UI.

- Widget based decomposition - each widget can communicate only with it's own microservice. ✔️ You can deploy your UI and backend for a vertical slice of an application independently from other microservices. ❌ Adds complexity in managing communication between widgets.

- Central Aggregating gateway - gateway (with transformation, filtering, aggregation) as a single entrypoint to the microservices. Good fit when you have a separate UI teams and microservices teams. Creates horizontal layers of an application (n-tier architecture). ✔️ Simplifies UI development. ❌ Creates coupling on the gateway side.

- Backend For Frontend (aka BFF) - same as CAG per client type. This pattern fits, when you have multiple client types (web, ios, android, 3rd party API). ✔️ It solves the general purpose API problem and enables teams to develop independently. ❌ It creates coupling on the gateway layer, and introduces code duplication.

_patterns by Sam Newman from the book Microservices 2nd edition_