DEV Community: Adnan Saleem

A React dashboard that keeps up with a WebSocket feed

Adnan Saleem — Fri, 16 Oct 2026 13:00:00 +0000

For a vehicle cybersecurity platform I engineered real-time threat detection dashboards in React and TypeScript on WebSocket feeds, which cut analyst time-to-insight by about 20%. A live dashboard has one job that a normal page does not: it must stay responsive while data keeps arriving, for hours. The feed demo on this site shows the same state handling on a simulated feed.

What goes wrong first

The obvious version works in a demo and falls over in production:

socket.onmessage = (message) => {
  // One render per message, and a list that grows for as long as the tab is open
  setEvents((prev) => [JSON.parse(message.data), ...prev]);
};

It has two faults. Every message triggers a render, so a burst of fifty messages is fifty renders in a row. And the list never stops growing, so memory and render time climb all day until the tab is reloaded.

Render per frame, not per message

The screen updates about sixty times a second, so rendering more often than that is wasted work. Collect incoming messages in a buffer and flush it once per animation frame:

useEffect(() => {
  const socket = new WebSocket(url);
  const buffer = [];
  let frame = 0;

  const flush = () => {
    frame = 0;
    const batch = buffer.splice(0).reverse();              // newest first
    setEvents((prev) => [...batch, ...prev].slice(0, 40)); // keep what the screen can show
  };

  socket.onmessage = (message) => {
    buffer.push(JSON.parse(message.data));
    if (!frame) frame = requestAnimationFrame(flush);      // at most one render per frame
  };

  return () => {
    socket.close();
    cancelAnimationFrame(frame);
  };
}, [url]);

A burst of any size now costs one render. The cleanup function matters as much as the handler: without it, every remount leaves a socket open behind it.

Keep only what the screen can show

An analyst reads the latest few dozen events, not the last ten thousand. Cap the list (the demo keeps 40) and leave history to the server, which can page through it on request.

Aggregate as events arrive

Totals and charts should not be recalculated from the list, because the list is capped and recounting is slow. Update them incrementally:

// Counters grow by one per event; no need to recount the list
setCounts((prev) => ({ ...prev, [event.level]: prev[event.level] + 1 }));

// One bucket per second for the chart: add to the newest, drop the oldest every second
setHistory((prev) => [...prev.slice(0, -1), prev[prev.length - 1] + 1]);
setInterval(() => setHistory((prev) => [...prev.slice(1), 0]), 1000);

The chart then draws thirty numbers, whatever the event rate.

Plan for the connection dropping

Reconnect with backoff. Wait one second, then two, then four, up to a ceiling, so a server restart is not met by every client at once.
Show the state. A dashboard that silently stopped updating is worse than one that says it is reconnecting.
Catch up. After reconnecting, ask the server for what was missed, using the last event id you saw.

Give the user control

Pause. Nobody can read a row that keeps moving. A pause button holds the view while events keep buffering.
Announce politely. Mark the event list with role="log" so screen readers announce new entries without interrupting.
Make severity more than colour. Pair each colour with a word, so the meaning survives for colour-blind users and in print.

How to tell it holds

Raise the event rate well past what production sends and leave the page open. Frame rate should stay steady and memory should level off, not climb. If either drifts, something is still growing without a cap.

Originally published at theadnansaleem.com.

Role-based access control with data redaction in ASP.NET Core

Adnan Saleem — Tue, 13 Oct 2026 13:00:00 +0000

On a vehicle cybersecurity platform I secured sensitive security data with four-tier role-based access control, secure .NET API integrations, and data redaction pipelines filtered by caller tier. The idea underneath is simple and often skipped: deciding who may call an endpoint is only half of access control. The other half is deciding what each caller gets back.

Hiding a field in the UI is not security

If the API returns a field and the frontend chooses not to show it, the field is one browser tool away from anyone who is logged in. Whatever a user must not see has to be removed on the server, before the response is serialized.

Two questions, two mechanisms

May this caller use this endpoint at all? That is authorization, and ASP.NET Core policies answer it.
Which parts of the answer may this caller see? That is redaction, and it needs its own step.

Tiers as policies

Give each user a tier claim at sign-in and express every rule as a named policy. Controllers then state what they need, and the rule itself lives in one place:

// Program.cs: each policy names the lowest tier that passes
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("Tier2", policy => policy.RequireClaim("tier", "2", "3", "4"));
    options.AddPolicy("Tier3", policy => policy.RequireClaim("tier", "3", "4"));
    options.AddPolicy("Tier4", policy => policy.RequireClaim("tier", "4"));
});

One redaction step, used everywhere

The endpoint loads the full record and hands it to a single function that builds the response for the caller's tier:

[Authorize(Policy = "Tier2")]
[HttpGet("findings/{id}")]
public async Task<ActionResult<FindingDto>> Get(Guid id)
{
    var finding = await _findings.Find(id);
    if (finding is null) return NotFound();

    var tier = int.Parse(User.FindFirstValue("tier")!);
    return FindingRedactor.For(tier, finding);
}

public static class FindingRedactor
{
    public static FindingDto For(int tier, Finding f) => new()
    {
        Id = f.Id,
        Title = f.Title,
        Severity = f.Severity,
        // Each sensitive field names the tier that may see it; everyone else gets null
        AffectedComponent = tier >= 3 ? f.AffectedComponent : null,
        ReproductionSteps = tier >= 4 ? f.ReproductionSteps : null,
    };
}

Three properties make this hold up over time. The domain object never leaves the server; only the response object does. Every sensitive field states its own rule, so a reviewer can read the whole policy in one file. And a new field is absent from the response until someone adds it to the redactor, which makes the default safe.

Where data leaks anyway

Lists and search. A redacted detail page is pointless if the list endpoint returns the full record. Send every response for that type through the same redactor.
Exports and reports. CSV and PDF generation often bypasses the API layer. Give them the same step.
Filters and counts. If a low tier can filter by a hidden field, the result count reveals it. Reject filters on fields the caller cannot read.
Errors and logs. A validation message that quotes a hidden value leaks it. Keep sensitive values out of error text.
Real-time channels. A WebSocket that broadcasts full records to every subscriber undoes all of the above. Redact per connection.

Test it as a table

Access rules are a grid of tiers against fields, so test them as one: for every tier, request the same record and assert exactly which fields are present. When someone adds a field, the test for the lowest tier fails until they decide who may see it. That failing test is the review.

Originally published at theadnansaleem.com.

Passing Core Web Vitals in a React app: what moves LCP

Adnan Saleem — Sat, 10 Oct 2026 13:00:00 +0000

On Qatar's national event platforms I brought core pages to Core Web Vitals compliance through memoization, virtualization, lazy loading and code splitting, which improved LCP by about 35% and TTI by about 30%. On a payments platform, dynamic code splitting cut the initial bundle by about 35%. The method is the same every time, and it starts with measuring, not with optimizing.

The three numbers

LCP (Largest Contentful Paint): when the biggest visible element appears. Good is 2.5 seconds or less.
INP (Interaction to Next Paint): how long the page takes to respond to a tap or key press. Good is 200 milliseconds or less.
CLS (Cumulative Layout Shift): how much the page jumps while loading. Good is 0.1 or less.

Google judges these on real visits at the 75th percentile, so a fast laptop on office wifi tells you very little. Test with mobile emulation and a throttled connection.

Find the LCP element first

Lighthouse and the Performance panel in Chrome both name the element that counts as the largest paint. Until you know which one it is, every optimization is a guess. It is usually a hero image or a headline, and the question is always the same: what has to download and run before that one element can appear?

Ship less before the first paint

Most React apps send every screen to every visitor. Code splitting sends a screen only when it is opened:

// Before: the reports screen ships in the first bundle, to every visitor
import Reports from './Reports';

// After: it is downloaded only when someone opens it
const Reports = React.lazy(() => import('./Reports'));

<Suspense fallback={<ScreenSkeleton />}>
  <Reports />
</Suspense>

Split by route first, then split heavy pieces inside a route: charts, editors, maps, export dialogs. Anything below the fold or behind a click is a candidate.

Preload only what the first screen needs

Preloading is a promise that a file is urgent. Break that promise and the urgent files wait behind the others. This site is a small example: every page preloaded seven font files, four of which were used on one page each. Removing those four preloads took the Lighthouse mobile score from between 85 and 88 to 92 and cut the simulated LCP from about 4.1 seconds to 3.4, with no visible change.

Keep interactions cheap

INP suffers when one interaction re-renders too much. Two tools cover most cases. Memoization (React.memo, useMemo) stops components and calculations from repeating when their inputs did not change. Virtualization keeps long lists and tables down to the rows that are on screen.

Stop the page from jumping

Layout shift comes from content that arrives without reserved space: images, embeds, late banners, fonts that swap to a different width. Reserve the space up front:

/* The image box has its final size before the image arrives, so nothing jumps */
.hero-image { aspect-ratio: 16 / 9; width: 100%; }

Measure before and after, the same way

Run the same test three times before a change and three times after. Single runs vary too much to trust.
Change one thing at a time, so you know what worked. I tried deferring hidden images on this site and it measured no gain, so it was dropped.
Lab tools estimate. Real-user data, from the Chrome UX Report or your own analytics, is what Google uses, so confirm there once traffic allows.

Originally published at theadnansaleem.com.

Rendering 20,000 rows in React without freezing the page

Adnan Saleem — Wed, 07 Oct 2026 10:56:49 +0000

On a multi-currency payments platform I optimized large data tables with react-window virtualization and memoization, which cut render time by about 70% on datasets over 20,000 rows. The technique is small enough to write by hand, and writing it once makes the libraries easy to reason about. The code below is the same code that runs in the live demo on this site.

Why a big table is slow

The data is rarely the problem. Twenty thousand objects in memory is nothing. The cost is the DOM: every row is several elements that the browser has to create, style, lay out and paint, and React has to reconcile all of them on every update. A filter keystroke that touches 20,000 rows means 20,000 rows of work, even though the user can see about twelve.

Render only what is visible

Virtualization, also called windowing, keeps the full list in memory and puts only the visible slice in the DOM. With fixed-height rows it is arithmetic on the scroll position:

const ROW = 36;       // row height in px
const VIEW = 432;     // height of the scroll area in px
const OVERSCAN = 6;   // extra rows above and below, so fast scrolling shows no gaps

const first = Math.max(0, Math.floor(scrollTop / ROW) - OVERSCAN);
const last = Math.min(rows.length, Math.ceil((scrollTop + VIEW) / ROW) + OVERSCAN);
const visible = rows.slice(first, last);

Then give the browser an inner element as tall as the whole list, and shift the visible slice down to where it belongs:

const scroller = { height: VIEW, overflow: 'auto' };
const spacer = { height: rows.length * ROW, position: 'relative' };
const slice = { transform: `translateY(${first * ROW}px)` };

<div style={scroller} onScroll={(e) => setScrollTop(e.currentTarget.scrollTop)}>
  {/* Full height, so the scrollbar behaves as if every row were there */}
  <div style={spacer}>
    <div style={slice}>
      {visible.map((row) => <Row key={row.id} row={row} />)}
    </div>
  </div>
</div>

In the demo that turns 20,000 rows of data into roughly two dozen rows in the DOM, whatever the scroll position.

Where memoization fits

Windowing fixes how many rows exist. Memoization fixes how often the survivors re-render. Two places matter:

const Row = React.memo(function Row({ row }) {
  return <div className="row">...</div>;
});

const filtered = useMemo(() => rows.filter(matches(query)), [rows, query]);

The row. Wrapped in React.memo with a stable key, a row that scrolls but does not change is not rendered again.
The derived list. Filtering and sorting 20,000 items on every scroll event is wasted work. useMemo recomputes only when the inputs change.

Memoization only helps if props are stable. An inline object or arrow function passed to every row defeats it.

Measure it

React finishing is not the same as the user seeing the result. To time an update through to paint, wait two animation frames after the state change:

const started = performance.now();
setQuery(next);
requestAnimationFrame(() =>
  requestAnimationFrame(() => console.log(performance.now() - started, 'ms to paint')),
);

Record the number with virtualization off, then on, with the same data and the same action. That before and after is the only claim worth putting in a pull request.

What to watch for

Variable row heights. The arithmetic above needs a fixed height. For rows that grow, use a library that measures them, and expect more complexity.
Find in page. The browser's search cannot see rows that are not in the DOM. Provide your own filter, as the demo does.
Accessibility. Tell assistive technology the real size with aria-rowcount and aria-rowindex, and make the scroll area focusable so it can be scrolled from the keyboard.
Production use. For real products use a maintained library such as react-window. It handles the edge cases; the principle is exactly the one above.

Originally published at theadnansaleem.com.

Migrating a Visual FoxPro system to .NET: an order of work that holds up

Adnan Saleem — Mon, 05 Oct 2026 10:56:45 +0000

Over a two-and-a-half-year engagement I migrated 42 financial workflows from a legacy Visual FoxPro system to C# and .NET Core, as the sole engineer. The old system carried two decades of business logic and had no written specification. The domain layer was rebuilt on Entity Framework Core with 42 T-SQL stored procedures against SQL Server, the FoxPro reports were replaced with reporting workflows in a Blazor application, and the old system was retired. This is the order of work I would recommend to anyone facing the same kind of migration.

Why these migrations are hard

Visual FoxPro mixes data, logic and screens in one place. A form can hold validation, calculations and direct table updates, so there is no layer to lift out. Microsoft ended support for it years ago, which means the people who understand the system are often the only documentation left. The risk is not the new code. The risk is losing a rule that nobody remembers is there.

1. Inventory the workflows, not the files

Start from what the business does: each task a user completes from start to finish, such as posting a payment or closing a period. List them, name an owner for each, and note which screens, tables and reports each one touches. That list becomes the plan and the definition of done. In my case there were 42.

2. Treat the old code as the specification

When there is no written spec, the running system is the spec, including its oddities. For each workflow, read the FoxPro code and write down the rules in plain language, then confirm them with someone who uses the system. Record real inputs and the outputs they produce. Those pairs become the tests that the new system must pass.

3. Move the data model deliberately

FoxPro tables are loosely typed, often without enforced keys. Moving to SQL Server is the moment to add what was missing: primary and foreign keys, proper date and decimal types, and constraints for rules that used to live only in forms. Do not copy the old structure column for column. Redesign it, and write a repeatable script that loads the legacy data into the new shape, so the load can be rehearsed many times before the real cutover.

4. Put the rules in a domain layer

Business rules that were scattered across forms belong in one place in the new system: a domain layer in C# that knows nothing about screens or the database. That is what makes the rules testable, and it is what stops the new system from turning into the old one. Entity Framework Core handles ordinary reads and writes. For heavy set-based work, such as period-end calculations over many rows, a stored procedure is often the clearer and faster tool.

5. Keep data access testable

Hide the database behind a narrow interface, so domain logic can be tested without one and the stored procedures can be tested against a real one. Financial systems reward this more than most: when a number is questioned, you want a test that reproduces it.

6. Leave reports until the data is right

Reports are where users notice differences first, and they depend on everything underneath. Rebuild them after the workflows that feed them, and compare old and new output line by line on the same data. A report that matches is the most convincing evidence that a workflow was migrated correctly.

7. Migrate one workflow at a time, then retire

A single big cutover concentrates all the risk in one weekend. Moving one workflow at a time keeps each step small enough to verify and to reverse. Where you can, run old and new side by side for a period and compare results. Retire the old system only when the inventory from step one is fully ticked off.

What I would tell someone starting

Budget more time for understanding than for coding. The rewrite is the easy half.
Keep a written log of every rule you find and every decision you make. It becomes the specification the old system never had.
Do not improve behaviour while migrating it. Match first, then change, so a difference always means a bug.

Originally published at theadnansaleem.com.

The hard part of micro frontends is the contract, not the bundler

Adnan Saleem — Sun, 27 Sep 2026 08:25:52 +0000

Most Module Federation write-ups stop at the config. You add the plugin, you name a few exposes and remotes, the demo loads a button from another build, and the post ends. That part takes an afternoon.

The part that decides whether this survives contact with several teams is the contract between the shell and the remotes.

What we were splitting

A React frontend for a government events platform, built as one application, released as one unit. Every team waited for the slowest team in the release. Nothing shipped alone.

The goal was not novelty. It was letting teams deploy independently without turning every deploy into a coordination meeting.

Why the config is the easy half

With Module Federation, the shell loads remote modules at runtime. That runtime step is exactly where the guarantees you had at build time disappear.

In a monolith, a mismatch between two parts of the app is a build error. You cannot ship it. After the split, the shell and the remote are built at different times, by different pipelines, possibly weeks apart. A mismatch is no longer a build error. It is a blank panel in production, or a shared library initialised twice, or a hook called against a React copy the shell does not know about.

Nothing in the bundler config prevents that. The config is what makes loading possible. It says nothing about what is safe to load.

The contract

So we made the boundary explicit, and versioned it.

Each remote declares what it exposes and what it expects: the props of the exposed module, the shape of the events it emits, and the range of the shared dependencies it was built against. The shell checks that range before it mounts anything. If a remote sits outside it, the shell refuses it and renders a defined fallback, rather than mounting a component that will throw halfway through a user's session.

Three things this gets you:

Failures move left. A mismatch is caught at load, in one place, with a message naming the remote and the expected range, instead of surfacing as a broken screen a user reports two days later.
Independent deploys become boring. A team ships when their remote satisfies the contract. No release train, no queue.
Shared dependencies stop being folklore. React and the design system are declared as shared with explicit ranges, so "which version is actually loaded" has an answer you can read instead of guess.

The release cycle came down by about 40%. Most of that was not build time. It was the waiting that disappeared.

What I would tell someone starting this

Write the contract before you touch the build config. The config is reversible in an afternoon. A contract that was never written down becomes tribal knowledge, and tribal knowledge is what breaks when someone new ships their first remote.

Decide what happens when a remote fails to load, before it happens. Shell fallback, error boundary, feature flag, take your pick. The default is a blank rectangle, and the default is the one you get if you do not choose.

Keep the shared list short. Every shared dependency is a coupling you have to version. React and the design system, yes. A date library, probably not.

Do not split by page. Split by ownership. The seam should follow the team that maintains the code, because the point of the exercise is independent deploys, not smaller bundles. Smaller bundles are a side effect, and you can get those from code splitting without any of this.

When not to do this

If one team owns the whole frontend, this is overhead with no payoff. You get the coordination cost of a distributed system and keep the release cadence of a monolith. Code splitting and a clean module boundary will serve you better.

Micro frontends solve an organisational problem. If you do not have that problem, the bundler config is not going to give you one worth having.

Originally published at theadnansaleem.com.