DEV Community: Arish singh

How I Built Velocity — An AI Platform That Turns Plain English Into Production-Grade n8n Workflows

Arish singh — Sat, 04 Jul 2026 01:01:24 +0000

ai #n8n #nextjs #showdev

You describe the automation. Velocity ships the workflow — importable, deployable, running in your n8n instance one click later.

Every automation builder has been there. You know exactly what you want: "when a form is submitted, enrich the lead, drop it in a sheet, and ping Slack." Then you spend the next two hours in the n8n canvas hunting for the right node, guessing parameter names, wiring connections, and debugging Could not find property option errors on import.

The knowledge to build that workflow exists. It's just locked behind hundreds of node types, typeVersion quirks, and expression syntax. So I built Velocity — an AI platform that takes a plain-English description and generates a complete, valid, importable n8n workflow JSON. Not a 4-node demo. A production-grade pipeline with real triggers, configured parameters, error notifications, and sticky-note documentation — the depth of an actual published n8n template.

What I Built

Velocity is a full-stack AI automation copilot. The core loop:

Describe your automation in plain English → Gemini generates the full n8n workflow JSON
Chat with the copilot → iterate on the workflow conversationally, with full history
One-click deploy → Velocity pushes the workflow straight into your n8n instance via its REST API and activates it
Paste an error log → get a structured cause / fix / patch explanation
Browse real templates → proxied live from the official n8n template library

Tech stack:

Next.js 16 (App Router, Turbopack) + React 19
Google Gemini (raw REST API — no SDK) with a multi-model failover chain
Supabase (auth + Postgres with Row Level Security)
Redis (chat history hot cache + distributed rate limiting)
n8n public REST API for one-click deployment
Tailwind CSS v4 + Base UI + Motion (Framer Motion v12)
Deployed on Vercel

System Architecture

                        ┌─────────────────────────────┐
                        │        Next.js 16 App        │
                        │                             │
 Browser ──────────────▶│  /api/chat ─────────┐       │
   │                    │  /api/generate-workflow ─┐  │      ┌──────────────┐
   │  Supabase JWT      │  /api/explain-error ──┐  │  │      │    Gemini    │
   │  (Authorization    │  /api/analyze-workflow│  │  ├─────▶│  REST API    │
   │   header)          │  /api/plan-workflow ──┘  │  │      │ + fallback   │
   │                    │                          │  │      │   models     │
   │                    │  /api/deploy-to-n8n ─────┼──┼──┐   └──────────────┘
   │                    │  /api/templates ─────────┼──┼──┼─▶ api.n8n.io
   │                    │  /api/conversations ──┐  │  │  │
   │                    └───────────────────────┼──┼──┼──┼──┘
   │                                            │  │  │  │
   │                          ┌─────────────────▼──▼──┤  └─▶ Your n8n
   │                          │  Supabase Postgres    │      instance
   └─────────────────────────▶│  (RLS: auth.uid())    │      (create +
                              └───────────┬───────────┘       activate)
                                          │
                              ┌───────────▼───────────┐
                              │  Redis                │
                              │  · recent-turns cache │
                              │  · rate-limit counters│
                              └───────────────────────┘

Every AI route follows the same pipeline: verify JWT → rate limit → build prompt → call Gemini (with failover) → repair/parse JSON → persist → respond. Postgres is always the source of truth; Redis is always a cache that fails open.

How I Built It

The System Prompt Is the Product

The single hardest problem wasn't code — it was getting the model to emit workflow JSON that n8n will actually import. n8n is unforgiving: a wrong typeVersion loads a different parameter schema, a hallucinated dropdown value throws Could not find property option, and referencing a workflow that doesn't exist throws Could not find workflow.

The fix was treating the system prompt like a schema contract, not a vibe. A few of the rules that came directly from watching real imports fail:

IMPORT SAFETY — these prevent the two most common load errors:
- typeVersion: use 1 for simple core nodes unless you specifically need a
  newer version's fields. A wrong typeVersion loads a different parameter
  schema and breaks with "Could not find property option".
- Do NOT emit resource-locator objects ({"__rl":true,"mode":...,"value":...}).
  Their mode/value pairs are the #1 cause of "Could not find property option".
- NEVER reference another workflow you don't have a real id for.
- "connections" keys are the SOURCE node's NAME (exact, case-sensitive) —
  never its id.

Each of those lines exists because a generated workflow broke without it. The prompt also encodes verified parameter shapes for the most common nodes (HTTP Request, Set, If, Webhook, Schedule Trigger), because "parameters": {} produces workflows that import but do nothing:

- HTTP Request (POST): {"method":"POST","url":"...","authentication":"none",
  "sendBody":true,"body":{"contentType":"json","content":{...}}}
  GOTCHA: POST/PUT/PATCH MUST include "sendBody":true.

And the killer rule for accuracy: when a service has no dedicated n8n node, use a fully-configured HTTP Request node against its REST API instead of guessing. A configured httpRequest beats an empty branded stub every time.

One Contract, Two Routes — Killing Prompt Drift

Velocity has two AI surfaces that both emit n8n JSON: the conversational copilot (/api/chat) and the structured one-shot generator (/api/generate-workflow). Early on they had separate prompts, and they drifted — a rule fixed in one route would still break in the other.

The fix was boring and effective: the n8n contract lives in exactly one file, and both routes compose their system prompts from it.

// n8nPrompt.ts — the single source of truth
export const N8N_WORKFLOW_SHAPE = `An n8n workflow is a JSON object that imports cleanly: {...}`;
export const N8N_RULES = `RULES — follow every one: ...`;

// Conversational copilot (used by /api/chat)
export const CHAT_SYSTEM = `You are Velocity, an AI copilot...
${N8N_WORKFLOW_SHAPE}
${N8N_RULES}
...`;

// Structured one-shot (used by /api/generate-workflow)
export const GENERATE_SYSTEM = `You are Velocity, an expert at building n8n workflows...
${N8N_WORKFLOW_SHAPE}
${N8N_RULES}`;

If you have two prompts encoding the same output schema, they will drift apart. Shared constants are the cheapest insurance you'll ever buy.

Surviving the Free Tier: A Model Failover Chain

I run this on Gemini's free tier, and the preview model I use (gemini-3-flash-preview) has a 20 requests per day allowance. That's not a rate limit, it's a countdown timer. Rather than let the app die at request 21, the Gemini wrapper detects quota-exhausted 429s and transparently fails over to stable models that still have quota:

export const GEMINI_MODEL = "gemini-3-flash-preview";
const FALLBACK_MODELS = ["gemini-2.5-flash", "gemini-2.0-flash"];

// Signals the primary/fallback loop to try the next model.
class QuotaExhaustedError extends Error {}

async function generate(contents, maxTokens, temperature, jsonMode = false) {
  const models = [GEMINI_MODEL, ...FALLBACK_MODELS];
  let lastQuota: QuotaExhaustedError | null = null;

  for (const model of models) {
    try {
      return await generateWithModel(model, contents, maxTokens, temperature, jsonMode);
    } catch (err) {
      // Only a spent quota triggers failover; every other error is terminal.
      if (err instanceof QuotaExhaustedError) { lastQuota = err; continue; }
      throw err;
    }
  }
  throw lastQuota ?? new Error(QUOTA_MESSAGE);
}

The subtle part is distinguishing the two kinds of 429. A regular rate-limit 429 recovers if you back off; a quota 429 will not clear until tomorrow, so retrying is pure waste. The tell is in the response body:

// A 429 whose body mentions quota/billing (or "limit: 0") means the key's
// free-tier allowance is exhausted — retrying won't help.
function isQuotaExhausted(body: string): boolean {
  return /\blimit:\s*0\b|exceeded your current quota|billing/i.test(body);
}

Transient errors (500/502/503/504 and recoverable 429s) get exponential backoff with jitter — and the wrapper honors the API's own Retry-After header and Gemini's RetryInfo body when they suggest a delay. If the suggested delay is longer than the request budget, it gives up early with a human-readable message instead of hanging.

I also skipped the SDK entirely. The wrapper is a raw fetch against the Generative Language REST API — ~230 lines including all the retry/failover logic. When your error handling is your reliability story, owning the HTTP layer beats fighting an SDK's opinions.

Parsing JSON From a Model That Doesn't Always Return JSON

Even with responseMimeType: "application/json" forced, LLM output is only almost JSON often enough to hurt: markdown fences around the object, a stray sentence before it, trailing commas, literal newlines inside string values, and — the worst one — output truncated mid-object at the token limit.

A naive JSON.parse(raw.slice(raw.indexOf("{"), raw.lastIndexOf("}") + 1)) fails on all of those. So I wrote parseModelJson, a repair parser that extracts the first balanced JSON value with a proper scanner (string-aware, escape-aware), fixes control characters, and — if the input was truncated — closes the open string and any open brackets so the result still parses:

// Reached the end with brackets still open → truncated. Best-effort close.
if (inString) out += '"';
out = removeTrailingCommas(out.replace(/,\s*$/, ""));
while (stack.length) out += stack.pop();
return out;

Then it tries candidates from cleanest to rawest, each with a trailing-comma-stripped retry:

for (const candidate of [extracted, stripped, raw]) {
  if (!candidate) continue;
  const direct = tryParse<T>(candidate);
  if (direct !== undefined) return direct;
  const repaired = tryParse<T>(removeTrailingCommas(candidate));
  if (repaired !== undefined) return repaired;
}
return null;

The same philosophy shows up in the chat flow: when a user asks to deploy "the workflow from our conversation," a depth-tracking scanner walks the assistant messages newest-first, pulls out every balanced {...} slice, and keeps the ones that actually contain a nodes array. Fenced, unfenced, buried in prose — it finds the workflow.

Rule of thumb: never let JSON.parse be the last line of defense between an LLM and your user.

Auth: Let Postgres Enforce Ownership, Not Your Route Code

Every API route authenticates the same way: the browser sends its Supabase JWT in the Authorization header, and the server builds a request-scoped Supabase client that carries that token:

export async function getAuth(req: Request): Promise<AuthContext | null> {
  const token = bearerToken(req);
  if (!token) return null;

  // Request-scoped client carrying the user's JWT, so RLS (auth.uid())
  // applies to every query made through it.
  const db = createClient(url, anon, {
    global: { headers: { Authorization: `Bearer ${token}` } },
    auth: { autoRefreshToken: false, persistSession: false },
  });

  const { data, error } = await db.auth.getUser(token);
  if (error || !data.user) return null;
  return { userId: data.user.id, db };
}

The important choice: routes query through this client, not through the service-role admin client. That means Postgres Row Level Security (auth.uid()) applies to every single query. Even if I write a buggy WHERE clause, user A physically cannot read user B's conversations — the database refuses. The service-role key is used in exactly one place: the signup route, where admin user provisioning genuinely needs it.

Redis: Always a Cache, Never the Truth

Chat needs the recent conversation history on every turn. Hitting Postgres for the last 20 messages on every message works, but Redis makes it instant — as long as you're disciplined about what Redis is:

// Prior history: Redis cache, falling back to Postgres (and repriming).
let history = await getCachedTurns(conversationId);
if (history === null) {
  const { data: rows } = await auth.db
    .from("messages")
    .select("role, content")
    .eq("conversation_id", conversationId)
    .order("created_at", { ascending: false })
    .limit(MAX_TURNS);
  history = ((rows ?? []) as Turn[]).reverse();
  await primeCache(conversationId, history);
}

Both turns are persisted to Postgres before the cache is updated. A cache miss, an expired key, a Redis outage — all of it degrades to a Postgres read and a reprime. Nothing is ever lost because nothing important ever lived only in Redis.

The rate limiter follows the same philosophy but inverted — it fails open:

// Fails OPEN: if Redis is absent or errors, requests are allowed so chat
// keeps working — rate limiting is a safety layer, never a hard dependency.
export async function checkRateLimit(scope: string): Promise<RateResult> {
  const redis = getRedis();
  if (!redis) return { ok: true };
  ...
}

It runs two layered counters — a global one protecting the shared Gemini key's quota across all users, and a per-user one so a single caller can't hog the whole budget. The defaults (5/min, 20/day) deliberately mirror the Gemini free-tier quota, so the app's rate limit and the upstream quota fail at the same boundary with a friendly message instead of a raw 429.

One-Click Deploy: Closing the Loop

Generating JSON the user has to manually import is a demo. Deploying it is a product. /api/deploy-to-n8n accepts either a plain-English prompt (generate first, then deploy) or existing workflow JSON, pushes it to the user's n8n instance via the public REST API, and tries to activate it:

const created = await createWorkflowInN8n(workflowDraft, fallbackName);
const activation = await activateWorkflowInN8n(created.workflowId);

return NextResponse.json({
  workflowId: created.workflowId,
  workflowUrl: created.workflowUrl,   // deep link into the n8n editor
  activated: activation.activated,
  activationError: activation.activated ? undefined : activation.detail,
});

Note the shape of the response: activation failure is not an error. A workflow with a manual trigger can't be activated — that's expected, so the route reports activated: false with the detail and still hands back the editor URL. Modeling "partial success" honestly beat forcing everything into success/failure.

Problems I Faced (aka Lessons Learned)

The hardest bugs were import bugs, not code bugs. A workflow can be perfectly valid JSON and still fail n8n's import with Could not find property option. The causes were never in my code — they were in what the model invented: resource-locator objects, wrong typeVersions, dropdown values that don't exist. The fix was moving n8n's failure modes into the prompt as explicit prohibitions. Every import error became a new rule. The prompt is a changelog of everything that ever broke.

"Add more validation code" is usually the wrong first move. My instinct on every bad output was to write a post-processor. But post-processors can't fix a hallucinated parameter schema — they can only detect it. Restructuring the prompt (verified parameter shapes, "use httpRequest when unsure") fixed at the source what validation could only reject.

Free-tier quotas are an architecture constraint, not an ops detail. 20 requests/day on the primary model shaped real design decisions: the failover chain, the two-layer rate limiter mirroring the quota, distinguishing quota-429s from rate-429s, and honoring Retry-After. If I'd treated the quota as "someone else's problem," the app would be a coin flip.

LLMs leak their reasoning into output, and you have to tell them not to. Models love to open with "Okay, the user wants a workflow that..." before the JSON. Two mitigations: a DIRECTIVE suffix appended to every final user turn ("Output ONLY the final answer... Begin the answer immediately"), and hard constraints in the chat prompt banning meta-commentary, node-by-node prose dumps, and "here is the workflow" framing. Prompt discipline is output discipline.

Every external dependency needs a "not configured" story. Supabase clients return null when env vars are missing. hasGemini() gates every AI route. hasN8nConfig() gates deployment. Every route degrades to a clear "add X to .env.local" message instead of a crash. It made local development, demos, and partial deployments painless — you can run the marketing page with zero env vars.

Next.js 16 is not the Next.js in the model's training data. The repo has a standing rule: read the docs shipped in node_modules/next/dist/docs/ before writing framework code, because App Router conventions moved again. When a framework error looks undocumented, check your framework version first — the answer is almost always a recent breaking change.

What's Next

Velocity's core loop — describe → generate → deploy — works end-to-end. What I'm building next:

Workflow analysis & repair — paste any existing workflow and get a structured health report with auto-fixes (the /api/analyze-workflow and /api/explain-error routes are the foundation)
Plan-first generation — show the step plan and required services before generating, so users can edit the plan instead of the JSON
Execution monitoring — pull real run data from connected n8n instances into the dashboard
Template remixing — start from one of the official n8n templates and modify it conversationally

The core insight hasn't changed: automation knowledge shouldn't be locked behind a node catalog and a canvas. You describe the outcome; the machine should handle the wiring.

Built with Next.js 16, React 19, Google Gemini, Supabase, Redis, Tailwind CSS v4, and the n8n REST API.

If you've fought with LLM structured output, n8n imports, or free-tier quotas — I'd genuinely love to hear how you handled it. Drop a comment. 👇

— Arish Singh

Nexa - platform to understand any codebase

Arish singh — Sat, 13 Jun 2026 01:23:17 +0000

An AI platform that turns any GitHub repository into an interactive visual map so you can understand a codebase in an hour, not a week.

Every developer has been there. You clone a new repo, open the folder tree, and stare at 400 files with no idea where anything lives. The README is three years out of date. The architecture is documented somewhere in a Notion page nobody can find. You spend the first week just figuring out what calls what.

I got tired of that. So I built Nexa — a full-stack platform that connects to any GitHub repository, builds an interactive dependency graph from the actual code, and lets you ask an AI questions about what you're looking at. You go from a repo URL to a complete mental model in the first hour.

What I Built

Nexa is a full-stack codebase intelligence platform. Here's the core loop:

Sign in with GitHub → Supabase OAuth, your provider_token becomes the GitHub API key
Pick any repository → from your own repos, collaborations, or organization repos all in one dashboard
Explore the graph → an interactive canvas renders every folder and file as a force-directed node graph
Select any node → the AI panel explains what it does, what depends on it, and how it fits the architecture
Ask questions → a chat interface with full repo context answers anything about the codebase

Tech stack:

Next.js 14 (App Router)
Supabase Auth with GitHub OAuth (@supabase/ssr)
GitHub REST API via Octokit
Anthropic Claude (claude-sonnet-4-6) for code analysis and chat
Canvas API (<canvas>) for the force-directed graph renderer
Tailwind CSS

What It Actually Does

Fetches the full recursive file tree of any repo via GitHub's Git Trees API in a single request
Builds a force-directed graph where folders are hub nodes and files are satellites orbiting them
Colors nodes by programming language, matching the language dot colors developers already recognize from GitHub
Renders everything on a <canvas> element — no SVG, no D3, no React re-renders on every frame
Streams AI analysis of any selected file or folder directly from the Anthropic API
Maintains a full chat session with repo context so you can ask follow-up questions
Shows your own repos, collaborator repos, and organization repos in separate sections so you can always find what you're looking for

Key Features

Language-aware coloring — TypeScript is blue, Python is green, Go is cyan, matching GitHub's own color conventions so the graph is immediately readable
Single-request tree fetch — GitHub's recursive tree endpoint returns the entire repo structure in one API call regardless of depth, no recursive pagination
Canvas renderer, not DOM — the graph renders thousands of nodes at 60fps because nothing touches the DOM after the initial mount
provider_token auth — Supabase stores the GitHub OAuth token directly in the session, so every API route just reads session.provider_token with no extra token storage
Affiliation grouping — the dashboard separates your repos from collaboration repos so you know whose code you're looking at
Repo overview on load — the overview panel surfaces language breakdown, file count, and dependency stats before you open a single file

How I Built It

The Graph Renderer: Why Canvas, Not SVG

The obvious approach is D3 force simulation with SVG. Every tutorial does it that way. The problem: a mid-size repository has 800–1,200 files. SVG at that scale creates 800–1,200 DOM nodes. Every tick of the physics simulation forces a layout recalculation. On anything less than a high-end machine it becomes a slideshow.

The fix is a <canvas> renderer. The physics simulation (custom spring force + repulsion) runs in a requestAnimationFrame loop, and every frame clears the canvas and redraws everything imperatively:

function drawFrame(ctx: CanvasRenderingContext2D, nodes: Node[], edges: Edge[]) {
  ctx.clearRect(0, 0, width, height)

  // Draw edges first (behind nodes)
  for (const edge of edges) {
    ctx.beginPath()
    ctx.moveTo(edge.source.x, edge.source.y)
    ctx.lineTo(edge.target.x, edge.target.y)
    ctx.strokeStyle = 'rgba(255,255,255,0.04)'
    ctx.stroke()
  }

  // Draw nodes
  for (const node of nodes) {
    ctx.beginPath()
    ctx.arc(node.x, node.y, node.r, 0, Math.PI * 2)
    ctx.fillStyle = node.color
    ctx.fill()
  }
}

No virtual DOM. No reconciliation. No layout recalculation. The canvas just paints pixels as fast as the GPU can move them.

Hit testing (knowing which node you clicked) requires manual math since the canvas has no event system:

function getNodeAtPoint(x: number, y: number, nodes: Node[]): Node | null {
  // Check in reverse order so top-rendered nodes get priority
  for (let i = nodes.length - 1; i >= 0; i--) {
    const n = nodes[i]
    const dx = x - n.x, dy = y - n.y
    if (dx * dx + dy * dy <= n.r * n.r) return n
  }
  return null
}

Worth the extra code. The graph handles 1,000-node repos without a frame drop.

GitHub Auth: `provider_token` Is the Whole Solution

The first version of Nexa used NextAuth with a GitHub provider and a custom session.accessToken field. Replacing that with Supabase cut out about 200 lines of auth boilerplate.

The key insight: when a user signs in via Supabase GitHub OAuth, the GitHub access token lives directly on the session:

const { data: { session } } = await supabase.auth.getSession()
const accessToken = session?.provider_token  // this is the GitHub token

Every API route reads this one field. No separate token storage, no database column, no JWT augmentation. The token scope is set once at sign-in time:

await supabase.auth.signInWithOAuth({
  provider: 'github',
  options: {
    scopes: 'read:user repo',
    redirectTo: `${origin}/auth/callback`,
  },
})

repo scope covers private repos. read:user covers the user profile. That's everything Nexa needs.

The OAuth callback is three lines:

// app/auth/callback/route.ts
const { searchParams } = new URL(request.url)
const code = searchParams.get('code')
await supabase.auth.exchangeCodeForSession(code!)
return NextResponse.redirect(new URL('/dashboard', request.url))

Fetching Repos: One API Call for Everything

GitHub's authenticated repo endpoint supports an affiliation parameter that most tutorials ignore:

const { data } = await octokit.repos.listForAuthenticatedUser({
  sort: 'updated',
  per_page: 100,
  page,
  affiliation: 'owner,collaborator,organization_member',
})

One parameter, three categories. The response includes every repo the user owns, every repo they're a collaborator on, and every repo in every organization they belong to. The dashboard then splits them client-side:

const myRepos     = repos.filter(r => r.affiliation === 'owner')
const collabRepos = repos.filter(r => r.affiliation !== 'owner')

Collaboration cards show owner/repo-name with the owner's avatar so you immediately know whose codebase you're jumping into.

The File Tree: One Request, Any Depth

The naive approach — walking the tree recursively, one API call per folder — falls apart on large repos. A repo with 10 levels of nesting makes dozens of sequential requests.

GitHub's Git Trees API has a recursive: '1' parameter that solves this completely:

const { data } = await octokit.git.getTree({
  owner,
  repo,
  tree_sha: branch,
  recursive: '1',  // returns the entire tree flat
})

One request. Every file. No matter how deep the nesting. The response is a flat array of every path in the repo, which the graph renderer then groups into folders client-side by splitting on /.

The only edge case: GitHub truncates responses for repos over ~100,000 files and sets data.truncated = true. For those repos Nexa shows the truncation warning in the UI rather than silently showing an incomplete graph.

AI Analysis: Streaming Claude Over the Repo Tree

The analysis panel streams responses from Claude with the repo's file tree as context. The system prompt is assembled server-side from the actual tree data:

const systemPrompt = `You are analyzing the GitHub repository ${owner}/${repo}.

File structure:
${treeItems.map(f => f.path).join('\n')}

Language breakdown:
${languageSummary}

Answer questions about architecture, dependencies, and code organization.
Be specific — reference actual file paths from the tree above.`

Giving Claude the real file tree (not a summary, the actual paths) means its answers reference app/api/auth/callback/route.ts instead of "the auth callback file." Specificity is the difference between useful and generic.

The response streams over the Vercel AI SDK's StreamingTextResponse, so the panel starts showing text within a few hundred milliseconds of the request.

Lessons Learned

The hardest bugs are coordinate system bugs. The canvas renderer uses three coordinate systems simultaneously: screen coordinates (pixels from top-left of the viewport), canvas coordinates (pixels from top-left of the canvas element), and graph coordinates (the physics simulation's arbitrary space). Getting a click on a node to correctly identify which node was clicked required tracking pan offset, zoom scale, and device pixel ratio through every transformation. I got it wrong three times before writing out all three transforms explicitly on paper.

Supabase's provider_token disappears after session refresh. The GitHub token is available on first login but Supabase does not persist it across session refreshes. After an hour, session.provider_token comes back null. The fix is to store the token in the user's Supabase metadata or a database row on first login and read it from there on subsequent requests. This is a known issue and not documented clearly.

GitHub OAuth's "Homepage URL" and "Authorization callback URL" are different fields. The OAuth app settings in GitHub have two URL fields. The Authorization callback URL must be the Supabase OAuth callback (https://<project>.supabase.co/auth/v1/callback), not your app's URL. Putting the app URL in the wrong field produces a cryptic redirect_uri_mismatch error that has nothing to do with the error message.

overflow: hidden on body will silently break page scrolling. A starter template had overflow: hidden on the body for the landing page's scroll-snap behavior. The dashboard inherited it and became unscrollable with no console error, no warning, no indication of why. The fix was one CSS line. Finding it took longer than it should have because the symptom (content cuts off) looks identical to a layout height bug.

Force-directed graphs need damping or they never settle. The physics simulation adds spring forces and repulsion on every frame. Without a velocity damping coefficient, nodes oscillate forever — the graph never reaches a stable layout. Adding node.vx *= 0.85 and node.vy *= 0.85 per frame brings the simulation to rest in about 3 seconds. Too much damping and the graph snaps into place awkwardly. Too little and it bounces. 0.82–0.88 is the range that looks natural.

What's Next

Nexa is live and the core explore loop works end-to-end. What I'm building next:

Symbol-level graph — go deeper than files, show function calls and import relationships as edges
Diff view — compare two branches or commits as graph changes, see what moved and what broke
Team onboarding packs — generate a curated "start here" guide from the graph for new contributors
PR impact preview — before merging, see which nodes in the graph your PR touches and what depends on them

The core insight hasn't changed: reading code in a file tree is like reading a city by looking at individual addresses. The graph is the map. Once you have the map, everything else is navigation.

Built with Next.js 14, Supabase, GitHub API, Anthropic Claude, and the browser's native Canvas API.

— Arish Singh

Built a Chrome Extension That Watches my Dev Tab and Explains Everything

Arish singh — Sun, 07 Jun 2026 00:20:44 +0000

about Croma

Croma is a AI dev tools extension that auto-explains selected code, catches console errors, monitors slow API calls, and answers questions about any page you're on.

I kept alt-tabbing to ChatGPT to explain stack traces I was already staring at.
The error was right there on my screen. The fix was probably three sentences. And yet — copy, switch tab, paste, wait, read, switch back. Every single time.
So I built Croma. A Chrome extension that lives in a dark sidebar and watches what you're doing — explains selected code, catches console errors before you've even seen them, monitors failing API calls, and lets you ask questions about whatever page you're on.
No copy-paste. No alt-tab.
Here's how I built it, what tripped me up, and what I'd do differently.

What It Does

Four things, all automatic:

Select any code or text → the sidebar explains it
Console errors on localhost → caught and diagnosed without you doing anything
Failing or slow API requests → what went wrong and how to fix it
Ask anything about the page → manual Q&A in the footer input

The goal was zero friction. You're debugging, you see something confusing, and the answer is already appearing before you've consciously decided to ask.

It works on any page — docs, GitHub, your own localhost. Here it is on the AWS EC2 docs:

And here it is explaining a GitHub file mid-browse:

Tech Stack

Part	Choice	Why
UI framework	Preact	~3kb, React-compatible, perfect for content scripts
Build tool	Vite + CRXJS	HMR for extensions during dev
Sidebar isolation	Shadow DOM	No CSS bleed from host page
API streaming	Raw fetch + SSE	No SDK bloat, works in service workers
Styling	Inline CSS string	Shadow DOM makes Tailwind painful

I'll be honest — I reached for React first, saw it was 45kb, and immediately switched to Preact. For a content script that runs on every page you visit, bundle size is not a place to be casual.

The Architecture

Three pieces, separated by Chrome's extension boundary:

Content Script (content.tsx)
      ↕  chrome.runtime.sendMessage
Service Worker (service-worker.ts)
      ↕  chrome.tabs.sendMessage
Content Script (receives response)

The content script captures events — text selection, errors, fetch calls — and ships them to the service worker. The service worker hits the Anthropic or OpenAI API, streams the response back chunk by chunk, and the sidebar renders it live.

The sidebar state lives at module level using a simple imperative pattern:

let _setState: ((s: SidebarState) => void) | null = null
let _state: SidebarState = { ...initial }

function update(patch: Partial<SidebarState>) {
  _state = { ..._state, ...patch }
  _setState?.(_state)
}

export const sidebar = {
  show:  (feature: Feature) => update({ visible: true, feature, text: '', mode: 'loading' }),
  chunk: (text: string)     => update({ text: _state.text + text, mode: 'streaming' }),
  done:  ()                 => update({ mode: 'done' }),
  error: (msg: string)      => update({ text: msg, mode: 'error' }),
}

The component calls _setState = setS on render. External events drive it. No Redux, no context, no prop drilling — just a module-level state machine that the content script calls directly.

Streaming Without an SDK

The Anthropic TypeScript SDK is huge and wasn't designed with service workers in mind. I went raw instead:

async function readSSEStream(
  response: Response,
  tabId: number,
  extractText: (event: Record<string, unknown>) => string | null
) {
  const reader = response.body!.getReader()
  const decoder = new TextDecoder()
  let buffer = ''

  while (true) {
    const { done, value } = await reader.read()
    if (done) break

    buffer += decoder.decode(value, { stream: true })
    const lines = buffer.split('\n')
    buffer = lines.pop() ?? ''

    for (const line of lines) {
      if (!line.startsWith('data: ')) continue
      const data = line.slice(6).trim()
      if (data === '[DONE]') continue
      try {
        const event = JSON.parse(data) as Record<string, unknown>
        const text = extractText(event)
        if (text) chrome.tabs.sendMessage(tabId, { type: 'CHUNK', text })
      } catch {}
    }
  }

  chrome.tabs.sendMessage(tabId, { type: 'DONE' })
}

The key line is buffer = lines.pop() ?? ''. SSE chunks don't always split cleanly on newlines — a chunk can end mid-event. You always save the incomplete last line and prepend it to the next read.

The same function handles both Anthropic and OpenAI. You just pass a different extractText callback:

// Anthropic
(event) => event.type === 'content_block_delta' && event.delta?.type === 'text_delta'
  ? event.delta.text as string
  : null

// OpenAI
(event) => {
  const text = event.choices?.[0]?.delta?.content
  return typeof text === 'string' ? text : null
}

Shadow DOM for Isolation

The sidebar needs to float above every website without the host site's CSS breaking it. Shadow DOM is the clean solution:

const host = document.createElement('div')
host.style.cssText = 'position:fixed;top:0;left:0;width:0;height:0;z-index:2147483647;'
document.documentElement.appendChild(host)
const shadow = host.attachShadow({ mode: 'open' })
const mountPoint = document.createElement('div')
shadow.appendChild(mountPoint)
render(<SidebarApp />, mountPoint)

The host element is a zero-size anchor in the corner. The actual sidebar lives inside Shadow DOM, positioned fixed so it floats above everything. The host page's CSS resets, z-index wars, and overflow: hidden containers cannot touch it.

No iframe juggling, no chrome.runtime.getURL paths for HTML files, no cross-origin messaging required.

Catching Errors Before You See Them

The localhost error monitor patches three surfaces:

// Console errors
const _consoleError = console.error.bind(console)
console.error = (...args: unknown[]) => {
  _consoleError(...args)
  const msg = args.map(String).join(' ')
  if (msg.length < 10) return
  ask(`Fix this console error:\n${msg}`, 'error-fix')
}

// Runtime errors
window.addEventListener('error', (e) => {
  const info = [
    `Error: ${e.message}`,
    `File: ${e.filename}:${e.lineno}:${e.colno}`,
    e.error?.stack ? `Stack:\n${e.error.stack}` : '',
  ].filter(Boolean).join('\n')
  ask(`Fix this runtime error:\n${info}`, 'error-fix')
})

// Unhandled promise rejections
window.addEventListener('unhandledrejection', (e) => {
  const reason = e.reason instanceof Error
    ? `${e.reason.message}\n${e.reason.stack ?? ''}`
    : String(e.reason)
  ask(`Fix this unhandled promise rejection:\n${reason}`, 'error-fix')
})

Localhost only — you don't want this running on every website you visit. The console patch calls through to the original so DevTools still shows the error. It just also routes it to Claude simultaneously.

The Network Monitor

This one surprised me the most in practice. Wrap window.fetch:

const _fetch = window.fetch.bind(window)
window.fetch = async (...args: Parameters<typeof fetch>) => {
  const start = Date.now()
  const response = await _fetch(...args)
  const duration = Date.now() - start

  if (response.status >= 400 || duration > 1500) {
    const url = typeof args[0] === 'string' ? args[0] : (args[0] as Request).url
    const method = (args[1]?.method ?? 'GET').toUpperCase()
    const clone = response.clone()
    const body = await clone.text().catch(() => '').then((t) => t.slice(0, 400))

    const prompt = response.status >= 400
      ? `API request failed:\n${method} ${url}\nStatus: ${response.status}\nResponse body: ${body}\n\nWhy did this fail and how do I fix it?`
      : `API request is slow (${duration}ms):\n${method} ${url}\nStatus: ${response.status}\n\nWhat's likely causing the slowness and how do I optimize it?`

    ask(prompt, 'network-explain')
  }

  return response
}

The 1500ms threshold catches sluggish endpoints you might not notice in the Network tab until you specifically go looking. The response.clone() is required — you cannot read a response body twice, so you clone it before passing the original back to the caller.

The Bug That Took Longest to Track Down

CRXJS generates a loader file with this line:

})().catch(console.error)

When you reload the extension or navigate, the extension context gets invalidated and this fires — printing a red "Extension context invalidated" error to the console on every page load. Harmless in practice, but alarming to look at and embarrassing to ship.

The fix is a postbuild script:

// scripts/postbuild.mjs
const files = await readdir(assetsDir)
for (const file of files) {
  if (!file.includes('-loader-') || !file.endsWith('.js')) continue
  const path = join(assetsDir, file)
  const content = await readFile(path, 'utf8')
  const patched = content.replace(
    /\}\)\(\)\s*\.\s*catch\s*\(\s*console\s*\.\s*error\s*\)/g,
    '})().catch(() => {})'
  )
  if (patched !== content) {
    await writeFile(path, patched)
    console.log(`Patched: ${file}`)
  }
}

Getting that regex right — especially the \(\) for the IIFE invocation — took two tries. The first version didn't match and I spent fifteen minutes wondering why the console was still yelling at me.

What I'd Do Differently

Rate limiting. Right now if you rapidly select text it fires multiple simultaneous API calls. A simple abort-previous-in-flight would fix this and make it feel tighter.

The devtools panel. I built a network inspector and a // @croma comment evaluator that runs in the context of the inspected page. The fundamentals work but the polish isn't there yet.

Smarter selection detection. The 600ms debounce timer works, but occasionally fires on accidental swipes across text. A minimum word count check or movement distance check would reduce false positives.

How to Run It

git clone https://github.com/arishsingh/croma
cd croma
npm install
npm run build

Then in Chrome:

Go to chrome://extensions
Enable Developer mode
Click "Load unpacked" → select the dist/ folder
Click the Croma icon → paste your Anthropic or OpenAI API key

Works on any page. Most useful on localhost while you're actively building something — open a Next.js dev server, trigger an error, and watch the sidebar explain it before you've moved your hand to the keyboard.

How I Built One

Arish singh — Sat, 30 May 2026 22:53:07 +0000

AI Platform That Turns Your Resume Into Proof that You Can Actually Code so Resume says "React developer." One proves it.

Every developer has been there. You spend 3 hours polishing your resume, listing every framework you've ever opened a tutorial for, and then a recruiter spends 6 seconds scanning it. Interviews test LeetCode algorithms you'll never use on the job. Nobody actually verifies if you can build things.

I got tired of that. So I built One an AI platform that parses your resume, generates a personalized Proof-of-Work assessment from your actual stack, gives you a real-time voice mentor, and builds a 6-month career roadmap from a conversation. All in one workspace.

What I Built

One is a full-stack AI developer career platform. Here's the core loop:

Upload your resume PDF → GPT-4o extracts your real skills (not the company's skills, yours)
Take a Proof-of-Work assessment → 27 auto-generated questions across MCQ, coding, system design, and workflow
Talk to Keri → a voice AI mentor powered by OpenAI Realtime API that knows your scores and stack
Get a 6-month roadmap → generated from your actual conversation with Keri, not a template

Tech stack:

Next.js 16 (App Router, Turbopack)
Supabase SSR for authentication
OpenAI GPT-4o for resume parsing, chat, and roadmap generation
OpenAI Realtime API (gpt-4o-realtime-preview) over WebRTC for voice
Tailwind CSS v4 + shadcn/ui + Framer Motion
Deployed on Vercel

What It Actually Does

Parses resume PDFs and extracts only skills the candidate personally used ignores technologies listed in employer descriptions
Generates exactly 27 questions: 20 MCQ + 3 coding challenges + 2 system design + 2 workflow questions, all tied to the candidate's actual projects
Scores each skill area and renders a visual skill graph
Opens a real-time voice session with Keri no audio round-tripping, sub-second response
After the conversation, generates a structured 6-month learning roadmap with hours-per-month estimates and an active month marker
Fully auth-gated with per-user data isolation no shared state between accounts
Supports email signup, Google OAuth, and GitHub OAuth, all without email confirmation friction

Key Features

Resume-aware question generation every question references the candidate's specific projects and stack
Voice mentor with full context Keri reads your resume skills, test scores, and roadmap before speaking
WebRTC voice, not REST — audio goes directly browser → OpenAI, the server is never in the audio path
Roadmap from conversation talk to Keri, then one button generates your personalized plan
Zero email confirmation server-side admin API creates users with email_confirm: true
Per-user localStorage isolation switching accounts clears previous user's data automatically
Route protection on every request proxy.ts verifies Supabase session before any page renders
Non-resume detection if you upload a hostel form or invoice, One tells you instead of inventing skills

How I Built It

Resume Parsing: Getting GPT-4o to Stop Lying

The naive approach "here's a PDF, what are the skills?" doesn't work. GPT-4o will happily extract every technology mentioned in every job description the candidate ever worked near. That's not the candidate's skill set, that's their employer's stack.

I used OpenAI's Files API to upload the PDF, then hit gpt-4o with a two-step prompt:

const PROMPT = `You are analyzing a document to determine if it is a DEVELOPER/ENGINEER
technical resume and generate a personalized coding assessment.

STEP 1 — Is this a developer resume?
A valid developer resume MUST contain ALL of the following:
- Personal work experience (jobs, internships, freelance) OR personal projects built by the candidate
- At least 3 distinct programming languages, frameworks, libraries, or technical tools used BY THE CANDIDATE

If NOT a valid developer resume, return ONLY:
{ "not_resume": true, "skills": [], "title": "", "questions": [] }

STEP 2 — If valid, return ONLY:
{
  "not_resume": false,
  "skills": ["skill1", "skill2", ...],
  "title": "TopSkill · SecondSkill",
  "questions": [
    { "type": "mcq", "skill": "React", "q": "...", "opts": [...], "a": 0 },
    { "type": "coding", "skill": "JavaScript", "q": "...", "answer": "..." },
    { "type": "system-design", "skill": "System Design", "q": "...", "answer": "..." },
    { "type": "workflow", "skill": "Architecture", "q": "...", "answer": "..." }
  ]
}`;

Step 1 is a gate. If the document doesn't have personal work experience AND 3+ personal skills, it short-circuits and never generates questions. Step 2 has an explicit instruction to extract only skills the candidate personally used.

Then I added a server-side guard on top of the model's own judgment:

// Treat as not-a-resume if: model flagged it, too few skills, or no questions generated
if (parsed.not_resume || skills.length < 3 || questions.length < 5) {
  return NextResponse.json({ not_resume: true, skills: [], title: "", questions: [] });
}

The model can lie. The guard catches it.

One more gotcha: OpenAI's response_format: { type: "json_object" } throws a 400 if the word "json" doesn't appear anywhere in your messages. Took me longer than I want to admit to figure that one out.

Voice AI: WebRTC in Next.js Without Losing Your Mind

Keri uses OpenAI's Realtime API for sub-second voice responses. The architecture matters here — you do not want your server in the audio path. That adds latency and cost. The right flow is:

Browser → (SDP offer) → Next.js server → OpenAI /v1/realtime
OpenAI → (SDP answer) → Next.js server → Browser
Browser ←→ OpenAI (direct WebRTC audio, server out of the loop)

The session endpoint creates a short-lived token:

// /api/realtime/session
const res = await fetch("https://api.openai.com/v1/realtime/sessions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${key}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "gpt-4o-realtime-preview",
    voice: "shimmer",
  }),
});

The SDP endpoint forwards the browser's WebRTC offer to OpenAI and returns the answer:

// /api/realtime/sdp
const sdpOffer = await req.text();

const res = await fetch("https://api.openai.com/v1/realtime?model=gpt-realtime-2", {
  method: "POST",
  body: sdpOffer,
  headers: {
    Authorization: `Bearer ${key}`,
    "Content-Type": "application/sdp",
  },
});

const answerSdp = await res.text();
return new Response(answerSdp, { status: 200, headers: { "Content-Type": "application/sdp" } });

After the SDP handshake, the server is completely out of the audio path. The browser and OpenAI talk directly over WebRTC. That's why the latency is low — there's no proxy in the middle.

Keri's Context: A Mentor Who Knows You

The thing that makes Keri feel different from a generic chatbot is that she has real data about you injected into every conversation:

const ctxLines: string[] = [];

if (context.skills?.length) {
  ctxLines.push(`Resume skills: ${context.skills.join(", ")}`);
}
if (context.skillScores?.length) {
  const sorted = [...context.skillScores].sort((a, b) => b.v - a.v);
  ctxLines.push(
    `PoW test scores: ${sorted.map((s) => `${s.k} ${s.v}%`).join(", ")}`
  );
}
if (context.roadmap?.length) {
  const rm = context.roadmap.map((m) => {
    const tag = m.active ? " ← CURRENT" : m.done ? " [done]" : "";
    return `Month ${m.month} · ${m.title}: ${m.topics.join(", ")}${tag}`;
  }).join("\n");
  ctxLines.push(`6-month roadmap:\n${rm}`);
}

Every message to GPT-4o carries the user's actual resume skills, their exact test scores sorted by performance, and their current roadmap status. When you ask "what should I work on?", Keri doesn't guess — she looks at your lowest score and your next roadmap month and gives you a specific answer.

Auth: Skipping Email Confirmation Without Disabling Security

Supabase's default signup flow sends a confirmation email before the user can log in. That's terrible UX for an assessment tool where you want people in the app immediately.

Supabase used to have a UI toggle for this. They removed it. The workaround is the admin API:

// /api/auth/register
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

const { data, error } = await supabase.auth.admin.createUser({
  email,
  password,
  email_confirm: true,  // skip verification entirely
  user_metadata: { full_name: name, organization: org ?? "" },
});

The register page calls this server-side endpoint, then immediately signs in the user with signInWithPassword. No email. No waiting. Just in.

Per-User Data Isolation

One stores resume data, test scores, and roadmap state in localStorage. The problem: if user A logs in after user B on the same browser, they'd see B's data.

The fix is a user ID sentinel key:

const storedUserId = localStorage.getItem("one-current-user");

if (storedUserId !== currentUserId) {
  // Different user — clear everything
  const keysToRemove = Object.keys(localStorage).filter((k) => k.startsWith("one-"));
  keysToRemove.forEach((k) => localStorage.removeItem(k));
  localStorage.setItem("one-current-user", currentUserId);
}

And to make sure no React state from the previous user survives, the entire dashboard remounts using a key prop tied to the user ID:

<main key={userId || "anon"}>
  {/* VoiceAgentPage, ChatbotPage, ResumePage all remount on user change */}
</main>

A React key change forces a full unmount → remount cycle. No stale state, no data bleed between accounts.

Route Protection: Zero Flash of Dashboard

The most important UX requirement: unauthenticated users cannot see a single frame of the dashboard. Not even for 200ms.

Next.js 16 with Turbopack uses proxy.ts (not middleware.ts — having both breaks the build with a conflict error). Every request hits this file first:

const { data: { user } } = await supabase.auth.getUser();

if (!user && !isPublic) {
  const url = request.nextUrl.clone();
  url.pathname = "/login";
  url.searchParams.set("next", pathname);
  return NextResponse.redirect(url);
}

getUser() verifies the JWT with Supabase's servers — it's not just reading a cookie, it's an actual session check. If there's no valid session, the redirect happens before Next.js renders a single byte of the page. The authChecked state in the dashboard is a second layer: the component renders a black screen until the client-side session check confirms.

Roadmap Generation From a Conversation

After talking to Keri, one button generates a structured 6-month learning plan. The model gets the full conversation history and produces a typed JSON object:

const ROADMAP_PROMPT = `You are analyzing a mentoring conversation to generate a
personalized 6-month learning roadmap with working hours.

Return ONLY:
{
  "months": [
    {
      "month": 1,
      "title": "Short title (2-4 words)",
      "focus": "One-line focus statement",
      "topics": ["topic1", "topic2", "topic3"],
      "hours": 40,
      "done": false,
      "active": false
    }
  ]
}

Rules:
- Exactly 6 months, current → 6 months ahead
- Tailor to what the user mentioned: stack, goals, struggles
- "active": true for the one month to focus on RIGHT NOW (only one)
- "done": true for skills already mastered`;

The roadmap uses gpt-4o-mini (cheaper, fast enough for structured JSON) with response_format: { type: "json_object" }. The conversation history is passed directly as messages — no summarization, just the full context.

Lessons Learned

The hardest bugs are prompt bugs, not code bugs.
The resume parser would occasionally invent plausible-looking skills for a PDF that was clearly not a resume. A hostel admission form returned "JavaScript, Python, React" because those words appeared somewhere in the document. The fix wasn't adding more validation code — it was restructuring the prompt to evaluate the document type before attempting skill extraction. A two-step prompt is slower but dramatically more accurate.

Next.js 16 Turbopack has quirks that aren't documented yet.
Having both middleware.ts and proxy.ts in the project root causes a hard build error: "Both middleware.ts and proxy.ts detected." The error message is clear enough, but there's almost nothing about this online because the convention is new. When you hit an undocumented framework error, check the framework version first — the answer is almost always a breaking change from a recent release.

WebRTC in a serverless environment means your server does almost nothing.
The intuition is: real-time audio needs a persistent server. In practice, with OpenAI's Realtime API, your server only handles the SDP handshake (two HTTP requests). Everything after that is peer-to-peer. Serverless functions are completely fine for this pattern.

response_format: { type: "json_object" } will silently break if you don't say "json."
OpenAI's API throws a 400 Bad Request with the message 'messages' must contain the word 'json' if you use JSON mode without the word "json" appearing somewhere in your prompt. After a refactor removed that word from my prompt text, the endpoint broke in production with an error I'd never seen before. Add "Return only a JSON object" to every prompt that uses JSON mode — not just to satisfy the API, but as good practice.

Force-push rewrites git history but GitHub's contributor cache is slow.
After rewriting all commits to remove Co-Authored-By trailers and force-pushing, the Contributors panel on GitHub still showed the old co-author for hours. The code was fixed; the cache just hadn't expired. GitHub's contributor computation runs on a delay — nothing to do but wait.

What's Next

One is live at onee-eight.vercel.app. The core loop works end-to-end. What I'm building next:

Shareable PoW cards — a public URL with your verified skill scores you can attach to job applications instead of a resume
Employer view — companies post a role, One surfaces candidates ranked by actual test performance in that stack
Progressive retesting — take the same assessment monthly and track skill growth over time on the skill graph
Team assessments — evaluate an entire engineering team and surface collective gaps by skill area

The core insight hasn't changed: resumes are promises. Proof-of-Work is evidence. The goal is to make the evidence the default.

Built with Next.js 16, Supabase, OpenAI GPT-4o, OpenAI Realtime API, Tailwind CSS v4, and shadcn/ui.

— Arish singh

Monitoring the Cloud: Learning CloudWatch

Arish singh — Tue, 02 Sep 2025 22:20:14 +0000

When you move applications to the cloud, the biggest challenge is not just deploying them but ensuring they stay reliable, performant, and cost-efficient. In modern architectures, applications are distributed across servers, databases, APIs, and containers. Without proper monitoring, problems often go unnoticed until customers start complaining.
This is where Amazon CloudWatch comes in. CloudWatch is AWS’s native monitoring and observability service. It helps you collect, visualize, and act on data about your infrastructure and applications. Let’s dive deep into how it works, why it matters, and how it applies to real-world use cases.

** What is Amazon CloudWatch?**

Amazon CloudWatch is a comprehensive observability platform that provides system-wide visibility into applications, infrastructure, and network activity. It collects data in three main forms:

Metrics → Numbers that represent performance over time.
Logs → Event data that records activity.
Traces & Insights → End-to-end visibility into distributed systems.

The goal is simple: to enable proactive monitoring. Instead of finding out about downtime from users, CloudWatch helps developers and operators detect, analyze, and resolve issues early.

Analogy: Running without CloudWatch is like driving a car without a speedometer, fuel gauge, or warning lights. You wouldn’t know if you’re running out of fuel or overheating until the car breaks down. CloudWatch is that dashboard of gauges and warning signals for your cloud.

** Core Components of CloudWatch**

1. Metrics

Metrics are the heartbeat of CloudWatch. They are numerical data points that represent resource or application performance. AWS automatically provides basic metrics such as:
EC2 CPU utilization
Lambda function duration
S3 bucket request counts

You can also publish custom metrics like the number of active users in your app.

Real-world example: In a food delivery app, metrics could track order-processing time, rider availability, and server response latency. During dinner rush hours, these metrics help ensure the system scales properly.

2. Dashboards

CloudWatch Dashboards allow you to visualize multiple metrics and logs in one place. These dashboards can be customized per team or per use case.
Real-world example: For a video streaming service, a dashboard may show:
Playback success rate per region
Buffering time per user session
Server load per data center
This unified view helps engineers quickly detect regional issues, like slow playback in Europe but smooth streaming in North America.

3. Alarms

Alarms continuously evaluate metrics against thresholds and trigger actions when breached. These actions can include:
Sending notifications via SNS
Triggering a Lambda function
Scaling out infrastructure automatically

Real-world example: In a ride-hailing app, if API latency goes above 2 seconds, an alarm could automatically scale up more servers. At the same time, it might notify the engineering team on Slack.
**
🔍 Advanced Capabilities**

4. Application Performance Monitoring (APM)

CloudWatch provides Application Signals to track KPIs such as request latency, error rates, and throughput.
Synthetics Canaries simulate user interactions with APIs or endpoints.

SLOs (Service Level Objectives) let you define targets like “99.9% uptime” and track error budgets.

Real-world example: In a banking app, CloudWatch Synthetics can simulate fund transfers every few minutes. If the API slows down, the system alerts the team before real customers are affected.

5. Infrastructure Insights

CloudWatch provides specialized monitoring for different AWS environments:
Database Insights: Monitor queries, transaction latency, and DB load.
Lambda Insights: Track execution duration, memory usage, and cold starts.
Container Insights: Monitor ECS/EKS workloads and microservices metrics.

Real-world example: An online ticket booking site during a movie release can use Database Insights to catch slow SQL queries that might delay seat reservations.

6. Logs & Querying

CloudWatch Logs centralize logs from across AWS services. With CloudWatch Logs Insights, you can run queries to analyze patterns and troubleshoot faster.

Real-world example: In a gaming platform, developers can query logs to see login failure counts in the last 15 minutes. If failures spike in one region, it signals a potential outage.

7. Cross-Account & Centralized Monitoring

Large organizations often split workloads across multiple AWS accounts. CloudWatch supports central dashboards and alarms that pull data across accounts.

**Real-world example: **A hospital chain may run separate accounts for each branch. CloudWatch lets IT teams monitor all accounts centrally to ensure consistent uptime for telemedicine services.

8. Network & Internet Monitoring

CloudWatch can monitor both internal AWS networks and the public internet. It helps determine if performance issues are caused by AWS infrastructure or third-party ISPs.

Real-world example: A global e-commerce platform detects that checkout latency in Europe isn’t caused by AWS servers but by congestion at a regional ISP. This saves hours of false troubleshooting.

⚡ Why CloudWatch Matters
CloudWatch is crucial because it transforms monitoring from a reactive process into a proactive one. Instead of relying on customer complaints, you gain the ability to:
Detect problems early with metrics and alarms.
Respond automatically through scaling and automation.
Optimize performance using logs and application insights.
Build trust by meeting** SLOs and SLAs** consistently.

** Real-World Case Studies**

Amazon Prime Day: CloudWatch automatically scales servers to handle millions of users logging in at midnight. Without it, the website would crash under load.
Healthcare Telemedicine: CloudWatch Synthetics monitor “Start Video Call” APIs, alerting engineers if latency rises before patients experience disruptions.
Ride-Sharing Surge Nights: On New Year’s Eve, CloudWatch scales resources dynamically, keeping driver-rider matching responsive during peak demand.

** Conclusion**
AWS CloudWatch is not just a tool—it’s the nervous system of your cloud ecosystem. By collecting data, providing insights, and automating responses, it ensures that systems remain reliable and user experiences stay smooth. Whether you’re building e-commerce platforms, banking apps, or streaming services, CloudWatch helps you run them with confidence.

                           thank you by Arishsingh

AWS Security 101

Arish singh — Sun, 03 Aug 2025 10:43:46 +0000

About the Project
AWS Security 101 is an interactive chatbot-based learning assistant designed to introduce beginners to foundational AWS security practices. The bot provides real-time explanations, guided labs, interactive quizzes, and curated resources to help learners build strong fundamentals in securing AWS environments. It simplifies concepts like IAM, encryption, monitoring, and compliance, making them digestible for non-experts.

🤔 Why I Built This
As a student and cloud enthusiast, I noticed a major gap: many beginners dive into AWS without truly understanding how to secure what they build. Misconfigured IAM roles, public S3 buckets, or lack of monitoring can easily lead to vulnerabilities. I wanted to build something that:
Teaches security first, not as an afterthought.
Encourages hands-on exploration of AWS best practices.
Acts as a friendly assistant—like a mentor—available 24/7.
This project is especially helpful for students, developers, and early cloud learners who want to understand security concepts in a simple and interactive way.

🛠️ How I Built This
Amazon Q (or Amazon Lex) powers the conversational experience, letting users ask questions and get clear, actionable answers.
AWS Lambda handles backend logic to fetch resources, generate quizzes, and suggest labs dynamically.
DynamoDB is used to store user progress, quiz scores, and logs securely.
Amazon S3 stores educational content like PDFs, cheat sheets, and interactive diagrams.
CloudWatch tracks bot usage and monitors user interactions for improvements.
IAM roles and policies are applied to create secure access boundaries within the application itself—making the bot a learning tool and a working demo of AWS security best practices.

📘 What is AWS Security 101?
"AWS Security 101" is a foundational guide to securing AWS environments. It covers:
🔑 Identity & Access Management (IAM)
🧱 Data Encryption using KMS, S3 encryption, etc.
🌐 Network Security – VPC, Security Groups, and NACLs
🛡️ Threat Detection & Monitoring – using CloudTrail, GuardDuty, CloudWatch
📜 Compliance & Governance
📦 Least Privilege Principle and secure-by-design workflows
It’s not a certification course—but it helps you build the mindset to protect your cloud resources from Day 1.

✨ Key Features
📖 Conversational Learning Bot: Ask questions, explore topics, and get guidance in real time.
🧪 Interactive Labs: Step-by-step instructions on real AWS consoles.
🧠 Quiz Mode: Learn by doing — test your concepts with dynamically generated quizzes.
💡 Daily Security Tips: Automatically fetches and displays AWS security news or practices.
🧾 Progress Tracking: Stores quiz scores and recommends next steps.
🌐 Multi-device Friendly UI: Runs smoothly on desktop and mobile via chatbot dashboard.

🧰 Tech Stack
Category Tool/Service
Chatbot Engine Amazon Q / Amazon Lex
Backend AWS Lambda, API Gateway
Storage Amazon S3, DynamoDB
Monitoring Amazon CloudWatch
Identity AWS IAM (Roles, Policies)
Voice Support Amazon Polly, Amazon Transcribe
Hosting AWS Amplify / S3 Static Hosting

🔄 Workflow Overview
User → Chatbot Interface → Amazon Q / Lex
↓
Query Handled by AWS Lambda
↓
Lambda fetches content (S3), updates DB (DynamoDB), or processes quiz
↓
Response sent back to chatbot
↓
User can also receive links to labs, voice explanations (Polly), or PDFs

📦 Project Repository
🔗 GitHub Repo: AWS-Security-101-Bot :->

https://github.com/Arishsingh/AWS-Security-101.git

Amazon Q Developer CLI

Arish singh — Thu, 17 Jul 2025 18:05:58 +0000

About the Project

Amazon Q Developer CLI is a powerful generative AI tool by AWS that allows developers to build real, working code directly from natural language prompts via the command line. Instead of manually writing boilerplate code or setting up entire projects from scratch, you can simply describe what you want—like "create a React app with a login form" or "build a Sudoku game in HTML, CSS, and JavaScript"—and Amazon Q CLI instantly generates the full project structure and code files for you. It supports multiple languages and frameworks, including JavaScript, Python, HTML/CSS, and more, making it ideal for frontend, backend, cloud, and DevOps tasks. Designed to accelerate developer productivity, Amazon Q CLI bridges the gap between ideas and implementation, acting like an AI-powered coding partner that helps you move faster and focus on logic rather than repetitive setup.

💡 Why I Built This

I've always loved quick logic games and was curious to see how fast I could go from idea → playable game with Amazon Q.

Here’s what motivated me:

✨ To experiment with AI coding tools in real-time
⏱️ To challenge myself with a 30-minute build
🎮 To recreate a childhood favorite puzzle digitally
🔍 To explore how natural language prompt-based coding actually works

⚙️ How I Built This

I used Amazon Q Developer CLI to prompt the system with:

"Build a playable Sudoku game with a 9x9 grid using HTML, CSS, and JavaScript."

And boom — within seconds, it generated:

📄 A full HTML layout for the game grid
🎨 CSS styles for layout and spacing
🧠 JavaScript logic for interaction and cell validation

After that, I did:

Minor edits to the styles
Added some clean UI polish
Tested it live in the browser

🧩 What is Sudoku?

For those unfamiliar, Sudoku is a classic number-based logic puzzle.

🎯 The goal:

Fill the 9x9 grid so that:
- ✅ Each row contains digits 1–9 without repetition
- ✅ Each column contains digits 1–9 without repetition
- ✅ Each 3x3 subgrid contains digits 1–9 without repetition

It’s logic-heavy, satisfying, and surprisingly addictive. 😉

🌟 Key Features

🎮 Interactive 9x9 Sudoku Grid
🧠 Logic-based number placement
✨ Clean, responsive UI with basic CSS
⚡ Built entirely using Amazon Q Developer CLI
💻 Works on both desktop and mobile browsers

🔧 Tech Stack

HTML5 for structure
CSS3 for layout & styling
Vanilla JavaScript for logic and validation
Amazon Q Developer CLI for prompt-to-code generation
(Coming Soon!) Hosted on AWS

🔄 Workflow Overview

💡 Thought of building a quick logic game
✍️ Described the project in simple English
🤖 Let Amazon Q generate the full codebase
🧪 Tested & polished the output
🚀 Shared it with the world!

📂 Project Repository

🧪 Try it locally:

git clone https://github.com/Arishsingh/AmazonQ.git

DEV Community: Arish singh

How I Built Velocity — An AI Platform That Turns Plain English Into Production-Grade n8n Workflows

ai #n8n #nextjs #showdev

What I Built

System Architecture

How I Built It

The System Prompt Is the Product

One Contract, Two Routes — Killing Prompt Drift

Surviving the Free Tier: A Model Failover Chain

Parsing JSON From a Model That Doesn't Always Return JSON

Auth: Let Postgres Enforce Ownership, Not Your Route Code

Redis: Always a Cache, Never the Truth

One-Click Deploy: Closing the Loop

Problems I Faced (aka Lessons Learned)

What's Next

Nexa - platform to understand any codebase

What I Built

What It Actually Does

Key Features

How I Built It

The Graph Renderer: Why Canvas, Not SVG

GitHub Auth: provider_token Is the Whole Solution

Fetching Repos: One API Call for Everything

The File Tree: One Request, Any Depth

AI Analysis: Streaming Claude Over the Repo Tree

Lessons Learned

What's Next

Built a Chrome Extension That Watches my Dev Tab and Explains Everything

about Croma

What It Does

Tech Stack

The Architecture

Streaming Without an SDK

Shadow DOM for Isolation

Catching Errors Before You See Them

The Network Monitor

The Bug That Took Longest to Track Down

What I'd Do Differently

How to Run It

Links

How I Built One

What I Built

What It Actually Does

Key Features

How I Built It

Resume Parsing: Getting GPT-4o to Stop Lying

Voice AI: WebRTC in Next.js Without Losing Your Mind

Keri's Context: A Mentor Who Knows You

Auth: Skipping Email Confirmation Without Disabling Security

Per-User Data Isolation

Route Protection: Zero Flash of Dashboard

Roadmap Generation From a Conversation

Lessons Learned

What's Next

Monitoring the Cloud: Learning CloudWatch

AWS Security 101

Amazon Q Developer CLI

About the Project

💡 Why I Built This

⚙️ How I Built This

🧩 What is Sudoku?

🌟 Key Features

🔧 Tech Stack

🔄 Workflow Overview

📂 Project Repository

🧪 Try it locally:

GitHub Auth: `provider_token` Is the Whole Solution