DEV Community: Veaceslav

A 40% Faster Fault-Detection Pipeline Without WebSockets — the Polling Trick We Shipped

Veaceslav — Tue, 06 Oct 2026 07:01:21 +0000

title: A 40% Faster Fault-Detection Pipeline Without WebSockets — the Polling Trick We Shipped
published: false
description: Real-time monitoring for 1,000+ network nodes over plain REST — a change-flag endpoint, RTK Query cache discipline, and an operator map that shows the causal chain, not the noise.
tags: react, rtkquery, architecture

This is the dev.to version of a story I first published as a LinkedIn article — restructured for a code-first audience. It's a real production system: real-time monitoring for 1,000+ GSM service stations, built for an international partner. And one honest constraint at its core: we could not touch the backend protocol.

The ticket-queue blind spot

The worst part of a monitoring outage isn't the failure itself. It's not being able to tell the difference between two situations that look identical on a ticket queue:

a node recovered by itself, and
a node is still broken, but nobody noticed yet.

Our network engineers — a field team plus a back office — lived inside that ambiguity for years. The back office created tickets from Grafana data, and a ticket meant wait: someone opened it, someone processed it, and a certain amount of time always passed before the incident became visible to people who could act on it.

The constraint that reframed everything

I checked the obvious answers first: whether the Romanian backend team could support WebSockets or SSE.

They couldn't. The backend was a monolith, and a deep refactor to introduce a new transport protocol was off the table. Not "hard" — off the table. Different project, different budget, different risk.

If the client can't be pushed updates, then maybe it can be woken up cheaply.

The reframe: change the data granularity, not the protocol

My proposal split the information flow into two layers:

1. A cheap change-flag. The backend exposes a tiny flag/version field on an ordinary REST endpoint — a number that increments whenever anything relevant changes underneath. We designed this together: they implemented a small flags feature to my spec, I tracked it from the frontend.

2. A heavy data pull. The actual node states — statuses, incidents, telemetry the dashboard renders.

The frontend polls only the flag on a light interval. When the flag hasn't changed, the request costs nothing meaningful. When it has — RTK Query re-fetches the heavy data and its cache is immediately invalidated and repopulated. The dashboard behaves as if it were pushed to, while under the hood everything is still plain REST.

That's the whole trick:

naive polling:            [timer] → pull full payload → render   (every N seconds, always)
flag-driven polling:      [timer] → pull 1 number  ─┬─ unchanged → nothing
                                                    └─ changed   → invalidate → pull full payload → render

The RTK Query side: cache and refetch discipline

Two things came out of the RTK Query migration itself:

Caching. Identical requests were served from cache instead of re-hitting the API — removing redundant traffic the legacy thunk-based store generated on its own.
Refetch discipline. Refetches happened on demand — flag changed, cache invalidated, window refocused — not on a dumb interval burning everyone's patience and the backend's CPU.

The polling setup in practice:

// poll the flag only — light interval, e.g. 5s
const flag = usePollChangeFlag(intervalMs = 5000)

// the heavy query is keyed on the flag value:
// flag moves → new cache key → automatic refetch + repopulate
const nodes = useGetNodesQuery({ version: flag.version })

The exact API shape was refactored a few times since — the pattern is the deliverable, not the signature. The heavy-fetch key follows the flag; refetch happens when and only when the flag moves.

Showing pain, not data: the map

Raw node counts are useless to a human operator. 1,000+ stations on one screen is noise.

The stations had real topology: parent–child hierarchy. A parent going down didn't just break itself — it degraded its children. So we drew the map differently:

the map shows only the affected subtree, not the whole network;
when a parent fails, its dependent children light up as potentially damaged;
in a typical impact window the map displayed around 400 nodes — the ones potentially hurt through connectivity — instead of 1,000+.

An engineer opens the map and sees a causal chain, not a cloud of dots. And the back office, which had been hand-writing tickets out of Grafana, now pulled the incident structure — parent, children, order of failure — from a single source.

The numbers

We validated the improvement with two existing instruments: Grafana metrics and the ticket system itself (opening-to-resolution timestamps, across the before/after periods).

Result: incident detection time improved by ~40%.

Being precise about what the number means — never defend a fuzzy metric in an interview: the clock we shortened is "failure happens → failure is actionable" — previously dominated by ticket latency, now dominated by flag-poll latency. Nodes that self-recovered no longer polluted the queue and no longer hid the ones that didn't.

If you can't change the protocol, change the granularity

You don't always need WebSockets. You need the cheapest possible signal that something changed — a version number, a hash, an etag — and a client disciplined enough to pull the real payload only when that signal moves. Pair it with cache-first architecture (RTK Query, React Query — whatever your stack provides) so heavy data is fetched rarely and reused often.

And when you present it to a human operator: don't show them the network. Show them the pain — the affected subtree, the causal chain. A map of 400 hurting nodes is worth more than a map of 1,000 quiet ones.

Built with React, TypeScript, RTK Query — and with backend partners who were straightforward about what the system could and couldn't give us.

I write about React patterns and the engineering behind my AI tooling — building in public on Telegram, the LinkedIn version of this story is here.

How do you do "real-time" when the protocol won't budge — flag-polling, SSE workarounds, or plain polling? Curious what others landed on.

Stop prompting for valid JSON: an LLM output layer that does not break

Veaceslav — Tue, 29 Sep 2026 08:45:52 +0000

I'm building JobCopilot: a small Python agent that reads a job description, compares it to my resume, and tells me what skills I'm missing. Like a skeptical recruiter in a terminal.

I want the agent's brain to be an LLM call. But my program needs an answer in a defined shape — like a form with three fields — not a wall of prose. And there's the problem.

The problem in one picture

I asked the model: return only raw JSON, no explanation.

It agreed politely. Then it sent:

Sure! Here's the breakdown in raw JSON:

{
  "verdict": "partial",
  "match_score": 68,
  "missing_skills": ["FastAPI", "Alemdic"]
}

See it? The JSON is wrapped in a hello + a code fence (the JSON-fence block). Python's json.loads() says there's no JSON there at all — it sees the words "Sure! Here's..." and dies. If I ask the model again, it does the same thing slightly differently. You can write "I really mean it this time!!!" in the prompt. It does not help. I tried for an hour.

And when the model does send clean JSON one night, there are three more ways it betrays you:

Wrong key names — it sends skills_missing today and missing_skills tomorrow. Your code searched for one of them.
Wrong types — the score arrives as 87.5, or even 105, when your program expects an integer up to 100.
Correct format, wrong content — {"verdict": "no", "missing_skills": []}: shape is perfect, logic is nonsense.

"A prompt is a suggestion. Only code is a contract." So instead of fighting the prompt, I built a small validation layer — a wall between the model and my program. Whatever comes out of the model, my program either receives a valid form or a precise error report. Here it is, in four steps any beginner can follow.

Step 1: Unwrap the JSON (8 lines of Python)

The model keeps wrapping JSON in JSON-fence fences no matter what I write in the prompt. Fine — let the code unwrap it:

import json
import re

# match (.*?) between ```
{% endraw %}
 pairs, WITH newlines — that's DOTALL
_FENCE_RE = re.compile(r"
{% raw %}
```(?:json)?\s*(.*?)\s*```

", re.DOTALL)


def extract_json(raw: str) -> dict:
    """Takes the model's raw output. Returns clean JSON data."""
    try:
        return json.loads(raw)      # best case: it was already clean JSON
    except json.JSONDecodeError:
        pass                        # no? look for the fence below...

    match = _FENCE_RE.search(raw)
    if match is None:
        raise ValueError(f"no JSON found in: {raw[:200]}")

    loaded = json.loads(match.group(1))
    if not isinstance(loaded, dict):
        raise ValueError(f"expected a JSON object, got {type(loaded).__name__}")
    return loaded

This function tries the honest path first (json.loads(raw)), and if the text has chatty greetings, it grabs whatever sits between the triple-backtick marks and parses THAT.

Three small details that each cost me an evening of confusion:

re.DOTALL — without it, the dot in my regex stops at the first line break, and the fenced JSON spans many lines. My first version matched nothing, silently.
(?:json)? — the model writes the language hint or a bare triple-backtick fence. This part makes the hint optional, so both work.
search, not fullmatch — because there's prose around the JSON: "Sure!", intro sentences, sometimes a closing joke.

One bonus detail I did not know: in Python, JSONDecodeError is a subclass of ValueError. That means except ValueError catches both — I'll use this in Step 3.

Step 2: Check the form field by field (pydantic)

The JSON parses now. But parsing is not validating: {"match_score": 105} parses perfectly fine. So the next layer checks the shape of the data field by field:


python
from typing import Literal
from pydantic import BaseModel, Field, field_validator, model_validator


class JobMatch(BaseModel):
    verdict: Literal["strong", "partial", "no"]   # ONLY these three values
    match_score: int = Field(ge=0, le=100)         # int, 0..100, nothing else
    missing_skills: list[str]                      # a list of strings

    @field_validator("missing_skills")
    @classmethod
    def clean_skills(cls, skills):
        # model sent ["React", "react", "  CSS ", ""] once. Clean it:
        seen = set()
        out = []
        for s in skills:
            key = s.strip().lower()
            if not key or key in seen:
                continue
            seen.add(key)
            out.append(s.strip())
        return out

    @model_validator(mode="after")
    def skeptical_check(self):
        # "no" verdict with empty list = the model gave up
        if self.verdict == "no" and not self.missing_skills:
            raise ValueError("verdict 'no' but no missing skills — model gave up")
        return self

Read this as a form with three fields, each field guarded:

The verdict must be exactly "strong", "partial" or "no" — the model once answered "maybe"; with Literal that becomes impossible.
The score must be an integer between 0 and 100. The model sent 105 once. Now that is impossible too.
The skills list gets cleaned: duplicated "React" and "react" collapse into one, empty strings are dropped.
The final check catches nonsense logic: if the verdict says "no match" but lists zero missing skills, the model gave up instead of analyzing.

When a value breaks a rule, pydantic produces an error that is specific:


text
match_score: Input should be a valid integer, got a number with a fractional
             part [type=int_from_float, input_value=87.5]
verdict:     Input should be 'strong', 'partial' or 'no'
             [type=literal_error, input_value='maybe']

Notice we threw out about thirty lines of handwritten if "verdict" not in data: ... code. The declarative model does the same job, and the errors are not "value error" mush — they name the field, the problem and the offending value.

One honest limit: this layer guarantees the shape, not the truth. It will not catch "Alemdic" — a misspelling of Alembic that is perfectly well-formed JSON. Catching wrong-but-valid content is the job of an eval set, and that is the next article in this series.

Step 3: Return an error as a result, not a crash

Now the top layer. My rule: the model can fail, and the program must handle that failure like any other value. If a function raises an exception, the caller has to catch it — and if the caller forgets, the whole program dies. If a function returns the error, the caller just decides what to do.

If you write TypeScript, you know zod.safeParse() — it returns a result object with a status. We can build the same in Python with two dataclasses:


python
from dataclasses import dataclass


@dataclass
class ParseOk:
    match: JobMatch                       # valid data


@dataclass
class ParseError:
    stage: str      # "json" — couldn't extract, or "schema" — invalid
    message: str    # exact reason, for me AND for the next LLM call


def parse_match(raw: str) -> ParseOk | ParseError:
    try:
        data = extract_json(raw)          # step 1
    except ValueError as exc:             # JSONDecodeError IS a ValueError
        return ParseError(stage="json", message=str(exc))

    try:
        return ParseOk(match=JobMatch.model_validate(data))   # step 2
    except ValidationError as exc:
        return ParseError(stage="schema", message=str(exc))

The type ParseOk | ParseError works like a union type from TypeScript: every result is definitely one or the other, and the caller checks with isinstance(result, ParseOk).

Step 4: The retry — give the exact error back to the model

There is one more trick with ParseError.message. The model can repair itself if you tell it exactly what failed. "It failed" teaches nothing. But:

match_score: Input should be a valid integer, got a number with a fractional part [type=int_from_float, input_value=87.5]

...the model fixes almost every time. So the retry loop feeds the exact pydantic error back into the next call:


python
FIX_PROMPT = """Below was your previous output and the validation error.
Return corrected JSON only.

Previous output:
{previous}

Validation error:
{error}"""


def structured_match(chat, jd_text: str, max_retries: int = 2):
    prompt = MATCH_PROMPT.format(job=jd_text)

    result = None
    for attempt in range(1 + max_retries):
        raw = chat(prompt)
        result = parse_match(raw)
        if isinstance(result, ParseOk):
            return result
        prompt = FIX_PROMPT.format(previous=raw, error=result.message)

    return result   # after max retries: ParseError as data — never None

Retry at most twice, then give up — but give up as a result, not a crash. The caller decides: log it, message the user, or end the run.

(A quick note about frameworks: many LLM providers have native JSON mode. If yours does, use it — it kills most fence problems at the root. But keep the pydantic layer anyway: native mode guarantees shape, not logic, and match_score <= 100 survives on every provider.)

The whole picture

Four small pieces, each doing one job:

Unwrap the code fence — extract_json
Validate field by field — the JobMatch pydantic model
Convert errors into typed data — ParseOk / ParseError
Retry with the exact error fed back — structured_match

In one sentence: code, not the prompt, decides when the model's output is good.

Two things I took from building it:

A prompt is a suggestion; a pydantic model is a contract.
"Errors as data" sounds fancy but is 15 lines: two dataclasses and an isinstance.

Next Tuesday, part 2: retrieval — embeddings with fastembed, cosine similarity computed by hand with numpy, and why my top-8 retrieval stopped discriminating on a resume of 20 chunks.

Follow if you want to see the rest of the copilot get built — including the parts that will break. Build log + daily code: t.me/novamind_hub.

How do you harden LLM JSON in your projects — native JSON mode, validators, or retries? I'm still collecting failure modes.

Stop bloating your AGENTS.md: reference your conventions instead of pasting them

Veaceslav — Tue, 22 Sep 2026 17:28:35 +0000

Stop bloating your AGENTS.md: reference your conventions instead of pasting them

Most AGENTS.md files I see are bloated walls of text. Here is the problem: your agent reads this file at the start of every task. Everything you put in there is passed to the LLM with every prompt. A 400-line AGENTS.md burns context tokens on every single action — even when the agent only needs one rule from it.

The fix is simple: keep AGENTS.md as a thin index, move the details into separate docs, and reference them.

What it looks like in practice

Here is the real AGENTS.md from my current project (invoice management SPA):

# AGENTS.md

## Project
IOD Invoice — invoice management SPA.
React 18 + TypeScript + Vite, Ant Design 6, Redux Toolkit (RTK Query),
styled-components, i18next (EN/RO), OIDC/Keycloak auth.

## Commands (npm; Node 18+)
- `npm run dev` — dev server
- `npm run build` — tsc + production build
- `npm run test` — vitest watch; `npm run test:ci` — run + coverage
- `npm run lint` — eslint, zero warnings tolerated

## Architecture
See `docs/architecture.md`

## TypeScript Conventions
See `docs/typescript-conventions.md`

## Style
See `docs/style-conventions.md`

## React Components
See `docs/react-components.md`

And in docs/ live the actual conventions — architecture decisions, TypeScript rules, styling rules, component patterns.

The agent loads the index plus only the docs it actually needs for the current task. A TypeScript task? It reads one conventions file, not your entire wiki. That is the whole trick: your conventions stay detailed, your context stays clean.

One gotcha: the CLAUDE.md twin problem

Many of us run more than one agent. Claude Code reads CLAUDE.md, everything else reads AGENTS.md — and the two files slowly drift apart until each agent works from different rules.

The fix is a symlink, so both names point at one file:

macOS / Linux:

ln -s AGENTS.md CLAUDE.md

Windows (order is reversed):

mklink CLAUDE.md AGENTS.md

Edit one file, both agents see the update. No drift, no duplicated maintenance.

Bonus: monorepos want nested AGENTS.md files

In a monorepo, put an AGENTS.md in each subfolder:

app/
├── AGENTS.md          # shared rules
├── client/
│   └── AGENTS.md      # frontend-specific rules
└── backend/
    └── AGENTS.md      # backend-specific rules

Working inside client/, the agent loads both — the root file and the subfolder file. Shared conventions live once, stack-specific rules live next to the code they govern.

The takeaway

Your AGENTS.md is not documentation — it is a context budget. Every line in it is paid on every task. Index + references keeps the rules detailed and the context cheap.

If this was useful:

👉 More React + AI tips daily in my Telegram channel: t.me/novamind_hub

I'm building NovaMind — an AI assistant in Telegram that debugs errors from screenshots (the reason my AGENTS.md files matter so much): t.me/mindrorgebot_bot — 30 messages/day free.

Building with coding agents? Drop your biggest AGENTS.md pain in the comments — curious which conventions you enforce first 👇

Handling Dynamic Role Names in Different Environments with useRoleManagement Hook (Part 2)

Veaceslav — Mon, 02 Sep 2024 07:13:46 +0000

In the first part of this series, we explored the foundation of implementing role-based access control in React using the useRoleManagement hook. If you haven't read it yet, you can check it out here
Implementing Role-Based Access Control in React: A Deep Dive into useRoleManagement Hook.

In this second part, we'll dive deeper into managing dynamic role names depending on different environments, such as staging and production. This is crucial for maintaining consistent and secure role management across various stages of development.

Overview

When developing applications, it's common to have different role names or permissions configurations for various environments. For instance, you might use test or mock role names in development and real, production-ready role names in the production environment. Handling these dynamic role names correctly ensures that your application behaves consistently and securely across different stages of its lifecycle.

Environment-Specific Role Configuration

To manage role names dynamically, we can leverage environment variables. These variables allow us to define different role keys for different environments, which can then be used to load the appropriate permissions configuration.

Here’s how we can achieve this:

1. Define Environment Variables

In your .env.development and .env.production files, specify the role keys for each environment. For example:

.env.development

VITE_ROLE_KEYS_MANAGER=Manager_Test
VITE_ROLE_KEYS_USER=USER_Test
VITE_ROLE_KEYS_ADMIN=Admin_Test

.env.production

VITE_ROLE_KEYS_MANAGER=Prod_Manager
VITE_ROLE_KEYS_USER=Prod_USER
VITE_ROLE_KEYS_ADMIN=Prod_Admin

This setup ensures that your application uses appropriate role names depending on the environment it’s running in.

2. Update the permissions Object

Use these environment variables to define the permissions object dynamically. The permissions object maps role keys to specific permissions for each role:

const permissions: Record<string, UserPermissions> = {
  [import.meta.env.VITE_ROLE_KEYS_MANAGER]: {
    partners: { add: false, view: false, edit: false, deleteRow: true },
    // ... other permissions
  },
  [import.meta.env.VITE_ROLE_KEYS_USER]: {
    partners: { add: false, view: false, edit: false, deleteRow: false },
    // ... other permissions
  },

  [import.meta.env.VITE_ROLE_KEYS_ADMIN]: {
    partners: { add: true, view: true, edit: true, deleteRow: true },
    // ... other permissions
  },
};

The import.meta.env syntax allows you to access environment variables defined in your .env files.

3. Use the useRoleManagement Hook

In the first part of this series, we explored the foundation of role-based access control in React using the useRoleManagement hook. If you haven't read it yet, you can check it out here.

The useRoleManagement hook extracts user roles from the decoded JWT token, maps them to permissions using the environment-specific role keys, and then returns the relevant permissions:

export function useRoleManagement() {
  const { pathname } = useLocation();

  const token = localStorage.getItem('token');

  let decodedToken: Realm | null = null;

  try {
    if (token) {
      decodedToken = jwtDecode<Realm>(token);
    }
  } catch (error) {
    console.error('Invalid token:', error);
  }

  const roles = decodedToken?.realm_access?.roles ?? [];

  const roleExists = ifRoleExists(roles);

  const rolePermissions = getPermissions(
    roleExists,
    pathname !== '/' ? pathname : '/partners',
  );

  if (!rolePermissions) {
    return {};
  }

  const {
    add,
    view,
    edit,
    deleteRow,
    confirm,
    include,
  } = rolePermissions as Permissions;

  return {
    add,
    view,
    edit,
    deleteRow,
    confirm,
    include,
  };
}

Conclusion

By dynamically managing role names through environment variables, you can ensure that your application's role-based access control behaves consistently across different environments. This approach provides flexibility and helps maintain a clear separation between development and production configurations.

Implementing Role-Based Access Control in React: A Deep Dive into useRoleManagement Hook

Veaceslav — Sun, 14 Jul 2024 18:09:08 +0000

Intorduction
Managing user roles and permissions is a critical aspect of web application security and functionality. It ensures that users have appropriate access to different parts of the application based on their roles. In this article, I'll walk you through the implementation of a custom useRoleManagement hook in React, which decodes a JWT token to manage user permissions.

Setting Up
Before diving into the implementation, let's set up the necessary tools and libraries. You'll need:

React
jwt-decode for decoding JWT tokens
react-router-dom for managing routing and extracting the current path

npm install react-router-dom jwt-decode

Implementation
Let's start by defining the interfaces for our permissions and JWT payload.

import { JwtPayload, jwtDecode } from 'jwt-decode';
import { useLocation } from 'react-router-dom';

// Realm is for authentication mechanism like Keycloak

interface Realm extends JwtPayload {
  realm_access: {
    roles: string[];
  };
}

// Interface representing the user's permissions

interface Permissions {
  add: boolean;
  view: boolean;
  edit: boolean;
  confirm?: boolean;
  include?: boolean;
  deleteRow?: boolean; 
}

// Interface representing the user's permissions for various pages

interface UserPermissions {
  partners?: Permissions;
  projects?: Permissions;
 // More pages can be added here as needed
}

type PermissionKeys = keyof UserPermissions;

Next, we define the permissions for different roles:

const permissions = {
  manager: {
    partners: {
      add: false,
      view: false,
      edit: false,
      deleteRow: true,
    },
    projects: {
      add: false,
      view: false,
      edit: false,
      deleteRow: false,
    },
    // Define more pages
  },
  analyst: {
    // Define permissions for analyst role
  },
  director: {
    // Define permissions for director role
  },
};

Check if Role Exists
We need a function to check if a role exists and return the associated permissions:

function ifRoleExists(roles: string[]) {
  return roles
    .map((role) => {
      return permissions[role as keyof typeof permissions];
    })
    .filter(Boolean)[0];
}

Get Permissions for the Role
This function retrieves the permissions for a given role and path:

function getPermissions(roleExists: UserPermissions, pathName: string) {
  const withoutSlash = pathName.replace('/', '') as PermissionKeys;
  return roleExists?.[withoutSlash] ?? pathName;
}

useRoleManagement Hook
Finally, we implement the useRoleManagement hook:

export function useRoleManagement() {
  const { pathname } = useLocation();

  const token = localStorage.getItem('token');

  let decodedToken: Realm | null = null;

  try {
    if (token) {
      decodedToken = jwtDecode<Realm>(token);
    }
  } catch (error) {
    console.error('Invalid token:', error);
  }

  const roles = decodedToken?.realm_access?.roles ?? [];

  const roleExists = ifRoleExists(roles);

  const rolePermissions = getPermissions(
    roleExists,
    pathname !== '/' ? pathname : '/partners',
  );

  if (!rolePermissions) {
    return {};
  }

  const {
    add,
    view,
    edit,
    deleteRow,
    confirm,
    include,
  } = rolePermissions as Permissions;

  return {
    add,
    view,
    edit,
    deleteRow,
    confirm,
    include,
  };
}

Usage Example
Here's how you can use the useRoleManagement hook in a React component:

import React from 'react';
import { useRoleManagement } from './useRoleManagement';

const Dashboard = () => {
  const { add, view, edit, deleteRow } = useRoleManagement();

  return (
    <div>
      {view && <p>You can view this content.</p>}
      {add && <button>Add Item</button>}
      {edit && <button>Edit Item</button>}
      {deleteRow && <button>Delete Item</button>}
    </div>
  );
};

export default Dashboard;

Conclusion
In this article, we've implemented a custom useRoleManagement hook in React to manage user permissions based on their roles. This approach ensures that your application remains secure and that users have the appropriate access based on their roles. Feel free to customize the permissions and roles according to your application's requirements.

I hope you found this guide helpful. If you have any questions or suggestions, please leave a comment below!