DEV Community: Veaceslav

Stop calling functions: my first LangGraph graph, where state does the calling

Veaceslav — Tue, 27 Oct 2026 08:25:10 +0000

Three parts in, JobCopilot had layers that worked but couldn't talk to each other. Part 1 gave me a structured-output layer — ParseOk/ParseError as data. Part 2 gave me retrieval — build_context() pulling the top-8 resume chunks for a job description. The pipeline was one line on paper; in code it was nested calls, and the awkward questions had no home: who retries when the model drifts into prose? Who stops the retries? Where does the score live between "parsed" and "shown to the user"?

I did what a React dev does in a new language: I nested functions. The retry loop closed over a closure that closed over a callback, and I couldn't tell you who owned what. Rewriting the flow as a graph — my first with LangGraph — made the nesting disappear. Not because a framework absorbed it, but because the mental model changed: functions stop calling each other; state flows through a graph, and nodes return patches of that state.

It survived everything I threw at it — after I fixed one wire that made every job come back "error", no matter how perfectly the model answered.

1. The state is a pydantic model; nodes return patches

If the graph is the wiring, state is everything a run knows. I made it one pydantic model — deliberately the same discipline as part 1:

# state.py — the whole run in one model
from __future__ import annotations

from typing import Literal

from pydantic import BaseModel, Field

THRESHOLD = 60   # score at or above this = "worth applying"
MAX_CALLS = 3    # 1 first try + 2 repairs — the budget from part 1


class AgentState(BaseModel):
    """One run of the copilot, end to end."""

    jd_text: str = ""
    context: str = ""              # resume chunks, from part 2
    last_raw: str = ""             # what the model last said, verbatim
    error: str | None = None       # latest parse failure, if any
    attempt: int = 0               # how many LLM calls so far

    match_score: int | None = None
    missing_skills: list[str] = Field(default_factory=list)
    verdict: Literal["match", "no_match", "error"] | None = None

The rule that makes a graph a graph: a node never calls another node. It receives state, does one job, and returns a dict with only what changed — a patch. LangGraph merges the patch and hands state to the next node. retrieve fills context; judge fills the score fields; nobody knows about anybody else.

Fields without a custom reducer are last-writer-wins — I proved it to myself before trusting it:

def note_a(state: AgentState) -> dict:
    return {"missing_skills": ["Python"]}

def note_b(state: AgentState) -> dict:
    return {"missing_skills": ["Terraform"]}

# a -> b in that order: missing_skills == ["Terraform"] — b overwrote a

For my state that's correct by design: every field is overwrite-on-purpose, so zero reducers. If a list should accumulate across nodes, opt in with Annotated:

from typing import Annotated


def merge_lists(left: list[str] | None, right: list[str] | None) -> list[str]:
    if left is None:
        return right or []
    if right is None:
        return left
    return list(left) + [x for x in right if x not in left]


class AccumState(BaseModel):
    missing_skills: Annotated[list[str], merge_lists] = Field(default_factory=list)

# two nodes appending "Python" then "Terraform" -> ["Python", "Terraform"]

And why pydantic for state instead of the TypedDict every tutorial starts with? A patch is data from somewhere else, and at merge time nobody type-checks a plain dict:

# TypedDict state, merged by dict spread — type-checkers scream, Python shrugs:
>>> {**{"attempt": 0, "verdict": None}, "verdict": 21, "attempt": "two"}
{"attempt": "two", "verdict": 21}          # garbage, happily stored

# pydantic model:
>>> PS(attempt="two", verdict=21)
pydantic.ValidationError: attempt — Input should be a valid integer...

Same lesson as part 1: shape is a contract, and contracts live in pydantic, not in comments.

2. The graph is a handful of declared edges

Here is the entire graph.py — wiring, not logic:

# graph.py
from langgraph.graph import END, START, StateGraph

from nodes import Chat, fail_node, judge_node, retrieve_node, route_after_parse
from state import AgentState


def build_graph(chat: Chat):
    g = StateGraph(AgentState)

    g.add_node("retrieve", retrieve_node)
    g.add_node("judge", lambda s: judge_node(s, chat))  # closure: node gets the LLM client
    g.add_node("fail", fail_node)

    g.add_edge(START, "retrieve")
    g.add_edge("retrieve", "judge")

    g.add_conditional_edges(
        "judge",
        route_after_parse,          # returns "ok" | "retry" | "give_up"
        {"ok": END, "retry": "judge", "give_up": "fail"},
    )
    g.add_edge("fail", END)

    return g.compile()

Coming from React, this shape clicked instantly: it's a component tree. Components don't import each other to call each other — data flows down a declared structure, and the structure decides what happens next.

The lambda is deliberate: the graph is built once with a concrete LLM client, and no node ever imports a provider. That's what makes the graph testable — hand it a fake chat and the whole flow runs with zero network. Which is exactly how I caught the bug.

3. All routing logic in one boring function — and the wire that said "error" to everything

add_conditional_edges takes a router: a pure function from state to a string, plus a mapping from strings to destinations. Mine is twelve lines and holds the entire loop policy of the agent:

# nodes.py
from state import MAX_CALLS


def route_after_parse(state: AgentState) -> str:
    """All loop logic in one boring function."""
    if state.error is None:
        return "ok"
    if state.attempt < MAX_CALLS:
        return "retry"
    return "give_up"

Compare with my first wiring attempt, written because the router concept felt foreign:

g.add_edge("retrieve", "judge")
g.add_edge("judge", "fail")     # "temporarily — I'll wire the real branches next"

Then I ran it — with a fake chat returning a perfect JSON verdict. Result: verdict = "error". Every single job. The parse was flawless, the score valid, and the graph marched it into fail_node anyway: I had declared exactly one outgoing edge from judge, and a graph never "falls through". Nothing raised, nothing warned — the state machine politely followed the only road I built:

>>> # plain edge judge -> fail, no conditional edges, perfect JSON from the model
>>> app.invoke(AgentState(jd_text="junior"))
verdict = "error"     # a valid parse, executed through the wrong edge

The fix was the conditional edges above, plus two habits that came with it:

Route values are data, not flow control. If the router returns a key that's not in the mapping, LangGraph doesn't guess — it throws KeyError at runtime. I know because my typo did exactly that. An unmapped route crashes loudly; a wrongly-wired edge fails silently. I'll take the crash.
Loops are declared, not nested. "retry": "judge" makes a cycle in the graph. The loop exists as an edge, its budget lives in MAX_CALLS, and its stop condition is one pure function I can unit-test without LLM, network, or shame.

The shift, internalized: in nested functions, control flow was who calls whom — invisible at a glance. In the graph, it's data in the edges — visible in one screenful.

4. Closing the repair loop with state, not recursion

Last piece: judge_node, the only node that talks to the model. It reads state to decide which prompt to send — first pass or repair — and returns a patch either way:

# nodes.py
from schemas import ParseError, ParseOk, parse_match
from state import AgentState, THRESHOLD

MATCH_PROMPT = """You are a skeptical technical recruiter.
Compare the job description to the candidate's resume excerpt.
Reply with ONLY a JSON object:
{{"match_score": <int 0-100>, "missing_skills": [<string, ...>]}}

JOB DESCRIPTION:
{jd}

RESUME EXCERPT:
{context}
"""

FIX_PROMPT = """Your previous reply could not be parsed.

PREVIOUS REPLY:
{previous}

PARSER ERROR:
{error}

Reply with ONLY a valid JSON object:
{{"match_score": <int 0-100>, "missing_skills": [<string, ...>]}}
"""


def judge_node(state: AgentState, chat: Chat) -> dict:
    """One LLM call, one parse, a patch of state. Loops are the graph's job now."""
    if state.error is None:
        prompt = MATCH_PROMPT.format(jd=state.jd_text, context=state.context)
    else:
        prompt = FIX_PROMPT.format(previous=state.last_raw, error=state.error)

    raw = chat(prompt)
    result = parse_match(raw)          # the part-1 contract, unchanged

    patch: dict = {"last_raw": raw, "attempt": state.attempt + 1}
    if isinstance(result, ParseOk):
        score = result.data.match_score
        patch.update(
            match_score=score,
            missing_skills=result.data.missing_skills,
            verdict="match" if score >= THRESHOLD else "no_match",
            error=None,
        )
    else:
        patch.update(error=result.message)
    return patch


def fail_node(state: AgentState) -> dict:
    """The model never produced valid JSON. Say so — as state, not a stack trace."""
    return {"verdict": "error"}

Because build_graph takes chat as a parameter, the end-to-end test is a fake answer card — call one drifts into prose, call two complies:

def flaky_llm():
    calls = {"n": 0}

    def chat(prompt: str) -> str:
        calls["n"] += 1
        if calls["n"] == 1:
            return "Sure! The match is quite good, I'd say around 70 out of 100."
        return '{"match_score": 70, "missing_skills": ["Terraform"]}'

    return chat


app = build_graph(flaky_llm())
final = app.invoke(AgentState(jd_text="Senior Frontend Engineer (React, TS)"))

verdict: match | score: 70 | attempts: 2 | error: None

The prose landed in last_raw, parse_match filled error, the router said "retry", and the second call got FIX_PROMPT with the model's own prose quoted back at it — the part-1 trick, now driven by edges instead of a while-loop. When the model never complies:

verdict: error | error: no JSON object found in model output | attempts: 3

No exception slicing through three stack frames. fail_node writes verdict: "error" and the graph ends — for an agent run overnight over forty postings, a run that ends with a recorded failure beats ten runs that crashed and took the batch with them. Part 1's "errors as data", promoted from one function to the shape of the whole system.

Wrapping up

The first graph, in one sentence: state is a pydantic contract, nodes return patches, a router returns strings, loops live in edges.

Three things this React-dev-learning-Python took from it:

Patches, not calls. The merge is last-writer-wins by default; accumulators are opt-in via Annotated. Every field in my state is overwrite-on-purpose — zero reducers, but verified behavior before trusting it.
Routing is a pure function. Twelve lines, no LLM, unit-testable — and an unmapped return value crashes with a KeyError. That's the framework refusing to guess, and I've come to love it.
Giving up is a node, not a throw. fail writes verdict: "error" and the graph ends cleanly. The batch survives; the log tells the truth.

And the bug that taught me most: a graph executes exactly the edges you declared — my single judge → fail wire turned perfect parses into errors with zero pushback from the framework. A state machine has no common sense. That's the feature.

Next Tuesday, part 4: evals. The judge says 72 — but is 72 right? Fixtures of job descriptions with expected score ranges, a negative case that must score LOW (a Python-backend posting should not match a frontend resume), and the first time JobCopilot tells me I'm wrong.

Follow if you want to watch the rest of the copilot get built — including the parts that break. Build log + daily code: t.me/novamind_hub. Part 1, in case you missed it: Stop prompting for valid JSON: an LLM output layer that does not break.

Do you build agent graphs with a framework or hand-roll the loop? And what's the first thing your graph did that you didn't expect?

Redux Refactoring Playbook: From Action-Types Soup to RTK Query — Without Rewriting the App

Veaceslav — Sat, 24 Oct 2026 07:25:43 +0000

Every React codebase of a certain age has one: the legacy Redux store. Hundreds of thunk actions, manually managed loading flags, per-feature cache invalidation, and a polling timer per data type pulling the full payload whether anything changed or not.

Ours lived under a real-time monitoring dashboard tracking 1,000+ GSM installations at Orange Romania — and by the time we migrated to RTK Query, the story ended with dashboard responsiveness up ~40%, telemetry traffic down 20%, and "frozen dashboard" complaints down 30%.

The previous article told that performance story. This one is the refactoring mechanics: in what order things moved, which decisions unlocked the next one, and the one rule that made a no-rewrite migration possible.

Rule 1 — Strangle, don't rewrite

The store wasn't broken in one place; it was broken everywhere: a switch-case reducer file nobody fully read, five middleware, isLoading / isRefreshing / hasError flag families per resource, and component-level useEffect chains firing fetches in a specific order "because it worked."

A big-bang rewrite was a non-starter: the dashboard was used every day by operations teams. So the rule was:

One page migrates per PR. The rest of the app keeps running on the legacy store untouched.

Redux makes this possible because combineReducers is natural strangler scaffolding:

const rootReducer = combineReducers({
  // new pages live here
  ordersApi: ordersApi.reducer,          // RTK Query
  invoices: invoicesSlice.reducer,       // RTK slice
  // legacy pages keep their ducks until their turn
  legacyTelemetry: legacyTelemetryReducer, // switch-case reducer, retired last
});

Each migration PR carried its own before/after render counts and INP p75 from a fixed scripted interaction. If the numbers moved the wrong way, the PR didn't merge — refactoring without a measurement loop is just rewriting with extra steps.

The code was the easy half. The pitch mattered as much: I sold this as risk control, not cleanup. Every PR shippable alone meant no feature-freeze window that anyone had to buy; the cost I did have to name up front was the parallel-store tax: two stores side by side meant duplicated fixtures and slower reviews while a slice waited for its turn. Leadership signed off because every migration PR ended with a measurement, not with the word "done". One more org-side lesson: the change-flag contract needed a backend buy-in, and I opened that conversation politely, late. Open it on day one; that delay cost us a month.

Rule 2 — Selectors are the API. Freeze them first.

The trick that removed 90% of the migration risk: components never touched state shapes directly.

The legacy store had selector functions (selectOrders, selectNodeById, selectIsNodeActive). Before migrating anything, we froze them as the contract and then made each selector a re-export shim that could source data from either world:

// selectors/orders.js
import { legacyOrders } from './legacySelectors';
import { useGetOrdersQuery } from '../api/ordersApi';

export function useOrders(selector) {
  const { data, isFetching } = useGetOrdersQuery();
  // legacy pages keep working against the same contract
  return useMemo(() => selector(data ?? legacyOrders()), [data, selector]);
}

(Simplified — the real shims carried fallbacks during the window when a page's data half-lived in the old store. The point is the shape: the component-facing API never moved, only its plumbing did.)

Result: a "migration PR" changed the data layer under a page, not forty components over it. That made page-by-page migration realistic rather than a nice idea.

Rule 3 — Kill loading flags with RTK Query, not with better thunks

There was a middle step available: keep the thunks and clean them up. I'd have kept every race. Request A finishing after request B silently overwrote fresher data, and that was our most common production bug, because each flag family carried its own private version of it.

So server state moved into RTK Query, and components declare what they need, not how to fetch it:

// before: every call site, every page
dispatch(fetchOrders());
// + component-local: isLoading, ordersError, lastRefreshed...

// after: the component declares the requirement
const { data: orders, isLoading } = useGetOrdersQuery(undefined, {
  pollingInterval: 0, // see Rule 4 — we don't poll blindly
});

Seventeen loading-flag families disappeared in this step. After it, a component tracking its own fetch lifecycle existed in exactly one place: a page that legitimately needed manual control.

Rule 4 — Polling moves from timers to tags

Old polling: one setInterval per data type, full payload every tick. On a dashboard watching 1,000+ nodes, that's thousands of identical requests an hour and constant re-render churn over data that hadn't changed.

New polling is no polling — it's a change-flag endpoint: a ten-byte version string the dashbo
ard polls on a timer, and the real data refetches when that string actually changes.

export const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  tagTypes: ['Nodes'],
  endpoints: (build) => ({
    nodesChanged: build.query<{ version: string }, void>({
      query: () => 'nodes/changed',       // returns a version string only
    }),
    getNodes: build.query<NodeState[], void>({
      query: () => 'nodes',
      providesTags: ['Nodes'],
    }),
    // refetch tagged data only when the flag version changes:
    // a listener middleware polls `nodesChanged` (cheap, ~10 lines) and,
    // on version change, dispatches api.util.invalidateTags(['Nodes'])
  }),
});

const flagListener = createListenerMiddleware();

flagListener.startListening({
  predicate: (action, currentState, previousState) => {
    // the version lives in RTK Query's own cache, so the store
    // snapshot gives us both "current" and "what it used to be"
    const cur = nodesChanged.select()(currentState)?.data;
    const prev = nodesChanged.select()(previousState)?.data;
    return cur != null && cur !== prev;
  },
  effect: (action, api) => {
    api.dispatch(api.util.invalidateTags(['Nodes']));
  },
});

// the flag endpoint itself: cheap on purpose
//   query: () => 'nodes/changed',   // returns ~10 bytes: a version string
//   pollingInterval: 5000,

What happens on an update, end to end: the version goes into the cache and
predicate sees it differ from the previous snapshot, invalidateTags marks
every tagged entry stale without removing it (the screen keeps the old
data), mounted subscribers immediately refetch — deduplicated to one request
per endpoint+args no matter how many components listen — and one re-render
lands the new data. A component sees isLoading: false, isFetching: true
during that window, which is why nothing flashes. If the flag endpoint dies,
data simply goes stale until the next successful tick; nothing breaks. If
nodes changed five times between two ticks, one refetch covers it: the
version is a snapshot of "what is true now", not an event queue.

What stayed in Redux core

A mistake we avoided (mostly): RTK Query is for server state only. UI-owned state — selected node, filter panel state, column layout, wizard steps — stayed in plain createSlice. Migrating that into queries would have replaced a working pattern with a worse one.

The end state: slices for decisions, RTK Query for data, zero custom cache code, zero hand-rolled loading flags.

The honest ledger

From the published case, measured as perceived dashboard responsiveness (how fast fresh data lands after a change, without UI-thread churn):

Dashboard responsiveness: +~40%
"Frozen dashboard" complaints: −30%
REST telemetry traffic: −20%

What I can't give you is a LOC table with a precise count — we deleted more code than we wrote every migration PR, and by the end the store directory had visibly halved; I kept no exact tally, and a made-up precision here would be dishonest.

What I'd do differently

Start with RTK Query for any new page. Half the migration tail was legacy thunks for features that could have been endpoints from day one.
Freeze selectors before touching anything. The component-facing API is the migration's unit of safety.
Measure per PR, not per epic. The scripted interaction + INP check cost minutes per PR and caught two regressions a "it looks fine" test never would.
Write the change-flag backend contract early. The polling redesign was the single biggest win and it needed a backend buy-in — politeness about it cost us a month.

Your refactoring checklist

Inventory actions/thunks/loading flags — count them, this is your "before" baseline.
Freeze selectors as the component-facing contract.
Add RTK Query via combineReducers alongside the legacy store.
Migrate one page per PR; measure INP p75 + render count on a fixed interaction.
Server state → endpoints with tags; UI state stays in slices.
Replace timers with a change-flag contract before touching fetch logic.
Delete: action-type strings, flag families, custom cache code. The deletion count is the score.

The performance numbers come from the same production system as my earlier piece, A 40% Faster Fault-Detection Pipeline Without WebSockets — that one tells the polling-protocol story; this is the data-layer refactoring around it.

RAG without a vector database: fastembed + numpy, cosine by hand

Veaceslav — Sat, 17 Oct 2026 17:03:37 +0000

title: RAG without a vector database: fastembed + numpy, cosine by hand
published: false
description: "JobCopilot part 2: I skipped the vector database. A 33 MB embedding model, numpy, one dot product — and one retrieval bug a tutorial gave me for free."
tags: python, ai, fastembed, numpy

I'm building JobCopilot in public: a small Python agent that reads a job description, pulls the most relevant chunks of my resume, and lets a skeptical-recruiter prompt do the matching. No framework — raw code first, abstraction only when the pain justifies it. Last week I wrote about the structured-output layer: pydantic, typed errors, retry. This week: the step before that call — deciding which parts of my resume deserve to be in the prompt at all.

I came to Python from React. My first instinct was infrastructure-shopping: every "build your own RAG" tutorial reaches for the same cast — a vector database, a chunking framework, an embeddings API. For my scale, a resume that chunks into single digits and one job posting at a time, that's not architecture. That's a second project to babysit, with an API key attached.

So I skipped all of it: fastembed for embeddings, numpy for search, a 33 MB model instead of a server. It survived every job posting I threw at it — after I fixed one retrieval bug a tutorial handed me for free.

1. Chunks in, embeddings out — the one-time script

The index side of "RAG" turned out to be embarrassingly small. This is the store-building script — I run it once whenever my resume changes:

"""Build my resume store: chunk once, embed once, keep for later."""
import json
import re
from pathlib import Path

import fastembed
import numpy as np

MODEL = "BAAI/bge-small-en-v1.5"   # 384 dims, ~33 MB on disk, CPU-first
TOP_K = 8

_model = None
def _embedder() -> fastembed.TextEmbedding:
    global _model
    if _model is None:                      # lazy: don't pay on import
        _model = fastembed.TextEmbedding(model_name=MODEL)
    return _model

def chunk_resume(md: str) -> list[str]:
    """Split by ## headings; each section becomes one chunk."""
    parts = re.split(r"\n(?=## )", md)
    return [p.strip() for p in parts if p.strip()]

def build_store(md_path: str, out_path: str) -> dict:
    md = Path(md_path).read_text()
    chunks = chunk_resume(md)
    vecs = list(_embedder().embed(chunks))
    emb = np.stack(vecs)
    emb = emb / np.linalg.norm(emb, axis=1, keepdims=True)   # normalize once
    Path(out_path).write_text(json.dumps({"chunks": chunks, "emb": emb.tolist()}))
    return {"chunks": len(chunks), "dims": emb.shape[1]}

if __name__ == "__main__":
    print(build_store("resume.md", "resume_store.json"))

Why each piece earns its line:

MODEL = "BAAI/bge-small-en-v1.5" — 384-dimension vectors, ~33 MB on disk, runs on CPU, no API key, no runtime network (the model downloads once, then it's local). For a single-language corpus at this scale, "small embedding model" isn't a compromise — it's the correct answer.
Lazy _embedder() — the model loads on first use, not on import, so scripts and tests that never embed anything don't pay for it.
re.split(r"\n(?=## )", md) — one regex line does the chunking: each ## section keeps its heading attached to its body, bodyless headings get dropped by the emptiness check. My resume lands at a handful of chunks — no chunking framework required.
Normalize once, at build time (emb / norm) — this pays off in the runtime section: cosine similarity on unit vectors collapses into a plain dot product. I'll come back to exactly why.

One run of python store_resume.py writes a JSON file: chunk strings plus a 384-float vector each. If you can regenerate your index with one command, it's not infrastructure — it's a build artifact. That reframe took most of the mystique out of RAG for me.

2. The whole runtime is 10 lines: `scores = emb @ q`

The query side — this is retrieve.py, the entire retrieval engine:

"""Runtime: pull the TOP_K chunks that matter for this job posting."""
import json
from pathlib import Path

import numpy as np

from store_resume import TOP_K, _embedder

def retrieve(query: str, store_path: str = "resume_store.json") -> list[tuple[str, float]]:
    store = json.loads(Path(store_path).read_text())
    chunks: list[str] = store["chunks"]
    emb = np.array(store["emb"])

    q = np.stack(list(_embedder().embed([query])))[0]
    q = q / np.linalg.norm(q)

    scores = emb @ q                      # cosine by hand: one dot product
    order = np.argsort(scores)[::-1][:TOP_K]

    return [(chunks[i], float(scores[i])) for i in order]

emb is (n_chunks, 384), q is (384,). One matmul broadcasts the query over every chunk row; the argsort sorts descending and keeps the top 8.

Why no vector DB, honestly answered: at single-digit chunks the whole "index" is a matrix, and a full scan is one matmul — microseconds. Ann indexes buy speed at hundreds of thousands of vectors and pay with recall errors plus another service to run. At my scale that trade is upside-down: complexity buys speed I don't need.

Coming from JavaScript, I'd have typed the cosine formula out manually, looping. The numpy docs (the senior-er voice in my head) said: if every vector is unit length, the dot product IS the cosine similarity. That's why build_store and retrieve both normalize immediately.

What the scores actually look like for the query "Kubernetes, Terraform, SRE on-call" against a small demo resume (6 chunks — this is my sandbox example, not the real store):

0.784  '## Kubernetes & SRE track record...'
0.573  '## Side projects...'
0.550  '# Demo Resume'
0.504  '## Experience...'
0.496  '## Skills...'
0.487  '## Interests...'

The shape is the story: the relevant chunk breaks away at 0.78, then comes the noise band — chunks that don't match the query, they match the genre of resumes. Retrieval is only useful while that separation exists. Which brings me to the bug.

3. The bug that got me: `TOP_K = 12` — ranking, downgraded to bulk-loading

Now the part I'm genuinely not proud of: my first working retrieval had TOP_K = 12, because a tutorial used it and I kept it. It felt robust — "grab a lot, the LLM will figure out relevance." The effect was the opposite.

The failure is invisible — no crash, no warning. argsort()[::-1][:12] just hands you a dozen chunks: the one that actually matched the posting, plus eleven that match the genre of job postings and resumes — Python keywords, generic resume lines. That tail was exactly what got pasted into the prompt, and the LLM, agreeable as ever, worked it into the missing-skills list with full confidence. Garbage in, confident garbage out.

The score line told the story in two numbers. With an over-fed TOP_K on my real store, the top of the list and the tail it dragged along looked like this:

0.635  '## Work Experience — the relevant one'
...
0.450  '## Languages — pure filler for this query'

A 0.185 spread where only the first row deserved attention; everything below ~0.55 was noise-band bulk. No separation. Retrieval had stopped ranking and started bulk-loading with extra steps. My fix was one line:

TOP_K = 8    # was 12 from a tutorial; enough for a resume, small enough to keep the gap

After:

0.635  '## Work Experience — the relevant one'
0.592  '## Technical Skills — adjacent, still on-topic'

And the 8-slot list ends in the languages/education band — nothing under 0.45 enters the prompt. The top row visibly separates again.

The rule I use now (embarrassingly late in my Python learning): TOP_K must stay small enough that the top-1 score visibly separates from the rest. The moment it stops separating, retrieval is decoration and the prompt is a firehose. On my resume, 8 is enough. And the tutorial never mentioned any of this — perfectly correct code can still be wrong, because a constant you copied was tuned for someone else's scale.

4. From ranked chunks to a prompt, with a character budget

Retrieval gives me ranked chunks with scores; the prompt needs one string. I could .join() the top 8 and move on — but the naive join has two failure modes: a monster section eating the prompt's attention budget, and a torn tail — a chunk cut in half by a [:2400] slice, half a bullet floating in the prompt.

build_context fixes both:

def build_context(query: str, store_path: str = "resume_store.json",
                  max_chars: int = 2400) -> str:
    """Join top chunks into one string for the prompt, and STOP when full."""
    out, size = [], 0
    for text, _score in retrieve(query, store_path):
        if size + len(text) > max_chars:
            break                  # a chunk that doesn't fit is dropped WHOLE
        out.append(text)
        size += len(text)
    return "\n\n".join(out)

Two details matter:

Stop at max_chars even if that uses fewer than TOP_K chunks. A prompt-quality knob, not a storage quota: 2400 tightly selected characters beat 6000 of everything.
Cut at chunk boundaries. A chunk that would overflow is skipped whole — no torn half-bullet floating in the prompt.

I tested a Represent this sentence for searching relevant passages: query prefix (documented for bge models) against my store: top score +0.014, but the gap to the second row shrank — a wash for ranking, which is what actually matters at my scale. So there's no query-prefix engineering in this pipeline; normalization is the only trick worth keeping.

Wrapping up

Retrieval without a vector DB: chunk by headings → embed once with a 33 MB model → normalize at build time → emb @ q at runtime → keep top-8 → join into a char-budgeted context. About 60 lines total — and I understand every one of them, which is more than I could say for a vector DB I don't need yet.

Three things this React-dev-learning-Python took from it:

For small corpora, a "vector store" is a JSON file and a matmul. The tutorials don't tell you when your scale justifies something heavier — your own score gap does.
Copy-pasted defaults have their owner's scale baked in. TOP_K = 12 was fine in the tutorial's corpus and quietly destructive in mine.
The most honest measure isn't the top score — it's the gap between the top score and the next one. If the gap is gone, nothing downstream matters.

Next Tuesday, part 3: my first agent graph — nodes that return partial state patches instead of raising, routing on data instead of exceptions, and the LangGraph mental shift from "function calls function" to "state flows through a graph".

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

How do you handle retrieval at small scale — still reaching for a vector DB, or plain numpy? And what default did you copy from a tutorial that quietly cost you?

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!

DEV Community: Veaceslav

Stop calling functions: my first LangGraph graph, where state does the calling

1. The state is a pydantic model; nodes return patches

2. The graph is a handful of declared edges

3. All routing logic in one boring function — and the wire that said "error" to everything

4. Closing the repair loop with state, not recursion

Wrapping up

Redux Refactoring Playbook: From Action-Types Soup to RTK Query — Without Rewriting the App

Rule 1 — Strangle, don't rewrite

Rule 2 — Selectors are the API. Freeze them first.

Rule 3 — Kill loading flags with RTK Query, not with better thunks

Rule 4 — Polling moves from timers to tags

What stayed in Redux core

The honest ledger

What I'd do differently

Your refactoring checklist

RAG without a vector database: fastembed + numpy, cosine by hand

1. Chunks in, embeddings out — the one-time script

2. The whole runtime is 10 lines: scores = emb @ q

3. The bug that got me: TOP_K = 12 — ranking, downgraded to bulk-loading

4. From ranked chunks to a prompt, with a character budget

Wrapping up

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

The ticket-queue blind spot

The constraint that reframed everything

The reframe: change the data granularity, not the protocol

The RTK Query side: cache and refetch discipline

Showing pain, not data: the map

The numbers

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

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

The problem in one picture

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

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

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

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

The whole picture

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

What it looks like in practice

One gotcha: the CLAUDE.md twin problem

Bonus: monorepos want nested AGENTS.md files

The takeaway

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

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

2. The whole runtime is 10 lines: `scores = emb @ q`

3. The bug that got me: `TOP_K = 12` — ranking, downgraded to bulk-loading