Forem: Vishwajeet Kondi

Meta-Frameworks Are Taking Over Frontend (And Most Devs Don’t Even Notice)

Vishwajeet Kondi — Wed, 01 Apr 2026 11:51:43 +0000

If you’re still starting projects with plain React…
you’re already a bit behind.

Not because React is bad.
But because the ecosystem has moved ahead.

Welcome to the era of meta-frameworks.

What is a meta-framework?

A framework on top of a framework.

Not just UI (like React), but also:

routing
data fetching
backend APIs
rendering (SSR, SSG, etc.)
performance optimizations

All in one place.

Examples:
Next.js · Nuxt · Remix · SvelteKit · Astro

Why they took over

Frontend got too complex.

Before:

pick a router
setup Webpack
manage state
figure out SSR

Basically… build your own system.

Now?

One command → everything just works.

The real shift

Frontend is no longer just “frontend”.

Your frontend is also your backend.

You now have:

API routes inside frontend
server-side logic next to UI
server components & edge functions

React apps are no longer just client-side.

Performance forced this

SPAs had problems:

slow initial load
poor SEO
too much JS

So we moved back to:

server rendering
static generation
hybrid rendering

Meta-frameworks handle this by default.

This isn’t a small trend

Next.js powers 50%+ React apps
~68% of new apps prefer it over plain React
Meta-frameworks are now the default for scalable apps

Developers are clearly moving toward integrated ecosystems instead of assembling tools.

Less JS is the new goal

Do more on the server, ship less to the browser.

Result:

faster load
better UX
better performance

Architecture changed

Old:


Browser (SPA)
↓
API
↓
DB

New:


Server + Edge
↓
Minimal JS
↓
Faster UI

👉 Less browser work

👉 More server work

Not all meta-frameworks are the same

Full-stack
Next.js, Nuxt → everything in one place

Server-first
Remix, SvelteKit → closer to web fundamentals

Content-first
Astro → almost zero JS

Are they perfect?

Pros

faster setup
better defaults
less decision fatigue

Cons

more abstraction
breaking changes
some lock-in

The bigger shift

This isn’t about tools.

It’s frontend → full-stack systems.

Final thought

The question is no longer:

“Can you build a React app?”

It’s:

“Can you design systems using a meta-framework?”

How the Browser Rendering Pipeline Actually Works

Vishwajeet Kondi — Thu, 12 Mar 2026 12:56:52 +0000

Most frontend developers spend their time inside frameworks like React, Vue, or Angular. But underneath every framework is the same system: the browser turning code into pixels on a screen.

This process is known as the browser rendering pipeline (or the critical rendering path).

In simplified terms:

HTML → DOM
CSS → CSSOM
DOM + CSSOM → Render Tree
Render Tree → Layout
Layout → Paint
Paint → Composite

Understanding this pipeline explains many real-world performance issues that developers encounter.

1. HTML Parsing → DOM Construction

The browser begins by parsing HTML and converting it into the Document Object Model (DOM), a tree structure representing the page.

Example HTML:

<body>
  <h1>Hello</h1>
  <p>Welcome</p>
</body>

DOM representation:

Document
 └── body
      ├── h1
      └── p

Browsers stream-parse HTML, meaning they start building the DOM before the entire document is downloaded.

However, JavaScript can interrupt this process. When the parser encounters a blocking script:

<script src="app.js"></script>

DOM construction pauses while the script executes. This is why script placement or using defer matters.

2. CSS Parsing → CSSOM Construction

While the DOM represents structure, CSS defines how elements should appear.

The browser parses CSS into the CSS Object Model (CSSOM).

Example CSS:

h1 {
  color: red;
}

The browser resolves:

the cascade
specificity
inheritance

Eventually, every element receives its computed styles.

3. DOM + CSSOM → Render Tree

The DOM alone isn’t enough to render a page. The browser merges the DOM and CSSOM to create a Render Tree, which contains only visible elements with their computed styles.

For example:

DOM:

body
 ├─ h1
 ├─ p
 └─ script

Render Tree:

body
 ├─ h1 (styled)
 └─ p (styled)

Elements such as <script>, <meta>, or elements with display: none are excluded.

The render tree represents what actually needs to be drawn.

4. Layout (Reflow)

Once the render tree is built, the browser calculates the geometry of each element. This stage is called layout (or reflow).

The browser determines:

width and height
position
spacing and box model calculations

Example:

h1 → x:0 y:0 width:800 height:40
p  → x:0 y:40 width:800 height:20

Layout can be expensive because a change in one element may affect many others. For example, changing a container’s width might require recalculating layout for the entire subtree.

5. Paint

After layout, the browser converts elements into drawing instructions.

Painting includes:

text
colors
borders
shadows
images

At this stage the browser determines how elements should be visually drawn, but pixels are not yet combined into the final frame.

6. Compositing

Modern browsers split the page into layers and send them to the GPU compositor.

Certain properties create separate layers, including:

transform
opacity
position: fixed
video
canvas

The GPU then combines these layers into the final image displayed on the screen.

This step is what enables smooth animations and efficient rendering.

The 16ms Frame Budget

Browsers aim for 60 frames per second, which means each frame must be processed within about 16 milliseconds.

Within that time the browser must run:

JavaScript
Style calculation
Layout
Paint
Composite

If the work exceeds this budget, the result is dropped frames and visible UI lag.

Not All CSS Changes Are Equal

Different CSS properties affect different stages of the pipeline.

Layout-triggering properties (expensive)
Examples: width, height, margin, top, left

Pipeline:

Style → Layout → Paint → Composite

Paint-only properties

Examples: background-color, border-color, box-shadow

Pipeline:

Style → Paint → Composite

Composite-only properties (fastest)

Examples: transform, opacity

Pipeline:

Style → Composite

This is why modern animation guidelines recommend using transform and opacity.

Why This Matters

Many developers blame frameworks when performance issues appear. In reality, problems usually come from:

excessive DOM updates
layout thrashing
expensive paint operations
overly complex render trees

Frameworks may change, but browser fundamentals remain the same.

Most developers think in terms of:

Components → State → UI

But the browser ultimately thinks in:

DOM → Style → Layout → Paint → Composite

Understanding that model is what separates framework users from true frontend engineers.

Oxfmt: The Prettier Compatible Formatter That's 30x Faster

Vishwajeet Kondi — Wed, 18 Feb 2026 12:05:17 +0000

Remember Part 1 where we talked about Oxlint being stupidly fast? Well, buckle up because Oxfmt (the formatter) is even more ridiculous.

We're talking 30x faster than Prettier. Not a typo. Thirty times.

But speed isn't everything. Prettier works. It's stable. It's everywhere. So the real question isn't "is Oxfmt fast?" it's "is it fast enough to justify the risk of switching?"

Let's find out.

What Is Oxfmt?

Oxfmt is a code formatter built by the same VoidZero team that made Oxlint. Written in Rust, runs on the Oxc parser (same one Oxlint uses), and targets 95%+ compatibility with Prettier.

Key phrase: targets compatibility. Not "reinvents formatting" like Biome. Not "has its own opinions" like dprint. Oxfmt's goal is to be Prettier, but faster.

Announced in December 2025, currently in alpha. Early, but with receipts.

The Performance Numbers (With Sources)

All numbers from Oxc's official formatter benchmark repo.

Large single file (TypeScript compiler's parser.ts, ~540KB):

oxfmt:                  104ms
Biome:                  136ms (1.3x slower)
prettier+oxc-parser:    710ms (6.8x slower)
prettier (default):     1.04s (10x slower)

Mixed repository (Storybook):

oxfmt:              16.6s
prettier+oxc:       40.2s (2.4x slower)

Full features (Continue repository):

oxfmt:              9.2s
prettier+oxc:       56.8s (6.2x slower)

Memory usage (Outline benchmark):

prettier:       223.9 MB
oxfmt:          152.9 MB
Biome:          62.2 MB  ← Biome wins here

Worth noting: Biome is significantly more memory-efficient. Oxfmt is faster, but Biome is leaner. Official benchmarks put Oxfmt at roughly 30x faster than Prettier and 3x faster than Biome on initial runs without cache.

But Is It Actually Compatible?

This is the million-dollar question. If Oxfmt formats your code differently, migration becomes a nightmare of diffs.

Good news: Oxfmt passes ~95% of Prettier's JS/TS test suite. The remaining 5%? Some of it is intentional.

Example — array formatting consistency:

// Prettier (inconsistent)
const longer = [
  'item1', 'item2', 'item3' // breaks despite fitting
];

// Oxfmt (consistent)
const longer = ['item1', 'item2', 'item3']; // stays inline if it fits

The team is even submitting PRs to Prettier to converge on these edge cases, some landed in Prettier 3.7.

⚠️ Critical gotcha: Oxfmt defaults to printWidth: 100. Prettier defaults to 80. Migrate without setting this and you'll get massive diffs everywhere.

// .oxfmtrc.jsonc — set this FIRST
{
  "$schema": "./node_modules/oxfmt/configuration_schema.json",
  "printWidth": 80
}

Feature Comparison

Feature	Oxfmt (Alpha)	Prettier 3.7	Biome 2.0
Speed	30x faster	Baseline	3x faster
Prettier compatibility	95%+	100%	~70%
JS/TS/CSS/HTML	✅	✅	✅
Tailwind class sorting	Built-in ✅	Plugin	❌
Import sorting	Coming	Plugin	Built-in ✅
Vue/Svelte/Astro	Roadmap	Plugins	❌
Plugin support	Roadmap	✅	❌
Memory usage	152 MB	224 MB	62 MB
Production ready	No (alpha)	Yes	Yes

Oxfmt's built-in Tailwind class sorting is a big deal if you're on Tailwind, no prettier-plugin-tailwindcss needed. But no Vue/Svelte/Astro support yet, and no plugin system. Both are on the beta roadmap.

Migration Strategies

Option 1: Full Replace

Best for: JS/TS-only projects, no Prettier plugins, willing to be early adopters

npm install -D oxfmt
npx oxfmt --migrate=prettier  # Auto-converts your Prettier config
npx oxfmt .

Trade-offs: 30x faster, built-in Tailwind sorting, 95% compatible, but alpha bugs exist, no plugins, no Vue/Svelte formatters.

Option 2: Hybrid (Local Speed, CI Safety)

Best for: Teams that want fast local formatting but aren't ready to commit

{
  "scripts": {
    "format": "oxfmt .",
    "format:ci": "prettier --check ."
  }
}

Run Oxfmt locally for instant feedback. Keep Prettier in CI as a safety net. Slightly wasteful running both, but it de-risks the migration considerably.

Option 3: Wait for Beta (Q1 2026)

Honestly the right call for most teams. The team has been upfront: "Oxfmt is in alpha and may not suit complex setups."

Beta is targeting Q1 2026 with import sorting, Vue/Svelte/Astro support, and a plugin system. If you're not hitting CI pain right now, wait.

Common Pitfalls

printWidth mismatch: The single biggest migration trap. Always set printWidth: 80 explicitly if migrating from Prettier.

Prettier plugins: prettier-plugin-organize-imports, @trivago/prettier-plugin-sort-imports, and similar won't work. Plugin system is on the beta roadmap.

Vue/Svelte/Astro files: Oxfmt skips them silently. Keep Prettier for those files until framework support lands.

When Should You Use It?

Choose Oxfmt if:

You need maximum speed (30x faster)
You use Tailwind heavily (built-in class sorting, no plugin needed)
You only format JS/TS/CSS/HTML
You're okay with alpha software and willing to file issues

Stick with Prettier if:

You rely on plugins (import sorters, framework formatters)
You need proven stability
Your pre-commit hooks run on thousands of files daily (alpha bugs = blocked commits)

Consider Biome if:

You want one unified tool for linting + formatting
Memory efficiency matters to you
You need stable Rust-based tooling today

The Bigger Picture: Full Oxc Stack

If you go all-in on Oxc, your entire pipeline shares the same parser. Lint and format without parsing your code twice.

// package.json
{
  "scripts": {
    "lint": "oxlint",
    "format": "oxfmt",
    "check": "oxlint && oxfmt --check"
  }
}

VoidZero's vision: "One toolchain for parse, lint, format, transform, bundle."

Not fully there yet, Oxfmt is alpha, Rolldown is still in development. But the direction is clear.

The Honest Take

Oxfmt is impressive. 30x faster than Prettier is real. Built-in Tailwind sorting removes a dependency. 95% compatibility makes migration feasible without a giant diff.

But it's alpha. If you're on a greenfield project and comfortable filing GitHub issues, try it. If you're running a production app with dozens of engineers, wait for beta. If Prettier works fine and CI isn't painful, there's genuinely no reason to change. Being boring with tooling is underrated.

The best formatter is the one that gets out of your way.

Try it yourself:

Questions? Hit bugs? Found edge cases? Drop them in the comments, community feedback shapes these tools early on.

Missed Part 1? Go read the Oxlint deep dive on why it's 50-100x faster than ESLint and when you should actually care.

Oxlint: JS Linter That's Actually Fast Enough to Matter

Vishwajeet Kondi — Sat, 14 Feb 2026 07:00:55 +0000

So here's the thing about my last Biome blog post, the comments section(on Reddit) turned into a mini war zone. Not the angry kind, thankfully. More like the curious kind. Everyone wanted to know about Oxlint and how it stacks up against Biome.

Fair enough. Let's talk about it.

What Even Is Oxlint?

Oxlint is a JavaScript/TypeScript linter written in Rust. It's part of this bigger thing called Oxc (Oxidation Compiler) that Evan You's company VoidZero is building. You know Evan, the guy who made Vue and Vite.

Reached v1.0 stable in June 2025 after about 18 months of development and help from 200+ contributors. It's not some side project anymore, companies like Shopify, Airbnb, Mercedes-Benz, Linear, and Framer are using it in production.

The pitch is simple: ESLint, but way faster. Like, ridiculously faster.

The Performance Numbers (With Receipts)

Okay, let's get into the benchmarks. I'm pulling these from Oxc's official benchmark repository so you can verify this yourself.

Oxlint vs ESLint vs Biome

Vue Core codebase (~900 files):

oxlint:     138ms
Biome:      377ms (2.7x slower than Oxlint)
ESLint:     28.6s (207x slower than Oxlint)

Yeah, you read that right. ESLint took almost 30 seconds. Oxlint? Under 140 milliseconds.

Outline repository (larger project):

oxlint:     150ms
Biome:      498ms (3.3x slower than Oxlint)
ESLint:     [They didn't even bother timing it]

According to their official benchmarks page, Oxlint is 50-100x faster than ESLint depending on how many CPU cores you have. The record? 264,925 files linted in 22.5 seconds, roughly 10,000 files per second.

Why Is It So Fast?

I know what you're thinking. "Rust is faster than JavaScript", yeah, we get it. But there's more to it.

Multi-threading: ESLint runs on a single thread. Oxlint uses all your CPU cores by default. 8-core machine? That's 8x parallelism, no configuration needed.

Shared parser: Oxlint and other Oxc tools share the same parser. Your code gets parsed once, then all tools work on the same AST. Compare that to ESLint + Prettier parsing your code twice.

No plugin overhead: ESLint loads each plugin separately. Oxlint has all rules built-in. No dependency hell, no initialization overhead.

Feature Comparison: Oxlint vs Biome

Feature	Oxlint 1.0	Biome 2.0
Speed	~10,000 files/sec	~5,000 files/sec
Built-in rules	670+	250+
ESLint plugin compat	Preview (experimental)	None
Type-aware linting	Alpha via tsgolint	Stable via Biotype
Formatting	Yes (oxfmt, alpha)	Yes (stable)
Single binary	No (separate tools)	Yes
Memory efficiency	Higher usage	Lower usage

Oxlint is roughly 2x faster than Biome at linting, has way more rules available, and supports some ESLint plugins (experimental). But Biome wins on memory usage and the "one tool does everything" philosophy.

The Type-Aware Linting Difference

Biome's approach: Custom type synthesizer (Biotype) reimplementing TypeScript's type checker in Rust. Single binary, no external dependencies, but every TS edge case must be reimplemented.

Oxlint's approach: Uses tsgo (Microsoft's Go port of TypeScript) via tsgolint. 100% TypeScript compatibility, all 40+ typescript-eslint rules, but requires two binaries and is still alpha.

Evan You said it best: "Biome's type-aware linting cannot guarantee full coverage or behavior alignment with official TS."

Biome's approach is more mature right now. Oxlint's tsgolint is still alpha. Pick your tradeoff.

Migration: How Hard Is It Really?

Option 1: Full Replace

Best for: Small to medium projects, greenfield codebases

npm install -D oxlint
npx @oxlint/migrate  # Auto-migrate ESLint config
npx oxlint

Trade-offs: 50-100x faster, simple config, but you might lose niche ESLint rules and custom plugins won't work yet.

Option 2: Parallel Approach (Recommended)

Best for: Large codebases, teams with heavy ESLint customization

This is what Mercedes-Benz did.

npm install -D oxlint eslint-plugin-oxlint

// eslint.config.js
import oxlint from 'eslint-plugin-oxlint';

export default [
  ...yourExistingConfig,
  oxlint.configs['flat/recommended'], // Prevents duplicate errors
];

"lint": "oxlint && eslint ."

Oxlint runs first (fast feedback <1s), ESLint catches what Oxlint missed. You get speed AND comprehensive coverage.

Note on type-aware linting: Oxlint's --type-aware flag (via oxlint-tsgolint) is still alpha. Unless you're okay with experimental software, keep typescript-eslint for now.

Common Pitfalls

Missing rules aren't obvious: Oxlint silently skips unsupported rules. Run both linters in parallel initially to catch gaps.

Custom ESLint plugins: JavaScript plugin support is in preview but not production-ready. Keep ESLint for custom rules.

Type-aware linting is alpha: Memory usage can spike, bugs exist. Stick with ESLint for type-aware rules until tsgolint stabilizes.

When Should You Actually Use Oxlint?

Choose Oxlint if:

You need maximum speed (2x faster than Biome, 50-100x faster than ESLint)
You want gradual migration (run alongside ESLint)
You need broad rule coverage (670+ rules)
You're in the Vite/Vue ecosystem (same team, shared tooling)

Don't choose Oxlint if:

You need stable type-aware linting today (use Biome or ESLint)
You rely heavily on custom ESLint plugins (experimental support)
You want one unified tool (Biome does linting + formatting)
You're risk-averse about tooling changes (ESLint is 13 years old, battle-tested)

The Honest Take

ESLint and Prettier have been amazing. They've served us well for over a decade. But they're built on JavaScript running in a single thread, and there's only so fast you can make that.

Biome proved that Rust-based tooling could work. Oxlint is pushing even harder on speed and ESLint compatibility.

Should you switch today?

If you're starting a new project and want to live on the edge, go full Oxlint. Just know you're an early adopter.

The best tool is the one that solves your actual problem. Run the benchmarks on your codebase. Check if it covers your rules. Then decide.

Next up: Part 2 where we'll dig into Oxfmt (the formatter) and how it compares to Prettier and Biome. Spoiler: it's fast. Really fast.

Try it yourself:

Got questions? Benchmarks from your codebase? Drop them in the comments. I actually read them (clearly, since that's why this post exists).

Biome: Replace ESLint + Prettier With One Tool

Vishwajeet Kondi — Tue, 10 Feb 2026 15:25:54 +0000

If you've spent any time in the JavaScript ecosystem, you know the drill: install ESLint, configure it, install Prettier, configure it, make them play nice together, figure out why they're fighting, and then do it all over again every new project. It's exhausting.

Biome is an attempt to fix that.

What Is Biome?

Biome is a fast, all-in-one toolchain for web projects. It handles formatting and linting — the two things most JS/TS devs reach for ESLint and Prettier to do — in a single tool, written in Rust.

The short pitch: run one command, get your code formatted and linted, no plugin wrangling required.

It supports JavaScript, TypeScript, JSX, TSX, JSON, CSS, GraphQL, and HTML out of the box. No extra packages needed for any of those.

Biome started as a fork of Rome (which is now archived), but it's been actively developed since and has diverged quite a bit. More on that in a moment.

How Does It Compare?

vs. Prettier

Prettier is the go-to formatter for most JS projects. It works well, but it's slow on large codebases and offers almost no configuration by design (which can be a plus or a minus depending on who you ask).

Biome's formatter is ~35x faster than Prettier when formatting large codebases. It also scores 97% compatibility with Prettier's output, so switching is mostly painless. The small differences are mostly edge cases you probably won't hit day-to-day.

One practical win: Biome can format malformed or incomplete code too. Prettier will just bail out. That matters if you want format-on-save to work mid-edit.

vs. ESLint

ESLint is incredibly powerful and flexible — and that's also its biggest downside. Configuring ESLint from scratch, especially with TypeScript support, plugins like eslint-plugin-react or @typescript-eslint, and making it all play together, takes time and breaks silently.

Biome ships with 434 lint rules covering JavaScript, TypeScript, JSX, CSS, and GraphQL. A meaningful chunk of those come from ESLint and typescript-eslint directly. You don't need to install separate plugins to get them.

That said, ESLint's plugin ecosystem is massive. If you rely on niche plugins (custom framework rules, accessibility plugins, etc.), Biome might not cover all of them yet.

vs. Rome

Rome was the original vision for a unified JS toolchain. Development stalled, the project was archived, and Biome was forked from it in 2023 by former contributors. Biome is actively maintained, has a growing community, and is used in production by companies like Cloudflare, Vercel, Canonical, and Discord.

If you were waiting on Rome, Biome is essentially what that promised to be.

Getting Started

Install it:

npm install --save-dev --save-exact @biomejs/biome

Initialize a config file:

npx @biomejs/biome init

This creates a biome.json in your project root. The defaults are sensible — you don't have to touch it.

Format your code

npx @biomejs/biome format --write ./src

Lint your code

npx @biomejs/biome lint --write ./src

Or do both at once

npx @biomejs/biome check --write ./src

That's it. No plugins, no peer dependency conflicts, no .eslintignore + .prettierignore duplication.

What the config looks like

A minimal biome.json might look like this:

{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  }
}

Compare that to a typical ESLint + Prettier + TypeScript setup with separate config files, .prettierrc, eslint.config.js, and a handful of devDependencies. The difference in cognitive overhead is real.

Error output is actually readable

One thing worth calling out: Biome's diagnostics are genuinely good. Here's an example of what a lint error looks like:

// ✖ Biome lint warning: lint/complexity/useFlatMap
// The call chain .map().flat() can be replaced with .flatMap()

// Before
array.map(sentence => sentence.split(' ')).flat();

// After (safe fix)
array.flatMap(sentence => sentence.split(' '));

It tells you what's wrong, where it is, why it matters, and shows you the fix. Most ESLint errors don't do that — you often end up Googling the rule name to understand what it actually wants.

Editor Integration

Biome has first-party extensions for VS Code, Zed, IntelliJ, Neovim, and Helix. Format-on-save works out of the box after installing the extension and pointing it to your project's biome.json.

If your team uses VS Code, you can commit a .vscode/settings.json that sets Biome as the default formatter, so everyone's on the same setup automatically.

When Should You Use Biome?

Biome is a great fit if:

You're starting a new JS/TS project and want formatting + linting without a bunch of config overhead
Your team spends more time configuring tools than writing code
You work with large codebases where Prettier's speed is noticeable in CI
You want consistent tooling without bikeshedding over ESLint plugin choices

It's probably not the right fit yet if:

You rely heavily on niche ESLint plugins (think eslint-plugin-jsx-a11y, framework-specific rules, etc.) that Biome doesn't have equivalents for
Your team has a deeply customized ESLint config that took months to get right and works well

Bottom Line

Biome isn't trying to replace ESLint for every use case. But for a lot of standard JS/TS projects, it covers 90%+ of what you actually need from ESLint and Prettier combined — and it does it faster, with less config, and with better error output.

If you find yourself re-doing the ESLint + Prettier setup dance on every new project, it's worth giving Biome a shot. Run npx @biomejs/biome init in your next project and see how far the defaults get you.

Chances are, pretty far.

Your Next Role, Planned With Clarity

Vishwajeet Kondi — Wed, 21 Jan 2026 12:56:55 +0000

Upload your resume. Get 4-6 strategic career paths. Pick one. Get a month-by-month roadmap to get there.

That's NextRole. That's it. That's the whole thing.

No job boards. No generic AI advice. No "let me tell you about a PM role." Just actual analysis of your specific background + a concrete plan forward that reads like a career strategist made it (because, well, the AI kind of did).

Show Me Proof

Step 1: Upload Your Resume

Paste your resume text or upload a PDF. The AI extracts what matters: your role, experience, tech stack, strengths. Takes 10 seconds.

See something wrong? Edit it. That's YOUR profile.

Step 2: See Your Options (This Is The Money Part)

Four to six career paths appear. Each one is ranked by:

Market demand - How many jobs are actually hiring for this?
Fit score - How well does this match YOU?

These aren't "you could maybe do this." These are "here's what the market wants + here's what you're ready for."

Pick the one that excites you.

Step 3: Get Your Roadmap (The Actual Plan)

This is where it gets real. You get:

Why this path fits you (specific to your background)
What skills you're missing (gaps, ranked by priority)
A month-by-month plan for the next 6-12 months - Not "learn React." Actual projects. Milestones. Certifications. Timelines.

Print it. Share it. Live by it.

Why This Beats Everything Else

Most career tools suck because they're either too generic ("you could be a manager") or too salesy ("check out these 400 jobs"). NextRole is different:

Personalized to you. Not a template. Not generic advice. Your actual background, your actual options.
Built by vibe. This is lovingly crafted code, not some enterprise bloatware. It's fast. It's clean. It works.
Tells you what's real. Market demand scores aren't made up. Skill gaps are specific. Paths are viable.

Try It Right Now

No credit card. No sign-up. No BS.

Open NextRole →

Can't decide? Try a sample resume (there are 4). Or use mock mode to test without API keys.

Seriously, you can be done in 3 minutes.

For The Curious Types

Built with Next.js + TypeScript. AI-powered by Gemini or Deepseek. Open source. Check out the code.

Hello World to GitHub Actions: Your First Automated Workflow

Vishwajeet Kondi — Thu, 25 Dec 2025 06:38:02 +0000

Hey there! So you're building a React app with TypeScript and Vite, and you keep hearing people talk about CI/CD and GitHub Actions. What's all the fuss about? Let me break it down for you in plain English.

What's GitHub Actions Anyway?

Think of GitHub Actions as your automation buddy that lives in your GitHub repo. You tell it "hey, whenever I push code, run my tests and make sure nothing broke," and it just... does it. Automatically. While you grab coffee(or chai) or work on something else.

Pretty cool, right? Here's what makes it awesome:

It's automatic - No more remembering to run tests before you push. Your automation buddy handles it.

It's consistent - Everyone's code gets tested the same way, every single time. No more "but it works on my machine!"

It's free - GitHub gives you a generous amount of free minutes every month. For most personal projects, you won't pay a dime.

It's built-in - Everything happens right in GitHub. No need to sign up for yet another service.

The Basics (Don't Worry, It's Simple!)

Before we jump into code, let's get familiar with a few terms:

Workflows are like recipes. They're files that tell GitHub Actions what to do. You write them in a language called YAML (it's just a fancy text format, nothing scary).

Events are triggers. "When someone pushes code" or "when someone opens a pull request" - these are events that kick off your workflow.

Jobs are the big tasks in your recipe. Like "build the app" or "run tests." Each job runs on its own fresh computer in the cloud.

Steps are the small tasks inside a job. Things like "install dependencies" or "run the linter."

Actions are pre-made shortcuts. Instead of writing commands to set up Node.js from scratch, you can use an action someone else already made. It's like using a package from npm, but for your workflows.

Let's Build Your First Workflow!

Alright, enough theory. Let's make something real. We're going to create a workflow that checks your code every time you push or open a pull request.

Creating the File

First, make a new folder in your project: .github/workflows/. Yes, it starts with a dot - that's on purpose!

Inside that folder, create a file called ci.yml. Here's what goes in it:

name: CI Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]

permissions:
  contents: read

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Type check
        run: npm run type-check

      - name: Build project
        run: npm run build

      - name: Run tests
        run: npm test

What's All This Mean?

Let me walk you through it:

name: CI Pipeline - Just a friendly name for your workflow. You'll see it in the GitHub interface.

on: - This is where you say "run this when..." In our case, we're saying "run when someone pushes to main or develop, OR when someone opens a pull request."

permissions: - This is important! We're telling GitHub "hey, this workflow only needs permission to read our code, nothing else." It's like giving someone a library card instead of the keys to the building. Good security practice!

jobs: - Here's where the actual work happens. We've got one job called "build-and-test."

runs-on: ubuntu-latest - This means "run on a computer with Ubuntu Linux." GitHub provides this for free!

steps: - These are the actual commands that run, one after another:

First, we grab the code
Then we install Node.js
Install our dependencies
Run the linter to check code style
Check for TypeScript errors
Build the project
Run our tests

Setting Up Your package.json

Your package.json needs to have these scripts for the workflow to work:

{
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint . --ext ts,tsx --report-unused-disable-directives --max-warnings 0",
    "type-check": "tsc --noEmit",
    "test": "vitest run",
    "preview": "vite preview"
  }
}

Don't have ESLint or Vitest set up yet? No worries - you can skip those steps in your workflow for now and add them later.

Want to Deploy Automatically Too?

Once your tests pass, you might want to deploy your app. Here's a workflow that deploys to GitHub Pages:

name: Deploy to GitHub Pages

on:
  push:
    branches: [ main ]

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build project
        run: npm run build

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./dist

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

This one's a bit different - it has TWO jobs. The second job (deploy) waits for the first one (build) to finish successfully. That needs: build line is what makes that happen.

Making It Faster with Caching

Want your workflows to run faster? Good news - the actions/setup-node@v4 action we're using already caches your npm packages when you add cache: 'npm'. That means the second time your workflow runs, it won't have to download all your dependencies again. Pretty smart!

Keeping Secrets... Secret

Sometimes you need API keys or passwords in your builds. DON'T put them directly in your workflow file - that's like posting your house keys on Instagram.

Instead, use GitHub's secrets feature:

Go to your repo's Settings
Click on "Secrets and variables" then "Actions"
Click "New repository secret"
Add your secret (like VITE_API_KEY)

Then use it in your workflow like this:

- name: Build project
  run: npm run build
  env:
    VITE_API_KEY: ${{ secrets.VITE_API_KEY }}

GitHub will hide it in the logs automatically. Nice!

Checking If It's Working

After you push your workflow file to GitHub:

Click the "Actions" tab in your repo
You'll see your workflow running (or done running)
Click on it to see all the details
If something breaks, click on the red X to see what went wrong

The logs tell you EXACTLY what happened at each step. It's super helpful for debugging.

Understanding Workflow Permissions

Quick important thing - see that permissions block we added? That's like setting up proper door locks for your house.

By default, workflows might have way more permissions than they need. We're being explicit and saying "this workflow only needs to READ the code" with contents: read. If later you need to do something like comment on pull requests, you'd add pull-requests: write.

It's just a good habit to be clear about what your workflow can and can't do. Your future self (and your team) will thank you!

Some Quick Tips

Here are a few things that'll make your life easier:

Set permissions explicitly - Like we just talked about, always add that permissions block. Start with contents: read and only add more when you need it.

Use version tags - Notice how we use @v4 in our actions? That's better than using @main because it won't suddenly change on you. Your workflows stay stable.

Use npm ci not npm install - In automated environments, npm ci is faster and more reliable. It's designed specifically for CI/CD.

Run jobs in parallel - If you have multiple jobs that don't depend on each other, they'll run at the same time. Saves time!

Add a badge to your README - In the Actions tab, you can grab a badge that shows if your build is passing. It looks professional!

Test different Node versions - You can use something called a matrix to test on Node 18, 20, and 21 all at once. Here's how:

strategy:
  matrix:
    node-version: [18, 20, 21]

Protect your main branch - In your repo settings, you can require that all checks pass before merging. No more broken builds!

Separate your workflows - Keep your testing workflow separate from your deployment workflow. Makes things easier to understand and manage.

When Things Go Wrong

Don't panic! Here are common issues and fixes:

Workflow not running? - Check that your YAML file is in .github/workflows/ and that you don't have any syntax errors. YAML is picky about spaces and indentation.

Works on your computer but not in CI? - Make sure all your dependencies are listed in package.json. Also check that you're not relying on environment variables that only exist on your machine.

Running out of build minutes? - Public repos get unlimited minutes! Private repos have limits. Check your usage in Settings → Billing.

What's Next?

You now know the basics! Here are some cool things to explore when you're ready:

Browse the GitHub Marketplace for actions other people have made
Set up notifications to Slack or Discord when builds fail
Add code coverage reporting
Create custom actions for your specific needs
Try matrix builds to test across multiple environments

The key is to start simple - get your basic testing pipeline working - then add more features as you need them. Don't try to do everything at once!

Wrapping Up

GitHub Actions might seem a bit intimidating at first, but once you get the hang of it, you'll wonder how you lived without it. No more forgetting to run tests. No more "oops, I broke main." Just push your code and let your automation buddy do its thing.

Start with the simple CI workflow we built together, make sure it works, and then gradually add more automation as you get comfortable. Before you know it, you'll be the GitHub Actions expert on your team!

Happy automating! 🚀

React Interviews: The Skills That REALLY Matter

Vishwajeet Kondi — Sat, 29 Nov 2025 11:14:19 +0000

After interviewing many React developers, I’ve realized that interviews aren’t about catching people off-guard or seeing what they don’t know. What I really want is to understand how someone thinks, how they approach problems, and how they’ve grown through their experiences.

These are the areas I naturally pay attention to, not because I expect perfection, but because they give me a clearer picture of someone’s comfort level with real-world frontend development.

1. JavaScript Fundamentals: The First Filter

Before I ask anything about React, I look for solid JavaScript fundamentals.

Not trivia. Not trick questions.
But questions that reveal understanding of:

closures
async/await & the event loop
immutability
objects vs references
array/object manipulation

Weak JavaScript always shows up later as weak React.

Strong JS tells me the candidate can reason about UI behavior without stumbling into guesswork.

2. HTML & CSS Mastery: The Underestimated Skill

A surprising number of candidates can’t structure accessible HTML or reason about CSS specificity.

So I pay attention to:

semantic markup
flex/Grid awareness
responsive thinking
accessibility basics

Because at the end of the day, React renders HTML and CSS—not magic.

Their approach here reveals whether they can build interfaces that are clean, accessible, and production-ready.

3. React Fundamentals: Depth Over Definitions

When I ask about reconciliation, controlled inputs, keys, or component composition, I’m not testing memory.

I’m testing understanding.

I want to see if candidates genuinely know why React behaves the way it does—not just that “it re-renders sometimes.”

Clear reasoning here shows me they can prevent issues before they appear.

4. Hooks: The Real Difference-Maker

Hooks expose a developer’s thought process instantly.

So I probe their understanding of:

dependency arrays
stale closures
memoization logic
custom hooks for reusability

The best candidates don’t just know how to use hooks—they know why hooks behave the way they do.

Good hook explanations show they understand state, side effects, and component lifecycles on a deeper level.

5. State Management: Architectural Thinking

This is where seniority becomes obvious.

Strong candidates can explain:

when to use Context vs Redux vs Zustand
the difference between server state and client state
caching strategies
selectors and memoization

Average candidates choose tools.
Senior candidates justify them.

Their choices here reveal their architectural maturity and thoughtfulness.

6. Deep Understanding of Their Own Project

This is the biggest differentiator.

I don’t want a tour of their GitHub.
I want to see:

how data flows in their app
what patterns they use
how they handle performance challenges
how they break down large features
why they made architectural decisions

If someone can’t explain their own application clearly, I can immediately tell they weren’t involved deeply.

The depth of their explanation tells me how involved they really were and how well they understand complex systems.

7. Performance Optimization: The Senior Signal

I often ask questions like:

“Why does this component re-render?”
“How would you optimize this list?”
“Where would memoization help—or hurt?”

Great engineers don’t jump to useMemo blindly.
They talk about causes, not just fixes.

Their approach here shows whether they can keep an app fast, even at scale.

8. Architecture & Design Thinking

I always look at how candidates:

structure folders
break down components
avoid props drilling
design for reusability
handle side effects

React is just a UI layer—architecture is the real skill.

This part reveals how they operate inside large, evolving codebases.

9. TypeScript: The Modern Essential

Most interviews now include TypeScript.

I check whether candidates can:

type props
type hooks
use utility types
handle API responses safely

I’m not looking for TS gurus.
I’m looking for engineers who understand how TS reduces runtime bugs.

Good TS habits tell me they write safer, more predictable UI code.

10. Async Logic & Real-World Scenarios

This is where many candidates stumble.

I want to hear how they handle:

loading & error states
retries and fallback UI
parallel requests
data caching (TanStack Query is a big plus)
Suspense in modern React

How they think about async workflows tells me whether they can build resilient user experiences.

11. Testing: The Sign of a Mature Engineer

I listen for:

understanding of React Testing Library
mocking strategies
testing asynchronous behavior
testing components using context/hooks

Tests say a lot about the engineer writing them.

Their testing mindset shows how much they value long-term stability.

12. Awareness of React 19+

Even if they haven’t used it, awareness of:

server components
actions
Suspense improvements
transitions

…shows they’re staying relevant.

Staying updated tells me they’re committed to evolving with the ecosystem—not stuck in old patterns.

Final Thoughts: What Truly Stands Out

When you interview someone, you do not expect them to know everything.
I certainly don’t know everything myself.

What I appreciate most is:

clarity
reasoning
technical humility
strong fundamentals
an ability to explain their decisions
and real ownership of the projects they’ve built

Those are the candidates who instantly stand out.

AI Coding Assistants: Boon or Bane?

Vishwajeet Kondi — Sat, 08 Nov 2025 14:18:24 +0000

Let’s be real: AI coding tools like Copilot, Cursor, and others are game-changers. They autocomplete code, suggest fixes, and even write entire functions for you. For new developers, this is like having a senior dev sitting next to you, whispering answers in your ear. But here’s the big question: Are these tools making us better coders, or are they turning us into button-pushers who don’t understand what’s happening under the hood?

🧩 The Case for Concern: Are We Losing Our Edge?

1. The Logic Gap

Back in the day, if you wanted to write a sorting algorithm, you had to understand how sorting works. Now, you can just type // sort this array and let Copilot do the rest. That’s convenient, but what happens when the code breaks? If you don’t understand the logic, debugging becomes a game of guesswork.

2. The Dependency Dilemma

AI tools are fantastic—until they’re not. What if you’re working on legacy code, or a niche language, or a system where AI suggestions are just wrong? Over-reliance on AI might leave developers scrambling when they need to think for themselves.

3. The Learning Curve Paradox

For beginners, AI tools can be a double-edged sword. On one hand, they lower the barrier to entry. On the other, they might skip the struggle that teaches you how to code. It’s like learning to drive with autopilot—great until you need to take the wheel.

⚙️ The Flip Side: Why AI Tools Are a Net Positive

1. Democratizing Coding

Not everyone has the time or resources to spend years mastering coding. AI tools let more people build, create, and innovate without needing a PhD in computer science. That’s a win for diversity and accessibility in tech.

2. Speed and Efficiency

Let’s face it: writing boilerplate code is boring. AI handles the repetitive stuff, freeing developers to focus on creative problem-solving and architecture. That’s where the real magic happens.

3. Learning with a Safety Net

AI tools aren’t just for copying code—they’re for learning. Seeing how an AI solves a problem can spark curiosity. “Why did it suggest this?” “How does this function work?” Used right, AI can be a mentor, not just a crutch.

⚖️ The Future: What’s Next?

AI tools aren’t going away—they’re only getting smarter. The real question isn’t if we should use them, but how. Here’s what the future could look like:

Hybrid Learning: Coding bootcamps and universities might integrate AI tools into curricula, teaching students when to use them and when to think for themselves.
Better Debugging Tools: AI could evolve to not just write code, but explain it—helping developers understand the “why” behind the “what.”
New Kinds of Developers: The role of a developer might shift from “person who writes code” to “person who designs systems and solves problems,” with AI handling the grunt work.

🌟 Final Thoughts: Embrace the Change

AI coding tools are neither a curse nor a miracle—they’re just tools. Like any tool, their impact depends on how we use them. Will some developers rely too much on AI and miss out on deep learning? Probably. Will others use AI to become even better at what they do? Absolutely.

The key is balance. Use AI to speed up your work, but don’t let it replace your curiosity. Stay hungry, keep learning, and remember: the best developers aren’t the ones who write the most code—they’re the ones who understand it.

💬 What do you think?

Are we heading towards a “logic-light” generation of coders, or are we just evolving into more creative builders?

JSON Schema in the Wild: Real World Applications & HAL 🌍

Vishwajeet Kondi — Tue, 07 Oct 2025 18:30:00 +0000

Part 3 of 3: Where Theory Meets Production

Welcome to the final part of our JSON Schema journey! We've covered the theory and implementation – now let's see how JSON Schema solves real problems in production environments. Plus, we'll dive into HAL (Hypermedia Application Language) and how it plays beautifully with JSON Schema.

1. API Validation Middleware (Your APIs' Bodyguard)

Let's build bulletproof API validation that catches bad data before it causes havoc:

import express from 'express';
import Ajv from 'ajv';
import addFormats from 'ajv-formats';

const ajv = new Ajv({ allErrors: true });
addFormats(ajv);

// Generic validation middleware
function validateRequest(schema: any, target: 'body' | 'query' | 'params' = 'body') {
  const validate = ajv.compile(schema);

  return (req: any, res: any, next: any) => {
    const dataToValidate = req[target];

    if (!validate(dataToValidate)) {
      return res.status(400).json({
        error: 'Validation failed',
        details: validate.errors?.map(err => ({
          field: err.instancePath || err.params?.missingProperty,
          message: err.message,
          value: err.data
        }))
      });
    }

    // Store validated data (with defaults applied!)
    req.validatedData = dataToValidate;
    next();
  };
}

// Define your schemas
const createUserSchema = {
  type: "object",
  properties: {
    name: { type: "string", minLength: 1, maxLength: 100 },
    email: { type: "string", format: "email" },
    age: { type: "number", minimum: 13, maximum: 120 },
    role: { enum: ["user", "admin"], default: "user" }
  },
  required: ["name", "email", "age"],
  additionalProperties: false
};

const updateUserSchema = {
  type: "object",
  properties: {
    name: { type: "string", minLength: 1, maxLength: 100 },
    email: { type: "string", format: "email" },
    age: { type: "number", minimum: 13, maximum: 120 }
  },
  minProperties: 1, // At least one field must be provided
  additionalProperties: false
};

// Use in your routes
const app = express();
app.use(express.json());

app.post('/users', 
  validateRequest(createUserSchema, 'body'),
  (req, res) => {
    // req.validatedData contains clean, validated data
    const user = createUser(req.validatedData);
    res.json(user);
  }
);

app.patch('/users/:id', 
  validateRequest(updateUserSchema, 'body'),
  (req, res) => {
    const userId = req.params.id;
    const updates = req.validatedData;
    const user = updateUser(userId, updates);
    res.json(user);
  }
);

// Query parameter validation too!
const searchSchema = {
  type: "object",
  properties: {
    q: { type: "string", minLength: 1 },
    page: { type: "string", pattern: "^[1-9]\\d*$", default: "1" },
    limit: { type: "string", pattern: "^(10|25|50|100)$", default: "25" }
  },
  required: ["q"],
  additionalProperties: false
};

app.get('/search', 
  validateRequest(searchSchema, 'query'),
  (req, res) => {
    const { q, page, limit } = req.validatedData;
    const results = searchUsers(q, parseInt(page), parseInt(limit));
    res.json(results);
  }
);

2. Data Pipeline Validation (ETL with Confidence)

When processing large datasets, catching bad data early saves hours of debugging:

// data-pipeline.ts
import Ajv from 'ajv';
import addFormats from 'ajv-formats';

const ajv = new Ajv({ allErrors: true });
addFormats(ajv);

// Schema for incoming data records
const dataRecordSchema = {
  type: "object",
  properties: {
    id: { 
      type: "string", 
      pattern: "^[A-Z]{2}[0-9]{6}$" // e.g., "AB123456"
    },
    timestamp: { 
      type: "string", 
      format: "date-time" 
    },
    value: { 
      type: "number",
      minimum: 0
    },
    category: { 
      enum: ["sales", "marketing", "support", "development"] 
    },
    metadata: {
      type: "object",
      properties: {
        source: { type: "string" },
        confidence: { type: "number", minimum: 0, maximum: 1 }
      },
      required: ["source"],
      additionalProperties: true // Allow extra metadata
    }
  },
  required: ["id", "timestamp", "value", "category"],
  additionalProperties: false
};

const validateRecord = ajv.compile(dataRecordSchema);

interface ProcessingResult {
  validRecords: any[];
  invalidRecords: Array<{
    record: any;
    errors: string[];
  }>;
  stats: {
    total: number;
    valid: number;
    invalid: number;
    validationRate: number;
  };
}

export function processDataBatch(records: any[]): ProcessingResult {
  const validRecords: any[] = [];
  const invalidRecords: any[] = [];

  records.forEach((record, index) => {
    if (validateRecord(record)) {
      validRecords.push(record);
    } else {
      invalidRecords.push({
        record,
        errors: validateRecord.errors?.map(err => 
          `${err.instancePath || 'root'}: ${err.message}`
        ) || []
      });
    }
  });

  const total = records.length;
  const valid = validRecords.length;
  const invalid = invalidRecords.length;

  return {
    validRecords,
    invalidRecords,
    stats: {
      total,
      valid,
      invalid,
      validationRate: (valid / total) * 100
    }
  };
}

// Usage in your ETL process
async function runETL(inputFile: string) {
  const rawData = await loadDataFromFile(inputFile);
  const result = processDataBatch(rawData);

  console.log(`Processed ${result.stats.total} records:`);
  console.log(`✅ Valid: ${result.stats.valid} (${result.stats.validationRate.toFixed(1)}%)`);
  console.log(`❌ Invalid: ${result.stats.invalid}`);

  if (result.invalidRecords.length > 0) {
    console.log('\nInvalid records:');
    result.invalidRecords.slice(0, 5).forEach((invalid, i) => {
      console.log(`Record ${i + 1}:`, invalid.errors.join(', '));
    });
  }

  // Process only valid records
  await saveToDatabase(result.validRecords);

  // Log invalid records for investigation
  if (result.invalidRecords.length > 0) {
    await saveInvalidRecords(result.invalidRecords);
  }
}

3. HAL (Hypermedia Application Language) Schemas

HAL makes your APIs self-describing with built-in navigation. Think JSON with links that tell clients what actions they can take next.

Basic HAL Structure & Schema

// HAL link schema
const halLinkSchema = {
  type: "object",
  properties: {
    href: { type: "string", format: "uri-reference" },
    templated: { type: "boolean" },
    type: { type: "string" }
  },
  required: ["href"],
  additionalProperties: false
};

// Complete HAL resource schema
const halUserSchema = {
  type: "object",
  properties: {
    // Resource data
    id: { type: "number" },
    name: { type: "string" },
    email: { type: "string", format: "email" },

    // HAL links (required)
    _links: {
      type: "object",
      properties: {
        self: halLinkSchema,
        edit: halLinkSchema,
        delete: halLinkSchema
      },
      required: ["self"],
      additionalProperties: halLinkSchema
    },

    // HAL embedded resources (optional)
    _embedded: {
      type: "object",
      properties: {
        posts: {
          type: "array",
          items: {
            type: "object",
            properties: {
              id: { type: "number" },
              title: { type: "string" },
              _links: {
                type: "object",
                properties: { self: halLinkSchema },
                required: ["self"]
              }
            },
            required: ["id", "title", "_links"]
          }
        }
      }
    }
  },
  required: ["id", "name", "_links"],
  additionalProperties: false
};

HAL Response Builder

import Ajv from 'ajv';
const ajv = new Ajv();
const validateHalUser = ajv.compile(halUserSchema);

class HalBuilder {
  static user(user: any, baseUrl: string) {
    const halUser = {
      ...user,
      _links: {
        self: { href: `${baseUrl}/users/${user.id}` },
        edit: { href: `${baseUrl}/users/${user.id}` },
        posts: { href: `${baseUrl}/users/${user.id}/posts` }
      }
    };

    // Add embedded posts if available
    if (user.posts?.length) {
      halUser._embedded = {
        posts: user.posts.map(post => ({
          ...post,
          _links: { self: { href: `${baseUrl}/posts/${post.id}` } }
        }))
      };
    }

    if (!validateHalUser(halUser)) {
      throw new Error('Invalid HAL resource');
    }

    return halUser;
  }
}

// Usage in Express
app.get('/users/:id', async (req, res) => {
  const user = await getUserById(req.params.id);
  const baseUrl = `${req.protocol}://${req.get('host')}`;

  res.json(HalBuilder.user(user, baseUrl));
});

4. Testing Your Schemas (Because Bugs Hide in Edge Cases)

Don't just validate production data – test your schemas themselves:

// schema-tests.ts
import { describe, it, expect } from 'vitest';
import Ajv from 'ajv';
import addFormats from 'ajv-formats';
import { halUserSchema, userRegistrationSchema } from './schemas';

const ajv = new Ajv({ allErrors: true });
addFormats(ajv);

describe('User Registration Schema', () => {
  const validate = ajv.compile(userRegistrationSchema);

  it('should accept valid user data', () => {
    const validUser = {
      username: "johndoe123",
      email: "john@example.com",
      password: "SecurePass123!",
      age: 25
    };

    expect(validate(validUser)).toBe(true);
  });

  it('should reject invalid email', () => {
    const invalidUser = {
      username: "johndoe123",
      email: "not-an-email",
      password: "SecurePass123!",
      age: 25
    };

    expect(validate(invalidUser)).toBe(false);
    expect(validate.errors).toContainEqual(
      expect.objectContaining({
        instancePath: '/email',
        message: 'must match format "email"'
      })
    );
  });

  it('should reject weak password', () => {
    const invalidUser = {
      username: "johndoe123",
      email: "john@example.com",
      password: "weak",
      age: 25
    };

    expect(validate(invalidUser)).toBe(false);
  });

  it('should apply defaults', () => {
    const userData = {
      username: "johndoe123",
      email: "john@example.com",
      password: "SecurePass123!",
      age: 25
    };

    validate(userData);
    expect(userData.preferences?.newsletter).toBe(false);
    expect(userData.preferences?.theme).toBe('light');
  });
});

describe('HAL User Schema', () => {
  const validate = ajv.compile(halUserSchema);

  it('should accept valid HAL user', () => {
    const halUser = {
      id: 123,
      name: "Alice",
      email: "alice@example.com",
      createdAt: "2023-01-01T00:00:00.000Z",
      _links: {
        self: { href: "/users/123" },
        edit: { href: "/users/123" }
      }
    };

    expect(validate(halUser)).toBe(true);
  });

  it('should require _links.self', () => {
    const invalidHalUser = {
      id: 123,
      name: "Alice",
      email: "alice@example.com",
      _links: {
        edit: { href: "/users/123" }
      }
    };

    expect(validate(invalidHalUser)).toBe(false);
    expect(validate.errors).toContainEqual(
      expect.objectContaining({
        instancePath: '/_links',
        message: "must have required property 'self'"
      })
    );
  });
});

5. Pro Tips for Production Success

1. Schema Versioning Strategy

// Keep schemas versioned for backward compatibility
const schemas = {
  'v1': {
    user: userSchemaV1,
    post: postSchemaV1
  },
  'v2': {
    user: userSchemaV2,
    post: postSchemaV2
  }
};

function getValidator(resource: string, version: string = 'v2') {
  const schema = schemas[version]?.[resource];
  if (!schema) {
    throw new Error(`Schema not found: ${resource} v${version}`);
  }
  return ajv.compile(schema);
}

2. Performance Monitoring

// Monitor validation performance
function createTimedValidator(schema: any, name: string) {
  const validate = ajv.compile(schema);

  return (data: any) => {
    const start = process.hrtime.bigint();
    const result = validate(data);
    const end = process.hrtime.bigint();

    const duration = Number(end - start) / 1000000; // Convert to milliseconds
    console.log(`Validation ${name}: ${duration.toFixed(2)}ms`);

    return result;
  };
}

3. Schema Documentation Generation

// Generate documentation from your schemas
function generateSchemaDoc(schema: any, title: string) {
  const doc = {
    title,
    properties: {},
    required: schema.required || []
  };

  for (const [prop, definition] of Object.entries(schema.properties || {})) {
    doc.properties[prop] = {
      type: definition.type,
      description: definition.description || `${prop} field`,
      required: schema.required?.includes(prop) || false,
      example: generateExample(definition)
    };
  }

  return doc;
}

Wrapping Up the Series

Congratulations! You've journeyed from JSON Schema basics to production-ready implementations. Here's what you've gained:

Part 1: Understanding JSON Schema fundamentals and YAML compatibility
Part 2: Mastering AJV implementation with advanced features and TypeScript integration
Part 3: Real-world patterns including API validation, ETL pipelines, and HAL hypermedia APIs

Your Next Steps

Start Small: Pick one use case (maybe API validation) and implement it
Build Your Schema Library: Create reusable schemas for your common data structures
Test Everything: Write tests for both your schemas and your validation logic
Monitor Performance: Keep an eye on validation performance in production
Document Your Schemas: Good schemas are self-documenting, but examples help

You're now equipped to bring order to the chaos of unvalidated data. Go forth and validate with confidence! 🚀

Series Navigation:

Part 1: Understanding the Basics
Part 2: Implementation with AJV
Part 3: Real-World Applications & HAL ← You are here

JSON Schema with AJV: Implementation Deep Dive ⚡

Vishwajeet Kondi — Thu, 02 Oct 2025 22:30:00 +0000

Part 2 of 3: Getting Your Hands Dirty

Welcome back! In Part 1, we covered the basics of JSON Schema and why it's awesome. Now it's time to roll up our sleeves and implement some real validation with AJV (Another JSON Schema Validator) – the Swiss Army knife of JSON validation.

Why AJV Rules the Validation World

AJV isn't just another validation library – it's THE validation library. Here's why developers love it:

Blazingly Fast: Compiles schemas to optimized JavaScript functions
Fully Compliant: Supports JSON Schema draft-07 and draft 2019-09
Extensible: Custom keywords, formats, and error messages
TypeScript Ready: Excellent TypeScript support out of the box

Getting Started: Installation and Basic Setup

# The essentials
npm install ajv

# Optional but recommended additions
npm install ajv-formats ajv-errors ajv-keywords

import Ajv from 'ajv';
import addFormats from 'ajv-formats';

// Create your AJV instance
const ajv = new Ajv({ 
  allErrors: true,        // Collect all errors, not just the first
  removeAdditional: true, // Remove additional properties
  useDefaults: true       // Apply default values
});

// Add common formats (email, date, uri, etc.)
addFormats(ajv);

// Now you're ready to validate!

Your First Real Validation

Let's build something practical – a user registration validator:

const userRegistrationSchema = {
  type: "object",
  properties: {
    username: {
      type: "string",
      minLength: 3,
      maxLength: 20,
      pattern: "^[a-zA-Z0-9_]+$"
    },
    email: {
      type: "string",
      format: "email"
    },
    password: {
      type: "string",
      minLength: 8,
      pattern: "^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*[@$!%*?&])[A-Za-z\\d@$!%*?&]"
    },
    age: {
      type: "number",
      minimum: 13,
      maximum: 120
    },
    preferences: {
      type: "object",
      properties: {
        newsletter: { type: "boolean", default: false },
        theme: { enum: ["light", "dark"], default: "light" }
      },
      additionalProperties: false
    }
  },
  required: ["username", "email", "password", "age"],
  additionalProperties: false
};

// Compile the schema (do this once, reuse many times)
const validateUser = ajv.compile(userRegistrationSchema);

// Test it out
function registerUser(userData: any) {
  const valid = validateUser(userData);

  if (!valid) {
    console.log('Validation failed:');
    validateUser.errors?.forEach(error => {
      console.log(`- ${error.instancePath}: ${error.message}`);
    });
    return null;
  }

  console.log('✅ User data is valid!');
  return userData; // Now with defaults applied!
}

// Try it
const newUser = {
  username: "coolguy123",
  email: "cool@example.com",
  password: "SuperSecret123!",
  age: 25
};

registerUser(newUser);
// ✅ User data is valid!
// Note: preferences.newsletter and preferences.theme get default values

Advanced AJV Features That'll Blow Your Mind

1. Custom Keywords

Sometimes the built-in validation isn't enough. Let's create a custom keyword:

// Add a custom "isAdult" keyword
ajv.addKeyword({
  keyword: 'isAdult',
  type: 'number',
  schemaType: 'boolean',
  compile(schemaVal) {
    return function validate(data) {
      if (schemaVal) {
        return data >= 18;
      }
      return true;
    }
  },
  errors: false,
  metaSchema: {
    type: "boolean"
  }
});

// Use it in a schema
const adultSchema = {
  type: "object",
  properties: {
    age: { 
      type: "number", 
      isAdult: true 
    }
  }
};

const validateAdult = ajv.compile(adultSchema);
console.log(validateAdult({ age: 17 })); // false
console.log(validateAdult({ age: 21 })); // true

2. Conditional Validation

Real-world data often has complex relationships. AJV handles this beautifully:

const conditionalSchema = {
  type: "object",
  properties: {
    userType: { enum: ["admin", "user", "guest"] },
    permissions: { 
      type: "array",
      items: { type: "string" }
    },
    adminKey: { type: "string" }
  },
  required: ["userType"],

  // If user is admin, they need permissions and adminKey
  if: { 
    properties: { 
      userType: { const: "admin" } 
    } 
  },
  then: { 
    required: ["permissions", "adminKey"],
    properties: {
      permissions: { minItems: 1 }
    }
  },

  // If user is guest, no additional requirements
  else: {
    if: { 
      properties: { 
        userType: { const: "guest" } 
      } 
    },
    then: {
      // Guests can't have permissions
      not: {
        required: ["permissions"]
      }
    }
  }
};

3. Schema Composition with $ref

Keep your schemas DRY and maintainable:

const schemas = {
  // Base address schema
  address: {
    $id: "https://example.com/schemas/address.json",
    type: "object",
    properties: {
      street: { type: "string" },
      city: { type: "string" },
      zipCode: { 
        type: "string", 
        pattern: "^[0-9]{5}(-[0-9]{4})?$" 
      }
    },
    required: ["street", "city", "zipCode"]
  },

  // Person schema using address
  person: {
    $id: "https://example.com/schemas/person.json",
    type: "object",
    properties: {
      name: { type: "string" },
      homeAddress: { $ref: "address.json" },
      workAddress: { $ref: "address.json" }
    }
  }
};

// Add schemas to AJV
ajv.addSchema(schemas.address);
ajv.addSchema(schemas.person);

const validatePerson = ajv.getSchema("https://example.com/schemas/person.json");

Error Handling Like a Pro

Default AJV errors are... functional. But we can make them much better:

import addErrors from 'ajv-errors';
addErrors(ajv);

const betterUserSchema = {
  type: "object",
  properties: {
    username: {
      type: "string",
      minLength: 3,
      maxLength: 20,
      pattern: "^[a-zA-Z0-9_]+$"
    },
    password: {
      type: "string",
      minLength: 8,
      pattern: "^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)"
    }
  },
  required: ["username", "password"],

  // Custom error messages
  errorMessage: {
    properties: {
      username: "Username must be 3-20 characters long and contain only letters, numbers, and underscores",
      password: "Password must be at least 8 characters with uppercase, lowercase, and a number"
    },
    required: {
      username: "Username is required",
      password: "Password is required"
    }
  }
};

Performance Tips That Actually Matter

1. Compile Once, Use Many Times

// ❌ DON'T do this
function validateUserData(data: any) {
  const validate = ajv.compile(userSchema); // Compiling every time!
  return validate(data);
}

// ✅ DO this instead
const validateUserData = ajv.compile(userSchema); // Compile once

function checkUser(data: any) {
  return validateUserData(data); // Reuse compiled function
}

2. Use removeAdditional for Large Objects

const ajv = new Ajv({ 
  removeAdditional: "all" // Strip unknown properties automatically
});

// Input: { name: "Bob", age: 25, secretHackerData: "evil" }
// After validation: { name: "Bob", age: 25 }

3. Optimize for Your Use Case

// For APIs - fast validation, detailed errors
const apiAjv = new Ajv({ 
  allErrors: true,
  verbose: true 
});

// For data processing - fastest validation
const processingAjv = new Ajv({ 
  allErrors: false,
  verbose: false,
  validateSchema: false
});

TypeScript Integration (The Cherry on Top)

AJV plays beautifully with TypeScript:

import { JSONSchemaType } from 'ajv';

// Define your TypeScript interface
interface User {
  id: string;
  name: string;
  age: number;
  email?: string;
}

// Create a typed schema
const userSchema: JSONSchemaType<User> = {
  type: "object",
  properties: {
    id: { type: "string" },
    name: { type: "string" },
    age: { type: "number" },
    email: { type: "string", nullable: true }
  },
  required: ["id", "name", "age"],
  additionalProperties: false
};

// Compile with type safety
const validateUser = ajv.compile(userSchema);

// TypeScript knows the validated data structure!
function processUser(userData: unknown): User | null {
  if (validateUser(userData)) {
    // userData is now typed as User!
    return userData;
  }
  return null;
}

Common Gotchas (Learn From My Mistakes)

1. Format Validation Needs ajv-formats

// This won't work without ajv-formats
const schema = {
  type: "string",
  format: "email" // Silently ignored!
};

// Fix it
import addFormats from 'ajv-formats';
addFormats(ajv);

2. RegExp Patterns Need Double Escaping

// ❌ Wrong
pattern: "^\d{3}-\d{3}-\d{4}$"

// ✅ Correct
pattern: "^\\d{3}-\\d{3}-\\d{4}$"

3. additionalProperties vs Properties

// This allows ANY additional properties
const schema1 = {
  type: "object",
  properties: { name: { type: "string" } }
  // additionalProperties defaults to true
};

// This blocks additional properties
const schema2 = {
  type: "object",
  properties: { name: { type: "string" } },
  additionalProperties: false
};

Wrapping Up Part 2

You now have the power to implement robust, fast, and maintainable validation in your applications! AJV transforms JSON Schema from a simple concept into a validation powerhouse.

Coming Up in Part 3...

In the final part of our series, we'll explore real-world applications:

Building API validation middleware
Data pipeline validation patterns
HAL (Hypermedia) schemas for self-describing APIs
Testing strategies for schema validation
Production ready tips

Ready to put this knowledge to work in production? Part 3 is where the magic happens! 🎯

Series Navigation:

Part 1: Understanding the Basics
Part 2: Implementation with AJV ← You are here
Part 3: Real-World Applications & HAL

Update JSON Schema: Your Data's New Best Friend 🛡️

Vishwajeet Kondi — Sat, 27 Sep 2025 06:33:23 +0000

Part 1 of 3: Understanding the Basics

Ever had that moment where your API returns { age: "twenty-five" } instead of { age: 25 } and your whole app breaks? Yeah, we've all been there. Let's talk about JSON Schema – your new best friend in the fight against unpredictable data.

What the Heck is JSON Schema Anyway?

JSON Schema is basically a contract for your JSON data. Think of it like TypeScript's type definitions, but for runtime validation. It tells your data: "Hey, you better look exactly like this, or we're gonna have problems."

The concept emerged around 2009-2010 when developers got tired of writing custom validation logic for every single API endpoint. Someone smart said, "What if we could describe our data structure using... more JSON?" And boom – JSON Schema was born.

// Instead of this mess:
if (!data.name || typeof data.name !== 'string') {
  throw new Error('Name is required and must be a string');
}
if (!data.age || typeof data.age !== 'number' || data.age < 0) {
  throw new Error('Age must be a positive number');
}
// ... 50 more lines of validation

// You get this beauty:
const schema = {
  type: "object",
  properties: {
    name: { type: "string" },
    age: { type: "number", minimum: 0 }
  },
  required: ["name", "age"]
};

The Anatomy of a JSON Schema

Let's break down what makes a schema tick:

const userSchema = {
  // Root type - what kind of data are we expecting?
  type: "object",

  // Define the shape of our object
  properties: {
    name: { 
      type: "string", 
      minLength: 1,
      maxLength: 100 
    },
    age: { 
      type: "number", 
      minimum: 0, 
      maximum: 150 
    },
    email: { 
      type: "string", 
      format: "email"  // Built-in format validation!
    },
    hobbies: {
      type: "array",
      items: { type: "string" },
      maxItems: 10,
      uniqueItems: true
    },
    isActive: { 
      type: "boolean" 
    }
  },

  // Which fields are mandatory?
  required: ["name", "age"],

  // Should we allow extra properties?
  additionalProperties: false
};

Common Schema Patterns You'll Love

1. Enums (Because Options Are Limited)

const statusSchema = {
  type: "object",
  properties: {
    status: { 
      enum: ["active", "inactive", "pending", "banned"] 
    },
    priority: {
      type: "string",
      enum: ["low", "medium", "high", "urgent"]
    }
  }
};

2. Nested Objects (Objects All the Way Down)

const addressSchema = {
  type: "object",
  properties: {
    street: { type: "string" },
    city: { type: "string" },
    country: { type: "string" },
    zipCode: { 
      type: "string", 
      pattern: "^[1-9][0-9]{5}$" // India ZIP code pattern
    }
  },
  required: ["street", "city", "country"]
};

const personSchema = {
  type: "object",
  properties: {
    name: { type: "string" },
    homeAddress: addressSchema,  // Nested schema
    workAddress: addressSchema   // Reused!
  }
};

3. Arrays with Specific Item Types

const orderSchema = {
  type: "object",
  properties: {
    orderId: { type: "string" },
    items: {
      type: "array",
      minItems: 1,
      items: {
        type: "object",
        properties: {
          productId: { type: "string" },
          quantity: { type: "number", minimum: 1 },
          price: { type: "number", minimum: 0 }
        },
        required: ["productId", "quantity", "price"]
      }
    }
  }
};

YAML Schema: JSON Schema's Chill Cousin

Here's a cool secret – JSON Schema works perfectly with YAML too! Since YAML is essentially JSON's more readable sibling, you can use the same schema definitions.

# Your YAML data
name: "Alice"
age: 30
email: "alice@example.com"
hobbies:
  - "coding"
  - "coffee"
  - "cats"

# Same schema validates both JSON and YAML!

The validation logic doesn't care if your data started as JSON or YAML – it all becomes the same object structure in memory anyway. This means you can:

Use JSON Schema to validate YAML config files
Accept both JSON and YAML in your APIs
Keep one schema definition for multiple data formats

Why Should You Care?

1. Catch Errors Early

// This will blow up at runtime somewhere deep in your code
const user = { name: "Bob", age: "thirty-five" };
calculateInsurance(user.age * 1.2); // NaN strikes again!

// This gets caught immediately with schema validation
// Error: /age: should be number

2. Self-Documenting APIs

Your schema IS your documentation. No more outdated API docs that say age is a number when it's actually a string.

3. Frontend/Backend Agreement

When both sides validate against the same schema, miscommunication becomes impossible. It's like having a peace treaty for your data structures.

4. Better Error Messages

Instead of "Something went wrong," you get "Property 'email' should match format 'email'." Your users (and your future self) will thank you.

Coming Up Next...

In Part 2, we'll dive deep into implementing JSON Schema validation with AJV, including:

Setting up AJV in your project
Advanced validation features
Custom keywords and error messages
Performance optimization tips

Ready to never debug mysterious data issues at 2 AM again? Let's make it happen! 🚀

Series Navigation:

Part 1: Understanding the Basics ← You are here
Part 2: Implementation with AJV
Part 3: Real-World Applications & HAL