DEV Community: Kushang Tailor

AbilityGuard v1.1: I Gave My Abilities API Monitor a Memory (and a Voice)

Kushang Tailor — Wed, 05 Aug 2026 16:35:57 +0000

A few weeks back I published an article upon my latest AbilityGuard plugin so you could actually see what the WordPress Abilities API was doing on your site — which abilities were registered, which ones were risky, and what ran when nobody was watching.

That part worked. But pretty quickly I ran into a problem I should've seen coming: a monitor that only shows you the last 100 log entries and makes you stare at the screen isn't really monitoring anything. It's just a mirror. You still have to be looking at it at the exact moment something happens.

So v1.1 isn't a "few bug fixes" release. It's the release where AbilityGuard stopped being a dashboard and started being something closer to a watchdog — one that remembers, filters, exports, flags, and taps you on the shoulder when it needs to.

🧠 The Problem With a 100-Entry Memory

The original execution log was capped at a rolling 100 entries. Fine for a quick check. Useless for an actual audit trail. If you wanted to know what an ability did last Tuesday, and 150 executions had happened since, that data was just gone.

So the first thing I fixed in 1.1 was retention itself. You can now configure how many log entries AbilityGuard keeps — including unlimited retention if you want a permanent record. No more silently losing history because the log rotated while you weren't looking.

Of course, unlimited retention is only useful if you can actually find what you're looking for inside it. Which brings me to the next piece.

🔍 Filters That Don't Fight Each Other

The old filter set technically existed, but it wasn't built for real audit work. In v1.1 I rebuilt it as advanced execution log filters — status, trigger context, risk level, category, user ID, date range, and free-text search, all combinable.

The detail that actually took the most iteration wasn't adding filters, it was making them behave independently. Previously, selecting one filter could quietly narrow or reset another in a way that wasn't obvious. Now each filter selection stands on its own, so "show me destructive abilities triggered via REST by user 14 last week" actually returns what you'd expect, instead of a filter fighting itself behind the scenes.

Once you've built a filter combination you actually care about, you shouldn't have to rebuild it every time. So I added saved views — save a filter set once, reuse it from a dropdown. If you're doing weekly reviews, this alone probably saves you the most clicks.

And once you've filtered down to the exact slice of log you care about, you'll usually want to take it somewhere else — which is exactly what CSV export is for.

📤 Getting Data Out of the Admin Screen

Every filtered log view can now be exported to CSV directly from the current view. This wasn't a hard technical problem, but it mattered a lot — because plenty of AbilityGuard users aren't just checking a dashboard, they're pulling this data into a compliance report, a security review, or a spreadsheet someone else on the team is going to read.

👀 The Watchlist: Not All Abilities Deserve Equal Attention

Here's the thing about a site with the Abilities API active — you might have dozens of registered abilities, and realistically only a handful of them actually worry you. The ones marked destructive. The ones an AI agent could trigger unattended. The ones tied to user data.

v1.1 adds a sensitive ability watchlist so you can flag exactly those abilities for closer attention, instead of treating every entry in the inventory as equally important. It's a small feature on paper, but it's the one that changes how you actually use the plugin day to day — you stop scanning everything and start watching what matters.

And a watchlist that requires you to keep checking back is still passive. So the next two features exist to close that gap.

📧 Email Alerts and Scheduled Reports

This is the part that turns AbilityGuard from "something I check" into "something that tells me."

Email alerts fire for high-risk, failed, or watchlisted ability executions — so if something destructive runs, or something fails, or a watched ability triggers, you find out without opening wp-admin.
Scheduled reports send a daily or weekly summary of activity, so even if nothing alarming happened, you still get a pulse check in your inbox. Between the two, you get both ends of monitoring covered: immediate notice when something risky happens, and a steady rhythm of visibility even when nothing does.

🌐 Multisite Finally Gets Its Own Dashboard

If you're running a network, checking abilities site by site was never going to scale. v1.1 adds a Network Admin dashboard that shows per-site ability and log counts in one place, so a network admin can spot which site is generating unusual activity without switching contexts twenty times.

And while I was in the multisite code, I found (and fixed in the 1.1.1 patch) a bug where uninstall cleanup only ran on the main site instead of every site in the network. If you'd removed AbilityGuard from a multisite install, subsites were quietly keeping their data behind. That's fixed now — cleanup runs network-wide.

The 1.1.1 patch also brought the inventory detail popup in line with the execution log's detail modal, so the two feel like the same plugin instead of two screens that were designed a week apart.

🧩 What Didn't Change

No new abilities are logged that weren't logged before. AbilityGuard still only tracks Abilities API registrations and executions — not general WordPress admin actions like post edits or media uploads. That boundary was intentional in 1.0, and it's still intentional now. This release is about doing more with the data AbilityGuard already collects, not collecting more kinds of data.

Payload logging also stays privacy-conscious by default: output logging is still off unless you turn it on, same as before.

🛠️ Where This Goes Next

Retention, filters, exports, watchlist, alerts, reports, multisite — that's a lot for one point release, and it's the reason it took a few weeks instead of a few days. What's next is less about adding more surfaces and more about making the existing ones smarter — better risk scoring, and eventually, a Pro tier for teams that need more than a single site's worth of visibility. More on that when it's actually ready to talk about.

If you're running the Abilities API on your site — whether it's your own plugins registering abilities or third-party AI tools doing it for you — v1.1 is a straightforward update. No config migration, no breaking changes, just a plugin that remembers more and bothers you less.

You can grab it from the WordPress.org plugin page.

From a 10-Minute Nap to 300+ Installs: The Story of My 'Restrict WP Upload Type' Plugin

Kushang Tailor — Mon, 03 Aug 2026 12:13:58 +0000

📼 It Started With WordPress 4.7

I still remember the version number: WordPress 4.7. That's when I properly started my journey as a WordPress developer. Not as a "I read a tutorial and now I'm an expert" kind of start — more like a "I broke a client's site three times before lunch" kind of start.

Those were good years, honestly. I built a lot of sites. Small business sites, portfolio sites, e-commerce stores. But there was one problem that followed me across almost every single project, like a background process that never quits: the media library.

Sites would crash. Uploads would eat up server resources. And every now and then, out of nowhere — the dreaded white screen of death, right after someone in the client's team uploaded "just one more file."

🩹 The Debugging Loop I Knew Too Well

Every time this happened, I went into the same routine. Open the error logs, check the wp-content/uploads folder, check PHP memory limits, and dig line by line until I found the culprit.

And more often than not, the answer was almost embarrassingly simple:

A corrupt file that somehow made it through upload
A heavy media file nobody bothered to compress
Someone uploading a .exe or .zip disguised as an image — sometimes by mistake, sometimes not

None of these were WordPress core problems. They were upload hygiene problems. But WordPress, out of the box, doesn't really give site owners a simple way to say "only allow these file types, nothing else." So every time, I'd write a quick one-off fix for that one client, ship it, and move on. It solved the symptom. It never solved the actual disease.

Now, to be fair — the White Screen of Death isn't only caused by bad uploads. Over the years I've seen it come from all sorts of directions: a plugin conflict, a theme function throwing a fatal error, PHP memory limits being exhausted, a corrupted .htaccess file, or even a simple PHP version mismatch after a server update. Uploads were just the culprit I kept running into the most.

🚀 New Job, New Plugins, New Skills

Time moved on, and so did I. I switched companies, and with the new job came new opportunities — this time, actual plugin and theme development work, not just "fix this WordPress site" freelance gigs.

This is where I really understood how plugins and themes are built from the ground up. I started building plugins for clients and for in-house company websites, and eventually shipped my very first personal plugin on WordPress.org — Product Category.

That first release taught me a lot: how WordPress.org review works, how real users behave differently than you expect, and how a plugin is never really "done" — it just moves into its next version.

💤 The Idea That Came During a Nap

Here's the part of the story I still find funny. In early 2022, I was taking a short 10-minute nap — the kind where your brain refuses to fully switch off. And in that half-asleep state, old memories started resurfacing. Corrupt uploads. Wrong file extensions. Clients accidentally uploading a .zip where an image was supposed to go. Years of the same recurring headache, replaying like a highlight reel.

And then the thought hit me:

"What if there was one simple plugin where a site owner could just check which file types are allowed — and everything else gets blocked automatically?"

No more one-off fixes per client. No more custom snippets copy-pasted from an old project. Just one clean toggle-based settings screen.

That nap turned into a plan.

🧩 Planning Before a Single Line of Code

I didn't jump straight into the editor. I sat down and actually mapped out the plugin — what file types needed support, how the settings screen should look, how validation should happen both on the frontend and the server side (because client-side checks alone are basically decorative).

After the research phase, I started building. Following pure OOP structure, keeping things aligned with WordPress coding standards, and making sure every single input was properly sanitized, validated, and escaped — non-negotiables for me, then and now.

🐛 "It Worked Locally... So Why Is Production Rejecting Everything?"

After a solid months of development, the plugin was functionally complete. Time for testing.

I ran it on a few local environments first — smooth. Then I moved it to some live production sites for real-world testing, and that's when things got interesting: uploads stopped working entirely. Every single file, blocked. Media library, dead silent.

My first reaction was pure confusion — it worked perfectly on local, so why was production behaving like it had personally decided to reject every file on Earth?

I dug in. Checked hooks, checked filter priorities, checked MIME validation order. Eventually I traced it back to a plugin conflict — another plugin on those production sites was hooking into the same upload filters, and the two were essentially fighting over who gets the final say on what's "allowed."

So I went back in, added new compatibility functions, and reworked the restriction logic to play nicely with other plugins instead of assuming it owned the upload pipeline alone. Retested. This time — it worked like a charm.

🎉 Launch Day: April 2022

After that final round of verification, I published Restrict WP Upload Type on WordPress.org in April 2022.

If you check the plugin today, it does exactly what that half-asleep idea imagined:

Control over 97 file extensions and MIME types
A simple allow/block toggle for each format
A dedicated SVG security toggle, since SVGs need special handling
Real-time validation that blocks bad uploads before WordPress even shows its generic error
A global file size limit
Zero configuration complexity — install, check some boxes, done

⭐ What the Reviews Taught Me

Shipping the plugin wasn't the finish line — it was the starting line for actually listening. The plugin currently sits at a clean 5-star average across its reviews, and every one of them nudged the roadmap in a real direction.

One review praised how simple and effective the restriction logic was. Another user pointed out something I hadn't considered — they wanted the Restrict Files menu tucked inside the Media menu instead of sitting on its own, and asked for a clearer message telling users which plugin blocked their upload, so support requests wouldn't turn into a guessing game. Another review flagged a rough patch where settings weren't saving properly for one specific site.

I took all of it seriously. Over the following versions, I:

Moved the settings page under Media > Restrict Files, exactly as requested
Added a global max file size control
Made the blocked-upload message fully customizable, so site owners can explain exactly why a file was rejected
Improved validation so it runs before WordPress's generic security error even shows up
Added a settings search and enabled/disabled filters, since scrolling through 97 file types isn't fun for anyone
Tightened up nonce protection and added a proper uninstall cleanup routine

Four reviews might not sound like a lot on paper, but each one represented a real site, a real workflow, and a real reason to keep improving.

🔮 What's Next

The plugin has grown a lot since that April 2022 launch — from a one-page toggle screen to a proper settings experience with search, custom messaging, and file size controls. But I'm not done.

Next on the roadmap: deeper role-based restriction controls, so different user roles can have different upload permissions instead of one global rule for everyone — along with custom MIME type management and upload logs, so site owners get more visibility into who's uploading what.

It's a small plugin in the grand scheme of the WordPress ecosystem. But it came from a real, recurring frustration — and honestly, that 10-minute nap in early 2022 might be one of the more productive naps of my career.

If you manage WordPress media libraries and have ever stared at a white screen after someone uploaded "just one file," you can find Restrict WP Upload Type on WordPress.org.

🛡️ Building AbilityGuard: Monitoring the WordPress Abilities API in Production

Kushang Tailor — Thu, 30 Jul 2026 15:20:05 +0000

A few weeks ago I wrote about the WordPress Abilities API — what it is, why WordPress 6.9 shipped it, and what it means for how plugins will talk to each other and to AI agents going forward. That post was theory. This one is the part where theory meets a composer.json file and a stubborn bug at 1 AM.

This is the story of building AbilityGuard — a plugin that monitors Abilities API usage in production, so you actually know what's happening when abilities get registered, called, and (occasionally) abused.

👀 Why monitoring, and why now

Here's the thing about the Abilities API that got me nervous the first time I really understood it: it's a capability surface. Any plugin can register an ability. Any authorized caller — a human-triggered action, an automation, or increasingly, an AI agent — can invoke one. That's the whole point of the API, and it's genuinely exciting. But it also means your site now has a growing list of "things that can be done to it programmatically," and most WordPress admins have zero visibility into that list.

I've spent enough years debugging WordPress sites in production to know what happens when you can't see something: you find out about it during an incident, not before. Slow queries, rogue cron jobs, plugin conflicts — they all follow the same pattern. Nobody notices the small thing until the small thing becomes the outage.

So the idea for AbilityGuard was simple: give site owners a dashboard and a log for every ability registered on their site, every time one gets called, and by whom. Not another abstract "security scanner" — just honest, readable visibility into a part of WordPress that's brand new and mostly invisible right now.

🔌 Where I started: hooking into the registry, not fighting it

The Abilities API exposes a central registry (wp_get_ability_registry() under the hood, with helper functions layered on top). My first instinct was to intercept ability calls by wrapping core functions — and I killed that idea within the hour. Wrapping core functions is exactly the kind of thing that breaks on the next minor release and turns your plugin into the villain of someone else's changelog.

Instead, AbilityGuard hooks into the lifecycle events the API already exposes: registration, before-execution, and after-execution actions. That's the whole trick. I'm not intercepting anything — I'm listening. When an ability is registered, I capture its metadata (name, description, input/output schema, permission callback). When it's executed, I capture the caller context, the arguments passed, the execution time, and the result status.

That distinction — listening instead of wrapping — ended up shaping almost every architectural decision that followed.

🏗️ The architecture: keeping the pieces simple, so nothing breaks quietly

I could get technical here, but honestly, the idea behind the build is simple enough to explain without any code.

Think of AbilityGuard as three small, separate jobs living under one roof, and none of them stepping on each other's toes:

One part just watches. It sits quietly and notices whenever an ability is registered or run — it doesn't touch anything, doesn't change how the site behaves, it just pays attention.
One part writes it down. Whatever the first part notices gets recorded neatly — what happened, who triggered it, and how (through the website, a command line, an automated schedule, or regular code).
One part shows it to you. The inventory and execution log you see in your WordPress admin area is just a clean readout of what the other two parts already collected. Each of these pieces only knows how to do its own job and nothing else. The "watcher" doesn't know how logs get stored. The "writer" doesn't know how the admin screen looks. That separation sounds like a small detail, but it's the reason the plugin can stay light and predictable — if I ever need to change how something is displayed, I'm only touching the "display" piece, not the parts responsible for actually catching and recording the activity.

For a monitoring tool, that predictability matters more than clever code. A plugin whose entire job is to watch quietly in the background should never be the thing that causes a problem.

🔒 The part nobody wants to think about: sanitize, validate, escape — for data you don't control

This is where AbilityGuard gets a little more interesting than a typical CRUD plugin, because the "input" isn't a form field a human filled in — it's arbitrary arguments passed to an ability, possibly by an automated caller. I can't assume anything about shape or intent.

Every argument captured for logging goes through explicit validation against expected types before it's ever sanitized or stored — nothing gets written on faith. Output is escaped at render time, not at storage time, which is the rule I see broken most often in plugins I audit: people sanitize once on the way in and assume that protects them on the way out. It doesn't. Two different jobs, two different moments.

// LogRepository.php (simplified)
public function insert_event( array $event ): int {
    $sanitized = array(
        'ability_name' => sanitize_key( $event['ability_name'] ),
        'trigger_type' => sanitize_text_field( $event['trigger_type'] ), // rest, wp-cli, cron, php
        'status'       => in_array( $event['status'], array( 'success', 'failure', 'denied' ), true )
            ? $event['status']
            : 'unknown',
        'input'        => $this->logging_enabled( 'input' ) ? wp_json_encode( $event['input'] ) : null,
        'output'       => $this->logging_enabled( 'output' ) ? wp_json_encode( $event['output'] ) : null,
        'created_at'   => current_time( 'mysql', true ),
    );

    return (int) $this->wpdb->insert( $this->table_name, $sanitized );
}

Two decisions there came straight out of thinking about what an admin would actually want, and what they'd regret leaving on by accident. Input logging is configurable, and output logging is off by default, because ability responses can carry sensitive or genuinely large payloads and I'd rather someone opt in deliberately than discover a log table quietly filling up with data they didn't mean to store. On top of that, the log itself is a rolling window of the latest 100 execution entries rather than an ever-growing table — visibility without turning into its own storage liability. And none of it leaves the site: everything stays in a single custom table, {$wpdb->prefix}ability_guard_logs, with no data sent to an external service.

😮 What surprised me while building this

Two things I didn't expect going in.

First, how much discipline it took to not scope-creep into a general activity log. It would have been easy to also log post edits, media uploads, settings changes — the usual audit-log territory. I deliberately left all of that out. AbilityGuard only logs what runs through a registered ability's native execution hooks; if an action doesn't go through the Abilities API, AbilityGuard stays quiet about it. That restraint is the whole point — it's a focused lens on one new capability surface, not a replacement for a general audit log plugin.

Second, how much the "listener, not wrapper" decision simplified everything downstream. Because ExecutionListener only hooks into native ability execution hooks instead of patching internals, trigger context — REST, WP-CLI, cron, or plain PHP — falls out of the hook data for free. I didn't have to reconstruct how something ran; the API already tells me.

🚀 Where it goes next

The next thing on my list is extending AbilityGuard toward accessibility auditing — using the same "listen, don't wrap" pattern to flag abilities whose responses might affect assistive technology output. That's still early, but it feels like a natural second act for a plugin whose whole reason for existing is making the invisible visible.

If you're building on the Abilities API yourself — whether that's registering your own abilities or just trying to understand what's already running on your site — I'd genuinely like to hear what you're building. This corner of WordPress is still small enough that we're all figuring it out together.

🔗 AbilityGuard is live on WordPress.org: https://wordpress.org/plugins/ability-guard/

I Sold My PS5. A Very Big Step.

Kushang Tailor — Sat, 25 Jul 2026 12:09:17 +0000

I know from the title you're thinking, "What does a PS5 have to do with a big step?" But c'mon, we all know this — nobody hates PlayStation. Everyone loves it. Some people bought it on EMI, some paid full price without blinking, some just saved for months to finally get their hands on one. No matter the cost, everyone wants it in their living room.

And it's not like the timing was even good. Two massive upcoming games are lined up — GTA 6 and John Wick. Yeah, the games that gamers like me have been waiting for, refreshing trailers, checking release dates every other week. So selling my PS5 right now, right before all that? Trust me, it hurt more than it sounds.

But here's the thing about big steps — they're rarely the fun kind.

💸 The Real Reason

I wasn't proud of admitting this, but I'll say it plainly because that's the whole point of writing this: I was going through a financial crisis. Not the dramatic kind you see in movies, just the quiet, everyday kind — bills stacking up, income drying up, and that constant math running in your head every single day. You know the feeling. You open your banking app, do the mental subtraction, and close it again pretending you didn't just do that.

I'd been picking up Uber delivery shifts on my bike to fill the gaps, something I've written about before — You can check here. It helped, but it wasn't enough to cover everything. Some months you patch the hole. Other months the hole is just bigger than the patch you have.

So I sat there one evening, phone in hand, staring at my PS5 sitting quietly under the TV. It wasn't collecting dust — I loved that thing. But love doesn't pay bills, and I had to be honest with myself about what mattered more right now.

🎮 Making the Call

I'm not going to pretend this was some heroic, easy decision. It wasn't. I went back and forth for a couple of days. I even checked the resale price twice hoping it'd somehow answer the question for me. But at some point you just have to stop overthinking and act, because the tension of not deciding is worse than the decision itself.

I listed it. Priced it fair — not a giveaway, but not greedy either. Within a few days, I got a buyer. Someone genuinely excited to take it home, probably as pumped about GTA 6 as I was. There was a small, weird moment of handing it over — like saying bye to a good friend who's moving to another city. You're happy for them, a little sad for yourself.

🌤️ What Happened Next

Here's the part that actually matters: I got a genuinely good amount for it. Good enough that next month's tension just... vanished. That constant low-grade stress I'd been carrying for weeks? Gone, at least for a while.

And because of that breathing room, I did something I didn't expect — I temporarily stopped the Uber deliveries. Not because I don't need that income anymore, but because for the first time in a long time, I wasn't running on empty. I could actually sit, think, plan, and not just react to whatever bill showed up next.

✍️ Why I'm Writing This

Honestly? Because I think we don't talk about this stuff enough. Everyone posts the wins — the new gear, the new setup, the "look what I bought" content. Nobody really posts "I sold my PS5 because I needed the money." It feels a little embarrassing to admit, even now while typing this.

But I think that's exactly why it's worth sharing. Financial pressure isn't rare. It's not a personal failure. It's just life catching up sometimes, especially when you're juggling freelance income, gig work, and unpredictable months. Selling something you love isn't defeat — it's just a decision. A trade-off. You give up a want to protect your stability, and that's not weakness, that's just being an adult about it.

Will I buy a PS5 again someday? Probably, yeah. Maybe when GTA 6 actually drops and I've got some cushion built back up. But for now, I don't regret it. It did exactly what I needed it to do — it gave me one less thing to worry about, and that's worth more than any game right now.

Sometimes the "big step" isn't buying something new. Sometimes it's letting go of something you love, for the version of you that needs it more.

📸 One Last Look

Before I handed it over, I took one last photo. Felt a little silly doing it, honestly — like taking a picture with an old friend before they leave. But I'm glad I did. It's a small reminder of where I was, the decision I made, and why I made it. Not everything worth keeping has to stay in your living room.

The Bug I Fixed Nine Times Before I Finally Killed It For Good

Kushang Tailor — Mon, 20 Jul 2026 15:39:03 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

🎭 The Recurring Villain

If you've built WordPress sites long enough, you know this bug. It doesn't show up as an error in your console. It doesn't throw a fatal exception. It just quietly sits there, page after page, client after client — and it's called video bloat.

Nine years into web development, I lost count of how many times a client sent me a site with a message like "it's just... slow." And nine times out of ten, when I opened DevTools and checked the waterfall, the story was the same: three, four, sometimes ten embedded YouTube videos, each one dragging in its own iframe, its own set of scripts, its own chunk of megabytes — all loading the second the page rendered, whether the visitor scrolled past them or not.

One video embed alone can pull in 500KB–1MB+ before a user even presses play. Multiply that by a landing page stacked with testimonials, product demos, and a hero video, and you've got a page that fights your Core Web Vitals before it's even finished loading.

🔁 The Manual Fix (Every. Single. Time.)

For years, my solution was the same tedious ritual:

Find every video embed on the page.
Replace the iframe with a static thumbnail image.
Write a bit of custom JavaScript to swap the thumbnail for the real embed on click or scroll.
Repeat it for YouTube.
Repeat it again for Vimeo, because Vimeo's oEmbed API works differently.
Repeat it again for self-hosted <video> tags, because now you're dealing with <source> tags instead of iframes.
Test it across whatever page builder the client was using — Elementor, Divi, WPBakery, or straight-up Gutenberg blocks — because every one of them nests the video markup slightly differently. It worked. But it was never reusable. Every project meant writing the lazy-load script again, half from memory, half copy-pasted from my own old projects, tweaked just enough to fit the new theme's markup. It was the same bug, wearing a different site's clothes each time.

💡 The Moment It Clicked

The turning point wasn't one dramatic incident — it was the accumulation. After the fifth or sixth time writing near-identical vanilla JS to defer a YouTube iframe, I finally asked myself the obvious question: why am I solving this per-project instead of solving it once?

That's what pushed me to stop patching symptoms and build VidDefer — a plugin that treats video lazy-loading as a solved problem you should never have to think about again.

🛠️ How VidDefer Actually Fixes It

The core trick is that VidDefer doesn't care how or where your video got onto the page. Instead of hooking into specific page builders one by one (which is a losing battle — there's always a new builder), it uses PHP output buffering to intercept the final rendered HTML before it reaches the browser. Any YouTube iframe, Vimeo iframe, or self-hosted <video> tag gets swapped for a lightweight thumbnail-and-play-button placeholder — regardless of whether it came from Gutenberg, Elementor, Divi, WPBakery, or hand-written HTML in a Custom HTML block.

The real video only loads when a visitor actually clicks, or scrolls near it — saving hundreds of kilobytes on every page load where a video isn't watched (which, statistically, is most of the time).

A few details I was stubborn about while building it:

Zero configuration. Activate it, and it just works. No setup wizard required, though there's a settings screen if you want to tweak things.
No jQuery. Pure ES6, under 2KB gzipped. The whole point is performance — the fix itself shouldn't add weight.
Per-source handling done properly. YouTube thumbnails come straight from YouTube's public CDN (no API key needed). Vimeo thumbnails come through Vimeo's oEmbed endpoint and get cached locally via WordPress transients, so your server isn't pinging Vimeo on every single page load.
Accessibility wasn't optional. The placeholders are keyboard-navigable and follow WCAG 2.1, because a performance fix that breaks accessibility isn't a fix.
An escape hatch. Some videos — popups, lightboxes — shouldn't be touched. A simple no-lazy class tells VidDefer to leave them alone.

⚡ Before vs. After

Here's where I want to be upfront instead of hand-wavy: I'm not going to drop a flashy "300% faster!" screenshot in this post, because that number would either be fake or borrowed from a client site — and client performance data isn't mine to publish. Privacy first, always.

What I can tell you honestly: VidDefer just landed on WordPress.org. It's brand new. So instead of cherry-picking an old result, I'd rather show you real, verifiable numbers once they exist — a proper before/after on a demo site loaded with heavy video embeds, tested with actual Lighthouse and PageSpeed runs, out in the open where anyone can double-check it.

That's next on my list: building a public demo site stacked with YouTube, Vimeo, and self-hosted videos, and publishing the raw before/after report for everyone to see — no cherry-picking, no marketing spin. If you're curious, that follow-up post is coming.

What I can say with confidence today, from nine years of doing this fix by hand: every unloaded iframe is bytes and requests your browser simply never has to make. The math isn't controversial — deferring what the visitor hasn't asked to see yet is a straightforward win. I just want to show you that win with real data, not tell you about it.

🎓 What I Learned

The real lesson here wasn't about video embeds at all — it was about recognizing when you're solving the same bug over and over and calling it "just part of the job." If you find yourself writing a similar patch for the third or fourth time, that's not a coincidence. That's a signal that the fix belongs in a tool, not in your muscle memory.

For me personally, the fix that used to take an hour or two of custom scripting per project now takes the time it takes to click "Activate." That alone was worth building.

VidDefer is live on WordPress.org now, and every install is one fewer freelancer somewhere staying up late writing the same lazy-load script I used to write.

🔗 VidDefer – Deferred Video Embeds on WordPress.org

100+ Job Applications, 2 Months, Zero Offers — Why I Started Riding an Uber Delivery Bike

Kushang Tailor — Fri, 10 Jul 2026 14:18:11 +0000

Never break when your time is tough — just stay calm, stay active, and keep moving.

🎯 The Application That Broke Me

I stopped counting after 100.

I applied to every role that matched my resume, including:

WordPress Developer
Full-Stack Developer
Frontend Developer
Backend Developer
Business Development Executive - Entry Level
Project Manager - Entry Level
Junior React Native Developer
Senior WordPress Developer

Two months. Every relevant listing I could find. Custom cover letters for the ones that mattered. Follow-ups. LinkedIn messages to hiring managers who never wrote back.

Nothing worked out.

Not one offer. Barely a handful of interviews. A few "we'll get back to you" emails that never came back.

So a few weeks ago, I picked up a food and package delivery job on Uber, riding my own Hero Xtreme 125 through morning and evening traffic. I'm writing this because I think a lot of developers reading this are living some version of the same story right now, and nobody in our field likes to say it out loud. I do.

📊 The Market Isn't in Your Head — It's Actually This Bad

If job hunting in 2026 feels harder than it should, that's not you being unskilled or unlucky. The numbers back you up.

The time it takes to get a first job offer jumped from 57 days to 83 days in 2025 — almost a month and a half longer than before. Entry-level hiring at the biggest tech companies dropped 25% between 2023 and 2024, and it still hasn't bounced back. Software job postings are still down more than a third from pre-pandemic levels, and about 7% lower than they were just a year ago.

It's not just a "big tech" problem either. At one well-known Indian engineering institute, fewer than a quarter of a graduating class of 400 students had job offers just months before their course ended. Students there are calling it a "jobpocalypse." Tech layoffs crossed 150,000 in a single year not long ago, and even though the number has come down since, Q1 2026 alone saw close to 80,000 more tech workers lose their jobs.

Here's the part that hurts if you're early in your career: it's not spread evenly. Jobs for young software developers have dropped almost 20% from their late-2022 peak. Senior and specialist roles are actually growing at some companies — Google alone posted 62% more engineering openings in the first half of 2026 than a year earlier — but that growth sits at the top of the experience ladder, not at the entry point most of us are trying to get through.

So if you've sent 50, 80, 100+ applications and heard mostly silence — you're not the exception. You're the current normal.

⚡ What's Actually Causing This

Four things are happening at once, and it helps to name them instead of just feeling them.

1. AI is eating the "easy" tickets first. Company leaders aren't hiding it anymore. Microsoft's CEO has said AI now writes a real chunk of the code in some of their projects. Salesforce's CEO said his company hired zero new engineers in a recent year because AI tools closed that gap. The small, simple tasks that used to be a junior developer's way in — quick bug fixes, boilerplate features, basic integrations — are exactly what AI coding tools now handle well. That doesn't mean developers are useless, but it does remove a lot of the "starter" work companies used to hire freshers for.

2. Companies are still recovering from over-hiring in 2021-2022. A lot of today's layoffs trace back to companies that doubled their engineering teams during the cheap-money pandemic years and are now cutting that back. This has nothing to do with your skills. It's a hiring hangover that started years before you even applied.

3. Global conflicts are adding extra pressure on hiring budgets. With active wars and unrest going on in multiple regions right now, companies are dealing with higher energy costs, shakier supply chains, and more cautious investors. Reports through 2026 show business leaders openly saying this instability is a factor in tighter, slower hiring decisions — money is moving toward "safe" spends like cybersecurity and core AI infrastructure, and away from riskier hiring plans, especially at the entry level.

4. The bar for "entry-level" quietly moved higher. Companies don't just want a degree and a to-do-list app on your GitHub anymore. They want real, shipped work — actual projects, actual collaboration, actual production experience — squeezed into what used to be an entry-level ask. It's a classic trap: you need production experience to get hired, and you need to get hired to gain production experience.

None of this means the field is dying. Developer roles are still expected to grow well into the next decade, and plenty of companies are hiring hard for the right profile. But "the right profile" has shifted, and nobody warns you about that shift until you're three months deep into rejections.

🚀 What Skills Are Actually in Demand Right Now

Going through current hiring data and job posts, the same pattern keeps showing up:

Working with AI tools is no longer a bonus — it's expected. More than half of tech job posts now ask for AI/ML familiarity, and daily use of tools like GitHub Copilot, Cursor, Codex, or Claude Code is fast becoming a basic skill, not an impressive one.
Depth over "I can do everything." The generalist pitch is losing ground to developers with real, provable depth in one lane — cloud, DevOps, ML, security, or a specific ecosystem.
For WordPress specifically, the bar has moved well past "I can install a theme and turn on WooCommerce." Companies now want REST API and headless WordPress experience, React-based block development, clean OOP plugin architecture, solid Git habits, and comfort with the platform's built-in AI tooling. WordPress still runs over 40% of the web, so the demand is real — it's just concentrated on developers who've moved past template installs.
Proof over polish. A strong GitHub history, published articles, or real shipped projects now carry more weight than a clean resume, since most hires still come through referrals and visible work, not cold applications.

⚖️ My Skills vs. What's Actually Demanded

Here's where I had to be honest with myself instead of just angry at the market.

What I bring: I've built and shipped 4 WordPress plugins from scratch, following pure OOP architecture, WordPress VIP coding standards, and proper sanitization/escaping at every layer. I've built enterprise-level websites and web apps using React and Next.js, including headless WordPress setups where the frontend is fully decoupled from the CMS. Performance and security aren't an afterthought for me — I bake them into the build from day one, whether that's caching strategy, query optimization, or basic hardening against common attack vectors. I also actively use AI tools like Codex, Claude, and GitHub Copilot as part of my real workflow — not just to autocomplete a line, but to help scaffold plugins, debug tricky WordPress hooks, and speed up full web app builds. On top of that, I keep a solid, active GitHub history and write technical articles regularly, so my work is documented and public, not sitting in private repos nobody sees.

Where the gap actually is: the problem wasn't that I lacked AI fluency — I use these tools daily and build with them. The real gap was in how I was positioning myself. I was applying into the same volume-heavy, entry-level pool as everyone else, instead of clearly showing recruiters that I already work the way the market now expects: AI-assisted, specialization-focused, with real production and architecture experience behind me. My resume wasn't telling that story loudly enough.

That gap isn't a character flaw. It's a positioning problem, and it's fixable — just not in the two months I had bills to pay in the meantime.

🛵 Why I Joined Uber

I didn't join Uber because I gave up on development. I joined because rent, food, and basic responsibilities don't pause for a job market correction, and two months of zero income while sending applications into a void just isn't sustainable for anyone.

Delivery work on my own bike gave me something a regular part-time job couldn't: income starting almost right away, with zero disruption to my ability to keep applying, interviewing, and writing during the hours I wasn't riding. It's physically harder than sitting at a desk, and yes, some pride had to be swallowed. But a bridge is a bridge, and I'd rather ride one than fall through the gap it's covering.

✅ The Onboarding Process Was Refreshingly Simple

Compared to the black-hole application process I'd just been through, signing up to deliver was almost jarring in how simple it was:

No bond. No lock-in agreement of any kind.
No fixed shift hours — I choose when I ride, and I choose when I stop.
Document verification, a basic orientation, and I was live on the app within days, not weeks.
Full control to log off any time — no penalty for taking a day off for an interview or a writing deadline. That flexibility is exactly why it works as a bridge income source. I run two shifts a day — morning and evening — and build the rest of my day around job hunting and content work.

💰 The Actual Numbers: What My Hero Xtreme 125 Earns Me

Let's do this properly, because vague "I make decent money" claims don't help anyone else weighing this option.

My setup: a Hero Xtreme 125, petrol at roughly ₹100/liter, riding two shifts a day — morning and evening — spending roughly ₹100 in fuel per shift (about ₹200/day, close to 2 liters). I also take one full day off every week to rest, both for me and the bike.

Hours/day	Gross earning	Fuel cost	Net earning/day
6 hrs (standard)	₹700–800	~₹200	₹500–600
8 hrs (extended)	₹1,000+	~₹200–250	₹750–800+
10 hrs (long day)	~₹1,250–1,300	~₹280–300	~₹950–1,000
12 hrs (max stretch)	~₹1,450–1,550	~₹320–350	~₹1,100–1,200

Notice the per-hour rate drops a bit as the hours climb — that's normal, since the best surge-pricing windows (early morning and evening rush) get used up first, and the extra hours are usually slower, lower-paying stretches.

Scaling this out with a weekly off day built in — roughly 26 riding days a month:

Period	6 hrs/day	8 hrs/day	10 hrs/day	12 hrs/day
Monthly (net)	~₹14,300	~₹20,000–20,800	~₹25,350	~₹29,900–31,200
Yearly (net)	~₹1,71,600	~₹2,40,000–2,49,600	~₹3,04,200	~₹3,58,800–3,74,400

A quick mileage sanity check: the Xtreme 125 is rated over 60 kmpl on paper, but real-world, stop-start delivery riding usually brings that down to somewhere between 40 and 50 kmpl. At ₹100/liter, that's roughly ₹2–2.5 per km, which lines up closely with the ₹200/day I actually spend across two shifts covering around 80–100 km total.

Worth being upfront about the parts this table doesn't show: chain lubrication, oil changes, tyre wear, and regular servicing add up over months of daily riding. So the real net is a little lower than the fuel-only numbers suggest once you spread maintenance across the year. I'd set aside roughly ₹500–800 a month for that on top of fuel.

It's not developer-salary money. It's not meant to be. It's meant to keep the lights on while I fix the real problem — landing the next role.

💭 A Few Things I'd Add From My Side

A few honest thoughts that didn't fit neatly into the sections above but felt worth saying:

This isn't a failure story, it's a sequencing story. The job search didn't stop. It just stopped being the only thing paying the bills while it played out.
Writing kept me sane. Publishing articles and working on side projects during this stretch gave me something the job hunt alone couldn't — a sense of moving forward on days when applications went nowhere.
The stigma is the hardest part, not the job itself. Riding a delivery bike after years of writing production code messes with your head more than the physical work does. Worth saying plainly, because I suspect a lot of developers going through something similar feel that shame alone.
Flexibility is underrated as a survival tool. A gig with no bond and no fixed hours meant I never had to choose between an interview and a shift. That mattered more than the pay itself.
The market will turn — but not by waiting. Every report on this points the same way: demand for developers who can specialize and work fluently with AI tools is actually growing, even while generic entry-level postings shrink. The move isn't to give up on development. It's to close the gap between how you're positioned and what's currently getting hired.

🌱 Where This Leaves Me

I'm still applying. I'm still writing. I'm still building and the rest of my plugins work in whatever hours are left after two shifts on the bike. The Uber income isn't the destination — it's what's making sure I don't have to pause the actual goal while the market sorts itself out.

If you're in the same spot right now — sending applications into what feels like a void — you're not behind, and you're not broken. The data shows the market genuinely shifted under everyone's feet at the same time. The only real move is to keep adjusting how you show up, while keeping the lights on however you need to.

If this resonated with you, or you're going through something similar, I'd genuinely like to hear how you're handling it. Drop a comment.

Sources referenced: IEEE Spectrum, Rest of World, The Pragmatic Engineer's 2026 job market deep-dive, Final Round AI's 2026 software engineering market report, Second Talent's 2026 tech job market trends, SQ Magazine's layoff statistics roundup, Forbes' 2026 midyear geopolitical trends tracker, IDC's 2026 IT spending outlook, and current WordPress hiring guides from Wisemonk and Boundev.

Why I Stopped Trusting 'Just Embed the Video' and Built VidDefer Instead

Kushang Tailor — Tue, 07 Jul 2026 13:00:00 +0000

🎬 Why I Built VidDefer — And Why Your Video-Heavy WordPress Site Probably Needs It

Let me start with a confession: for years, I treated video embeds like they were "free." Drop a YouTube iframe into a post, hit publish, move on. No big deal, right?

Wrong. Dead wrong.

The moment I actually opened DevTools on a client site with 15+ embedded YouTube videos on a single landing page, I understood why the Core Web Vitals report looked like a crime scene. Every single embed was silently loading its own player, its own scripts, its own tracking pixels — before the visitor had even scrolled past the hero section.

That frustration is the entire origin story of VidDefer – Deferred Video Embeds, a plugin I just shipped to the WordPress.org repository.

This isn't a "top 10 performance tips" article. It's the story of a real problem, why existing solutions didn't fully cut it, and how VidDefer approaches it differently — plus an honest breakdown of who actually needs this plugin (spoiler: not everyone does).

💡 Where the Idea Actually Came From

I didn't wake up one day and decide "I should build a video lazy-load plugin." It came from a pattern I kept noticing across client projects:

A course platform with a video per lesson page.
A real estate site with property walkthrough videos on every listing.
A recipe blog embedding a YouTube tutorial in nearly every post.
A SaaS marketing site with a demo video stacked on top of three testimonial videos, all on the homepage. Every single one of these sites had the same complaint: "Our PageSpeed score is terrible, and we don't know why — we already optimized images and enabled caching."

The answer was almost always hiding in plain sight: multiple video iframes loading simultaneously on page load, each one pulling in third-party JavaScript before a visitor had shown any intent to actually watch anything.

Existing lazy-load plugins handled images beautifully. Videos were treated like an afterthought — usually just "lazy load the iframe attribute" without actually deferring the heavy scripts behind it. That gap is where VidDefer was born.

🎯 Why This Plugin? What Problem Does It Actually Solve?

Here's the technical reality most WordPress users don't realize: a standard YouTube or Vimeo embed doesn't just load a video. It loads:

The full embedded player iframe
YouTube/Vimeo's own JavaScript player framework
Analytics and tracking scripts bundled by the provider
Preconnect and font requests tied to the player UI All of this fires immediately on page load, whether or not the visitor ever intends to press play. Multiply that by every video on the page, and you've got a serious Largest Contentful Paint (LCP) and Total Blocking Time (TBT) problem — even if your images and fonts are perfectly optimized.

VidDefer solves this with a simple idea: show a lightweight thumbnail placeholder first, and only load the real player when the visitor clicks it (or scrolls to it, if you enable that mode). The visitor sees a legitimate, good-looking video preview instantly. The heavy player only loads on genuine interaction.

The result: pages that used to ship hundreds of kilobytes of unused video-player JavaScript on load now ship a tiny thumbnail image instead — until the user actually asks for the video.

🎥 Built Specifically for Video-Heavy Sites — Not Every Site Needs This

I want to be upfront about something most plugin marketing pages avoid saying: if your site has one video, buried at the bottom of one blog post, you probably don't need VidDefer. The performance gain there is marginal.

This plugin earns its place specifically on:

Course and membership sites with a video embedded on every lesson page
Real estate and travel sites using video walkthroughs across dozens of listings
SaaS and agency landing pages stacking demo videos, testimonial videos, and explainer videos together
Media and review blogs that embed a YouTube video in nearly every article
Portfolio and creative sites showcasing multiple embedded reels or showcases per page If your site falls into "video-heavy" territory — meaning multiple embeds per page, or video embeds across a large percentage of your total pages — that's exactly where VidDefer is designed to shine. On a content-light, video-light site, a general-purpose performance plugin will likely already cover you. VidDefer isn't trying to replace that; it's solving a narrower, deeper problem for sites where video embeds are the actual bottleneck.

🔍 The Real-World Problem, In Numbers

Here's a rough breakdown of what a single unoptimized YouTube embed typically drags along with it on load, compared to a deferred thumbnail placeholder:

A standard embedded iframe pulls in the player framework, related scripts, and thumbnail assets that can easily add several hundred kilobytes and multiple third-party requests — before playback even starts.
A deferred placeholder, by contrast, is just a compressed thumbnail image and a small play-button overlay, with the actual plugin script itself weighing in at under 2KB gzipped. Now multiply that by five, ten, or fifteen embeds on a single page — which is completely normal for course platforms or video-heavy blogs — and you can see why Core Web Vitals scores collapse on these page types specifically, even when everything else on the site is well-optimized.

⚙️ Which Third-Party Scripts Does VidDefer Actually Defer?

This is the part developers usually want to know, so let's get specific. On visitor interaction (click or scroll trigger, depending on your settings), VidDefer defers and then loads:

Video Source	What Gets Deferred	What Loads Only on Interaction
YouTube	The full YouTube iframe player + its embedded scripts	Real YouTube iframe player, pulling thumbnails from YouTube's public thumbnail CDN
Vimeo	The full Vimeo iframe player + its embedded scripts	Real Vimeo iframe player, with thumbnail/title metadata fetched via Vimeo's public oEmbed API and cached locally via WordPress transients
Self-hosted video	The `<video>` element and its associated MP4/WebM/OGV source loading	The actual video file, only once the visitor triggers playback

A few implementation details worth calling out for fellow developers:

Vimeo thumbnail/title data is fetched via a secure server-to-server request and then cached using WordPress transients, so your site only contacts Vimeo once per video, not on every page load.
YouTube thumbnails are pulled straight from YouTube's public thumbnail CDN — no API key required, no quota limits to worry about.
The plugin intercepts embeds using PHP output buffering, so it works regardless of whether the video was added via Gutenberg, Elementor, Divi, WPBakery, or hand-coded HTML.

📊 Without VidDefer vs. With VidDefer

Aspect	Without VidDefer	With VidDefer
Initial page load	Every embedded video loads its full iframe + scripts immediately	Only a lightweight thumbnail image loads initially
Third-party requests on load	Multiple requests per video (player framework, tracking, fonts)	Zero third-party requests until visitor interacts
JavaScript weight	Grows with every additional embedded video	Plugin adds under 2KB gzipped, regardless of video count
LCP / TBT impact	Degrades significantly on video-heavy pages	Minimal impact — thumbnails are lightweight and render fast
Visitor experience	Player controls appear before intent to watch is shown	Clean thumbnail + play button, feels intentional and fast
GDPR / privacy exposure	Third-party cookies/scripts may load before consent	No third-party connection made until visitor clicks play
Accessibility	Depends entirely on the embed provider's markup	WCAG 2.1 keyboard-accessible placeholders built in
Page builder compatibility	N/A	Works with Gutenberg, Elementor, Divi, and WPBakery via output buffering

🥊 Competitors vs. VidDefer

There are a handful of established performance plugins that touch video lazy loading as a side feature. Here's an honest, non-exaggerated comparison of where VidDefer differs:

General-purpose performance/caching plugins (the big all-in-one optimization suites): most of these treat video lazy loading as one small checkbox buried inside a much larger feature set focused on caching, minification, and image optimization. It works, but it's rarely built with video-specific controls like thumbnail quality, play-button styling, or per-video exclusion classes.
Dedicated "lazy load for videos" plugins: a few of these exist, but many are YouTube-only, require an API key, or haven't been updated in a while. Vimeo and self-hosted video support is often missing entirely.
Manually coding it yourself: totally possible if you're comfortable writing custom output-buffering logic and thumbnail-fetching code for three different video sources — but that's a real time investment for something that should be a five-minute plugin activation. VidDefer's niche is being video-first and multi-source from day one: YouTube, Vimeo, and self-hosted videos, all handled the same way, with zero configuration required to get the core benefit, and deeper customization available for anyone who wants it (thumbnail quality, play button style, colors, exclusions, GDPR overlay).

To be fair to the alternatives: if you only need basic image lazy loading and video is a minor part of your site, an all-in-one performance plugin is still a perfectly reasonable choice. VidDefer is for when video is the primary performance bottleneck, not a footnote.

➕ A Few Additional Things Worth Knowing

No API key required — YouTube thumbnails come from the public CDN, Vimeo data comes from the public oEmbed endpoint. Nothing to configure, nothing to break when a key expires.
Exclusion support — Add a no-lazy class to any video, iframe, or wrapping element to skip it entirely, useful for popups and lightboxes that need immediate access to the player.
YouTube Shorts are handled automatically, since they use the same embed format as standard YouTube videos.
Three play button styles and custom colors mean the placeholder doesn't have to look like an obvious plugin bolt-on — it can match your site's branding.
Built-in GDPR/privacy notice overlay is a nice side effect of the deferred-loading architecture: since no third-party connection happens until the click, you get a natural checkpoint to show a consent notice first.

🚀 Try It, Break It, Tell Me About It

If your site has more than a couple of embedded videos per page — especially across course content, listings, or media-heavy posts — I'd genuinely love for you to try VidDefer – Deferred Video Embeds and see what it does to your Core Web Vitals numbers.

It's version 1.0.0, freshly published, so bug reports and feature requests through the support forum are extremely welcome. If you've solved this problem a different way on your own sites, I'd love to hear that too — drop a comment below.

The Abilities API: Teaching Your Site to Say 'Here's What I Can Do'

Kushang Tailor — Mon, 06 Jul 2026 11:48:27 +0000

"The power of WordPress has always lived in its thousands of functions, scattered across core, plugins, and themes — undiscoverable to anything except a developer willing to read the source." — that's roughly the problem the WordPress AI Team set out to fix, and the Abilities API is their answer.

If you've built anything non-trivial on WordPress, you already know the pattern: you need a piece of functionality, so you write a function, hook it somewhere, maybe wrap it in a REST route if something external needs to reach it, then write the validation by hand, then the permission check, then the docs nobody reads. Repeat for every plugin, every site, every developer who comes after you.

WordPress 6.9 ships a new core API that quietly rewires that whole pattern. It's called the Abilities API, and it's the first of four "AI Building Blocks" the WordPress AI Team is rolling into core. But don't let the "AI" framing make you think this is some bolt-on chatbot feature — what it actually gives you is a standardized, typed, permissioned, discoverable way to expose any unit of functionality, whether the consumer is an admin dashboard, a REST client, a WP-CLI command, or yes, an AI agent.

Let's unpack it properly, then build some things with it.

🤔 So What Exactly Is an "Ability"?

Strip away the AI marketing for a second. An Ability is just a self-contained, named unit of functionality with four parts:

A unique name — namespace/ability-name, where the namespace is usually your plugin slug
A schema — what input it expects, what output it returns, both described in JSON Schema
A permission check — who (or what) is allowed to run it
An execution callback — the actual PHP logic

That's it. Once registered, this single definition is simultaneously usable from PHP directly, from WP-CLI, over the REST API, and — because the shape maps cleanly onto the Model Context Protocol (MCP) — from any AI agent that knows how to read a tool registry.

Compare that to how we've always done it: a custom function, a separate register_rest_route() call with its own validation logic, a manual current_user_can() check buried somewhere in the callback, and zero discoverability unless someone reads your code or your (probably outdated) documentation. The Abilities API collapses all of that glue code into one declarative registration.

🧩 Why This Is Landing Now

This isn't a random feature drop. It's the foundation piece of WordPress's broader push to make itself legible to AI systems — the same instinct that's been driving MCP adoption across the dev tooling world. The official Abilities API GitHub repository frames it plainly: a unified registry that's both human-readable and machine-readable, so capabilities are discoverable by developers and by automation tools across different platforms, AI agents included.

Once an ability is registered with show_in_rest enabled, it's automatically reachable at /wp-json/wp-abilities/v1/{namespace}/{ability}. Pair that with the WordPress MCP Adapter plugin, and an AI agent can ask your site "what can you do?" and get back a structured, typed answer instead of a guess. That's a genuinely different posture for WordPress — moving from "AI tools reverse-engineer your REST routes" to "your site publishes its own capability menu."

And the practical upside isn't AI-exclusive at all. Every ability you register also gives you, for free: automatic input/output validation, a colocated permission check, a REST endpoint with the correct HTTP verb already chosen for you, and a single place future-you (or the next developer on the project) can look to understand what a plugin actually does.

🏗️ The Core Building Blocks

Before writing code, it helps to know the vocabulary, since the API leans on five primitives:

Primitive	What it is
Ability	A `WP_Ability` instance — the unit of functionality itself
Category	A grouping bucket abilities are filed under, must be registered first
Registry	The central store; you rarely touch it directly
Schema	JSON Schema for input and output validation
Permission callback	Returns `true`, `false`, or a `WP_Error` — required, no defaults

Two hooks matter most: wp_abilities_api_categories_init (register your categories here, it fires first) and wp_abilities_api_init (register your abilities here, the Abilities API's answer to rest_api_init). Get the order backwards and your abilities silently fail to register — there's no fatal error, they just won't show up.

🛠️ Registering Your First Ability — The Right Way

Let's build something real instead of a toy example. Here's a small, OOP, PHPCS-friendly plugin structure that registers an ability returning a sanitized snapshot of site health data — the kind of thing a monitoring dashboard or an AI agent might genuinely want to query.

File structure first, because structure matters as much as the code:

site-pulse/
├── site-pulse.php
├── includes/
│   ├── class-site-pulse-bootstrap.php
│   └── abilities/
│       └── class-site-pulse-health-ability.php
└── assets/
    └── scss/
        └── admin.scss

site-pulse.php — the entry point, guarded against older WordPress versions:

<?php
/**
 * Plugin Name: Site Pulse
 * Description: Exposes a read-only site health Ability for dashboards and AI agents.
 * Version:     1.0.0
 * Author:      Your Name
 * Text Domain: site-pulse
 *
 * @package SitePulse
 */

defined( 'ABSPATH' ) || exit;

if ( ! class_exists( 'WP_Ability' ) ) {
    add_action(
        'admin_notices',
        static function () {
            wp_admin_notice(
                esc_html__( 'Site Pulse requires WordPress 6.9 or later (Abilities API).', 'site-pulse' ),
                array( 'type' => 'error' )
            );
        }
    );
    return;
}

require_once __DIR__ . '/includes/class-site-pulse-bootstrap.php';

Site_Pulse_Bootstrap::get_instance()->init();

includes/class-site-pulse-bootstrap.php — a singleton that owns the registration hooks, keeping things pure OOP rather than loose functions:

<?php
/**
 * Plugin bootstrap.
 *
 * @package SitePulse
 */

defined( 'ABSPATH' ) || exit;

/**
 * Class Site_Pulse_Bootstrap
 */
final class Site_Pulse_Bootstrap {

    /**
     * Singleton instance.
     *
     * @var Site_Pulse_Bootstrap|null
     */
    private static ?Site_Pulse_Bootstrap $instance = null;

    /**
     * Get singleton instance.
     *
     * @return Site_Pulse_Bootstrap
     */
    public static function get_instance(): Site_Pulse_Bootstrap {
        if ( null === self::$instance ) {
            self::$instance = new self();
        }

        return self::$instance;
    }

    /**
     * Hook everything up.
     */
    public function init(): void {
        add_action( 'wp_abilities_api_categories_init', array( $this, 'register_categories' ) );
        add_action( 'wp_abilities_api_init', array( $this, 'register_abilities' ) );
    }

    /**
     * Register the ability category.
     */
    public function register_categories(): void {
        wp_register_ability_category(
            'site-pulse-monitoring',
            array(
                'label'       => __( 'Site Monitoring', 'site-pulse' ),
                'description' => __( 'Read-only diagnostic abilities for this site.', 'site-pulse' ),
            )
        );
    }

    /**
     * Register the abilities.
     */
    public function register_abilities(): void {
        require_once __DIR__ . '/abilities/class-site-pulse-health-ability.php';
        Site_Pulse_Health_Ability::register();
    }
}

includes/abilities/class-site-pulse-health-ability.php — the ability definition itself, with validation, sanitization, and escaping treated as non-negotiable:

<?php
/**
 * Site health Ability.
 *
 * @package SitePulse
 */

defined( 'ABSPATH' ) || exit;

/**
 * Class Site_Pulse_Health_Ability
 */
final class Site_Pulse_Health_Ability {

    /**
     * Register this ability with the Abilities API registry.
     */
    public static function register(): void {
        wp_register_ability(
            'site-pulse/get-health-snapshot',
            array(
                'label'               => __( 'Get Site Health Snapshot', 'site-pulse' ),
                'description'         => __( 'Returns sanitized counts of posts, plugins, and PHP/WordPress versions. Read-only, no side effects.', 'site-pulse' ),
                'category'            => 'site-pulse-monitoring',
                'output_schema'       => array(
                    'type'       => 'object',
                    'properties' => array(
                        'published_posts' => array( 'type' => 'integer' ),
                        'active_plugins'  => array( 'type' => 'integer' ),
                        'wp_version'      => array( 'type' => 'string' ),
                        'php_version'     => array( 'type' => 'string' ),
                    ),
                ),
                'execute_callback'    => array( __CLASS__, 'execute' ),
                'permission_callback' => static fn() => current_user_can( 'manage_options' ),
                'meta'                => array(
                    'show_in_rest' => true,
                    'annotations'  => array(
                        'readonly'    => true,
                        'destructive' => false,
                        'idempotent'  => true,
                    ),
                ),
            )
        );
    }

    /**
     * Execute callback — builds and sanitizes the snapshot.
     *
     * @return array<string, mixed>
     */
    public static function execute(): array {
        $counts = wp_count_posts( 'post' );

        return array(
            'published_posts' => absint( $counts->publish ?? 0 ),
            'active_plugins'  => count( (array) get_option( 'active_plugins', array() ) ),
            'wp_version'      => sanitize_text_field( get_bloginfo( 'version' ) ),
            'php_version'     => sanitize_text_field( PHP_VERSION ),
        );
    }
}

Notice what's happening here beyond the registration boilerplate: absint() and sanitize_text_field() are doing real work on every value before it leaves the callback, the permission callback checks a specific capability rather than a vague "is logged in" check, and the annotations honestly declare this ability as readonly so the REST layer routes it to GET instead of POST. Lying about annotations doesn't just mis-route HTTP verbs — it tells AI planners an operation is safe when it isn't, or unsafe when it's perfectly harmless.

Calling it is now trivial from anywhere in PHP:

$ability = wp_get_ability( 'site-pulse/get-health-snapshot' );

if ( $ability ) {
    $snapshot = $ability->execute();

    if ( ! is_wp_error( $snapshot ) ) {
        // $snapshot is your validated, sanitized array.
    }
}

That is_wp_error() check isn't optional — WP_Error is truthy in PHP, so a lazy if ( $result ) will happily treat a failed execution as a success. It's a small gotcha that'll bite you exactly once before you remember it forever.

💡 Real-World Plugin & Theme Ideas Worth Building

Here's where it gets genuinely fun. The Abilities API isn't just a cleaner way to write what you already write — it opens doors to functionality that was previously too much glue code to justify. A few ideas worth exploring, ranging from "build this weekend" to "this could be a product":

An accessibility audit ability. Register theme-slug/audit-accessibility that scans the current page's rendered blocks for missing alt text, low-contrast color combinations from your theme.json palette, and heading-order violations, returning a structured report. An AI agent — or your own admin dashboard widget — can call it on every save and flag problems before publish.

A form-to-anything webhook bridge. Instead of hardcoding a Zapier-style integration into your form plugin, expose forms/dispatch-submission as an ability with a destructive: false, idempotent: false annotation. Any MCP-aware automation tool can now trigger it directly, and you've built one integration point instead of fifteen one-off ones for Slack, CRM, email, and whatever your client asks for next quarter.

A content-brief generator for editorial teams. Register an ability that takes a topic and target keyword, pulls related internal posts via WP_Query, and returns a structured outline scaffold (headings, suggested internal links, estimated word count). Editors trigger it from a custom block; an AI writing assistant can call the exact same ability with the exact same guarantees.

A WooCommerce-style order lookup ability for support tooling. Something like shop/get-order-summary, gated behind a manage_woocommerce-equivalent capability, returning sanitized order status, fulfillment stage, and customer-safe details — perfect for an internal support chatbot that needs to answer "where's my order" without anyone hand-rolling a bespoke REST route and praying the auth is airtight.

A multilingual content-sync checker. If you're running WPML or Polylang, an ability that compares a post against its translations and flags stale or missing language versions turns a manual QA chore into something a scheduled agent — or a WP-CLI cron — can run unattended.

A headless "what can this site do" discovery endpoint for client handoff. If you build sites for clients who later bring in their own developers, registering a clean set of abilities for your custom post types and meta fields means the next dev (human or AI-assisted) can discover your site's custom functionality without spelunking through your codebase first.

The common thread: anywhere you'd normally write a custom REST route, an AJAX handler, or a WP-CLI command and worry separately about validation and permissions, an ability gives you all three in one declarative block.

🔐 The Security Checklist That Actually Matters Here

The Abilities API gives you structure, but it doesn't give you security by default — that part is still on you, every time:

Validate first, trust nothing. Input schemas run before your permission callback, which is good, but a schema only checks shape, not business logic. Add your own bounds checking inside the callback.
Sanitize on the way in, escape on the way out. Just because input passed JSON Schema validation doesn't mean it's safe to drop into a database query or render unescaped. Treat ability input exactly like REST input, because functionally, it is.
Scope permission callbacks tightly. Reach for the narrowest WordPress capability that fits, not is_user_logged_in() as a catch-all. A destructive ability gated behind a weak permission check is a vulnerability with a discoverable REST endpoint attached.
Be honest with annotations. readonly, destructive, and idempotent aren't cosmetic — they determine the HTTP verb your endpoint accepts and what automated tools assume is safe to retry.
Never leak secrets through output schemas. The output schema is effectively a public contract once show_in_rest is true. Treat it the same way you'd treat a public API response.

🌐 Where This Goes Next

WordPress 6.9 ships the server-side foundation: registration, the registry, REST exposure. A JavaScript client for browser-side abilities is already developing in parallel via the Gutenberg packages, aimed at things like AI agents driving the block editor itself — selecting blocks, navigating the admin, executing client-side actions the same way server abilities execute PHP. That's expected to mature further as later releases build on this 6.9 foundation.

The bigger shift, though, isn't really technical — it's architectural. WordPress has spent two decades as an ecosystem of brilliant, scattered functionality held together by conventions and tribal knowledge. The Abilities API is the first serious core-level attempt to make that functionality legible — to humans skimming a registry, to automation tools composing workflows, and yes, to AI agents trying to understand what a site can actually do before they touch it.

If you're building plugins or themes today, this is a good moment to start thinking in abilities even before you have an AI use case in mind. The validation, permission, and discoverability benefits pay for themselves regardless of who — or what — ends up calling your code.

Have you registered your first Ability yet, or found a use case I didn't cover here? I'd love to hear what you're building with it — drop a comment below. 👇

Monitoring Tools for React Apps — Which One Do You Actually Need?

Kushang Tailor — Sat, 27 Jun 2026 16:32:55 +0000

Read Time: ~14 minutes | A practical guide to the tools that tell you your app is on fire — before your users do

This article is a bonus companion to the React Mastery Series. You don't need to have read the series — it stands on its own.

📌 What You'll Learn

✅ The three categories of monitoring (and why all three matter)
✅ Honest comparison of 7 popular monitoring tools
✅ Full Sentry + Vercel Analytics setup walkthrough
✅ LogRocket, Datadog, New Relic, Bugsnag, and FullStory — when each makes sense
✅ Stack recommendations by team size
✅ A decision framework that actually helps you choose

🔥 The Problem with Shipping Blind

Here's a scenario that's more common than anyone admits.

You ship a new feature on Friday afternoon. Users start hitting it. Somewhere in that flow — a race condition, a missing null check, a third-party API returning an unexpected shape — something breaks. Users see a white screen. Or worse, a silent failure where data just stops saving.

You find out Monday morning. From an email. Sent by your most patient user.

That's what shipping without monitoring looks like. The good news: it's a solved problem. The honest news: there are seven popular tools that claim to solve it, and picking the wrong one wastes setup time and money.

This article cuts through the noise.

🏗️ The Three Categories of Monitoring

Before comparing tools, it's worth understanding that "monitoring" isn't one thing. It covers three distinct problems:

1. Error Monitoring

The question it answers: What broke, where exactly, and for whom?

When a user hits an unhandled exception, an API call crashes, or a component throws during render — error monitoring captures the full context: stack trace, browser, OS, user identity, and the sequence of events that led to the crash.

Without this, you're debugging from a vague user description. With it, you open a dashboard and see the exact file, line, and call stack.

2. Performance Monitoring

The question it answers: How fast is my app, and where is it slow?

This tracks real user experience — how long pages take to load, how quickly API routes respond, and how your Core Web Vitals (LCP, FID, CLS) look across different devices and regions.

A component that renders in 80ms on your MacBook Pro can take 400ms on a mid-range Android device in India. Performance monitoring shows you the real picture, not the one you see on your dev machine.

3. Session Replay

The question it answers: What was the user actually doing when things went wrong?

This records a video-like reconstruction of the user's session — every click, scroll, input, and network request — leading up to the moment something broke. Instead of reproducing a bug through guesswork, you watch it happen.

🛠️ The 7 Tools — Deep Dive

1. Sentry

Category: Error + Performance + Session Replay
Best for: Most React and Next.js apps
Free tier: 5,000 errors/month — generous enough for many side projects

Sentry is the default choice for good reason. One SDK covers all three monitoring categories, the Next.js integration is first-class, and the setup is handled mostly by a wizard in a single command.

What makes it stand out: The concept of breadcrumbs. Before an error lands in your Sentry dashboard, you see the full sequence of what happened — which API calls fired, which buttons the user clicked, which console messages appeared. It's like having a black box recorder in your app.

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

This generates three config files automatically. Your .env.local needs one variable:

NEXT_PUBLIC_SENTRY_DSN=https://your-key@sentry.io/project-id

Capturing context with errors:

import * as Sentry from '@sentry/nextjs';

// Add user context once — all future errors are attributed to this user
Sentry.setUser({ id: user.id, email: user.email });

// Capture exceptions with tags for filtering
try {
  await processOrder(orderId);
} catch (error) {
  Sentry.captureException(error, {
    tags: { module: 'checkout', action: 'processOrder' },
    extra: { orderId },
  });
  throw error; // Always re-throw — don't swallow errors silently
}

Session Replay config (from sentry.client.config.ts):

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1,           // Sample 10% of requests for performance
  replaysSessionSampleRate: 0.05,  // Record 5% of all sessions
  replaysOnErrorSampleRate: 1.0,   // Always record when an error occurs
  integrations: [Sentry.replayIntegration()],
});

The replaysOnErrorSampleRate: 1.0 line is the most valuable one. Every single error comes with a replay. You watch the bug happen, you fix it, you close the ticket.

Verdict: Start here. It's not glamorous advice, but it's the right one.

2. Vercel Analytics

Category: Performance Monitoring
Best for: Any app deployed on Vercel
Free tier: ✅ Completely free on hobby plans

If you deploy on Vercel, this is the easiest performance win you'll ever get. No SDK to install, no configuration file, no API key. Enable it in the Vercel dashboard and it starts tracking Core Web Vitals for real users immediately.

npm install @vercel/analytics

// app/layout.tsx — that's literally the entire setup
import { Analytics } from '@vercel/analytics/react';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Analytics />
      </body>
    </html>
  );
}

What you get:

Real user LCP, FID, and CLS scores per page
Breakdown by country, device type, and browser
Score over time (did your last deploy make things faster or slower?)
No sampling — every page view is counted

What you don't get: Error monitoring, session replay, or backend performance data. It's a performance-only tool.

Verdict: Add this in 5 minutes if you're on Vercel. It pairs perfectly with Sentry.

3. LogRocket

Category: Session Replay (primary) + Error Monitoring
Best for: Teams who want the deepest possible understanding of user behaviour
Free tier: 1,000 sessions/month

LogRocket is what you reach for when Sentry's session replay isn't quite enough context. Where Sentry replays the visual session, LogRocket records everything:

Every Redux/Zustand action dispatched
Every network request and response (with payloads)
Every console log, warning, and error
Every DOM mutation
Mouse movements, rage clicks, and dead clicks

The replay experience in LogRocket is closer to watching a movie than a wireframe reconstruction. You see pixel-perfect what the user saw.

npm install logrocket logrocket-react

// app/providers.tsx
'use client';
import LogRocket from 'logrocket';
import setupLogRocketReact from 'logrocket-react';
import { useEffect } from 'react';

export function LogRocketProvider({ children }: { children: React.ReactNode }) {
  useEffect(() => {
    LogRocket.init('your-app-id/project-name');
    setupLogRocketReact(LogRocket);
  }, []);

  return <>{children}</>;
}

// Identify users after login
LogRocket.identify(user.id, {
  name: user.name,
  email: user.email,
  plan: user.subscriptionTier,
});

Where LogRocket earns its keep: You have a bug that users report but you can't reproduce. You pull up their specific session in LogRocket and watch exactly what they did, what the API returned, and what state looked like when it broke. The reproduction step disappears entirely.

Where it's overkill: Small teams, early-stage apps, internal tools. The free tier is limited and the paid plans can add up.

Verdict: Use it when Sentry replay gives you the what but you still need the why.

4. Datadog

Category: Error + Performance + Infrastructure + Logs
Best for: Larger teams, microservices, or when you need one dashboard for everything
Free tier: ❌ No meaningful free tier — starts at ~$15/host/month

Datadog is where monitoring goes when your app grows into infrastructure. It's not primarily a React tool — it monitors servers, databases, containers, queues, and services alongside your frontend. When a slow API route is caused by a slow database query on an overloaded server, Datadog connects all of those dots in one place.

// Instrumenting custom metrics from Next.js API routes
import tracer from 'dd-trace';
tracer.init({ service: 'my-nextjs-app', env: process.env.NODE_ENV });

// app/api/orders/route.ts
export async function POST(request: NextRequest) {
  const span = tracer.startSpan('create.order');

  try {
    const order = await db.orders.create({ data: await request.json() });
    span.finish();
    return NextResponse.json(order, { status: 201 });
  } catch (error) {
    span.setTag('error', true);
    span.finish();
    throw error;
  }
}

The real power is distributed tracing — a single user action that touches three microservices shows up as one connected trace, so you can see which service introduced the latency.

Where Datadog earns its place: You have a dedicated DevOps or platform team. You're running on Kubernetes. You need compliance-grade log retention. Your on-call rotation needs a single pane of glass.

Where it's wrong: Solo developers, early-stage products, anything on Vercel that Vercel Analytics already covers. The learning curve and cost are both real.

Verdict: Right tool, wrong time — until your infrastructure complexity demands it.

5. New Relic

Category: Performance + Error + Infrastructure
Best for: Full-stack performance monitoring across backend and frontend
Free tier: ✅ 100GB/month data ingest — surprisingly generous

New Relic sits between Sentry and Datadog in the complexity spectrum. It does frontend error monitoring, backend performance tracing, and infrastructure monitoring — but with a gentler learning curve than Datadog and a real free tier.

npm install newrelic @newrelic/next

// next.config.js
const withNewRelic = require('@newrelic/next');

module.exports = withNewRelic({
  // your existing Next.js config
});

New Relic's strongest feature is browser agent performance monitoring — it captures real user timing data (not just Lighthouse scores) and shows you where time is actually spent: DNS lookup, connection, first byte, DOM processing, and so on. For apps with complex rendering pipelines, that level of detail is invaluable.

Verdict: Worth evaluating if you need backend performance tracing but find Datadog's pricing hard to justify. The free tier is real and usable.

6. Bugsnag

Category: Error Monitoring
Best for: Teams who want Sentry's core feature set with a simpler interface
Free tier: 7,500 errors/month

Bugsnag does one thing and does it well: error monitoring. No session replay, no performance dashboards, no infrastructure metrics. Just clean, well-organised error tracking with good grouping, filtering, and alerting.

npm install @bugsnag/js @bugsnag/plugin-react

// app/providers.tsx
'use client';
import Bugsnag from '@bugsnag/js';
import BugsnagPluginReact from '@bugsnag/plugin-react';
import { useEffect } from 'react';

Bugsnag.start({
  apiKey: process.env.NEXT_PUBLIC_BUGSNAG_API_KEY!,
  plugins: [new BugsnagPluginReact()],
});

const ErrorBoundary = Bugsnag.getPlugin('react')!.createErrorBoundary(React);

export function BugsnagProvider({ children }: { children: React.ReactNode }) {
  return <ErrorBoundary>{children}</ErrorBoundary>;
}

Where Bugsnag wins: Some developers genuinely find Sentry's dashboard overwhelming — too many features, too many options. Bugsnag is focused and clean. If your team's goal is simply "know when errors happen and who's affected", Bugsnag delivers that without distraction.

Verdict: A genuine Sentry alternative — pick whichever dashboard your team actually opens.

7. FullStory

Category: Session Replay + UX Analytics
Best for: Product and UX teams at scale
Free tier: ❌ Paid only (free trial available)

FullStory is the enterprise session replay tool. Where LogRocket focuses on the developer experience (stack traces, network calls, console logs), FullStory focuses on the product experience — funnel analysis, rage click heatmaps, frustration signals, and quantitative UX insights.

It answers questions like: "What percentage of users who reach step 3 of our checkout abandon it, and what are they doing right before they leave?" That's a product analytics question, not a debugging question. FullStory is built for it.

For most development teams, it's outside the scope of what monitoring means. But for product-focused companies where user behaviour data directly drives roadmap decisions, it's the right tool.

Verdict: Powerful, but it's a product analytics tool more than a developer monitoring tool. Worth knowing about — not where you start.

📊 Side-by-Side Comparison

Tool	Errors	Performance	Session Replay	Free Tier	Best Starting Point
Sentry	✅	✅	✅	✅ Generous	Solo to mid-size teams
Vercel Analytics	❌	✅	❌	✅ Free	Any Vercel deployment
LogRocket	✅	✅	✅ Deep	✅ Limited	Teams debugging UX issues
Datadog	✅	✅	❌	❌ Paid	Multi-service / enterprise
New Relic	✅	✅	❌	✅ 100GB	Full-stack perf focus
Bugsnag	✅	❌	❌	✅ 7.5k errors	Teams wanting simplicity
FullStory	❌	❌	✅ Deep	❌ Trial	Product/UX teams at scale

🗺️ The Decision Framework

Stop reading comparison tables and ask yourself two questions:

Question 1: What's your app's biggest risk right now?

"I need to know when errors happen"
└─→ Sentry or Bugsnag

"I need to know if my app is slow for real users"
└─→ Vercel Analytics + Sentry Performance

"I need to watch what users do when things break"
└─→ Sentry (Session Replay) or LogRocket

"I need to monitor servers, queues, and services together"
└─→ Datadog or New Relic

Question 2: What's your team size?

Solo developer or side project
└─→ Sentry free tier + Vercel Analytics. Done.

Small team (2–10 engineers)
└─→ Sentry + Vercel Analytics. Add LogRocket if UX debugging is painful.

Mid-size team (10–50 engineers)
└─→ Sentry + Vercel Analytics + LogRocket or New Relic depending on backend complexity.

Large team / enterprise
└─→ Datadog (or Datadog + Sentry). Add FullStory if product analytics is a priority.

🏆 Recommended Stacks by Scenario

The Indie Developer / Side Project Stack

Sentry (free tier) — errors, perf, session replay
Vercel Analytics (free) — Core Web Vitals

Total cost: $0
Setup time: ~30 minutes
Coverage: everything you actually need at this stage

The Early-Stage Startup Stack

Sentry Team plan — error monitoring + performance + replay
Vercel Analytics — real user page speed
LogRocket Startup plan — deep session replay for support and UX

Total cost: ~$100–200/month depending on traffic
Setup time: ~2 hours
Coverage: full observability stack

The Scaled Production Stack

Datadog — infrastructure, APM, logs, dashboards, alerting
Sentry — error monitoring (Datadog's error experience isn't as polished)
FullStory — user behaviour analytics for product team

Total cost: varies by scale
Setup time: 1–2 days for full integration
Coverage: enterprise-grade observability

⚡ The 30-Minute Setup (Sentry + Vercel Analytics)

If you want to go from zero monitoring to production-ready coverage right now, here's exactly what to do.

Step 1 — Sentry setup (15 minutes)

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

Add your DSN to .env.local:

NEXT_PUBLIC_SENTRY_DSN=your-dsn-from-sentry-dashboard

Update sentry.client.config.ts to enable replay:

import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.05,
  replaysOnErrorSampleRate: 1.0,
  integrations: [Sentry.replayIntegration()],
});

Step 2 — Identify users after login (5 minutes)

// Call this once after successful authentication
import * as Sentry from '@sentry/nextjs';

function onAuthSuccess(user: User) {
  Sentry.setUser({
    id: user.id,
    email: user.email,
  });
}

Step 3 — Vercel Analytics (5 minutes)

npm install @vercel/analytics

// app/layout.tsx
import { Analytics } from '@vercel/analytics/react';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Analytics />
      </body>
    </html>
  );
}

Enable it in the Vercel dashboard: Project → Analytics → Enable.

Step 4 — Set up one alert (5 minutes)

In Sentry: Alerts → Create Alert → Issue Alert → "First seen" trigger → send to your email or Slack. Now you get notified the moment a new error type appears in production.

That's it. You're monitored.

💡 Final Thoughts: Start Simple, Evolve With Your App

The most common monitoring mistake isn't choosing the wrong tool — it's not having any monitoring at all because the choice felt overwhelming.

Pick Sentry. Add Vercel Analytics. Configure one alert. You now know more about what's happening in your production app than 60% of teams shipping React today.

When your scale demands more, you'll know — because Sentry will show you exactly where your current setup is falling short.

Observability isn't a destination. It's a habit you build incrementally.

🔗 Quick Links

Sentry: sentry.io — Start here
Vercel Analytics: vercel.com/analytics — Free with Vercel
LogRocket: logrocket.com — Deep session replay
Datadog: datadoghq.com — Enterprise observability
New Relic: newrelic.com — Full-stack performance
Bugsnag: bugsnag.com — Simple error tracking
FullStory: fullstory.com — UX analytics

💬 What's Your Stack?

Which monitoring tool does your team use in production — and is there one that surprised you with how good (or painful) it was? Drop it in the comments. Real team experiences are always more useful than comparison tables.

This article is a bonus companion to the React Mastery Series — a complete six-part guide from React fundamentals to production engineering. Read the full series here.

React in Production — Ship It, Monitor It, Sleep at Night

Kushang Tailor — Tue, 23 Jun 2026 04:06:58 +0000

Read Time: ~15 minutes | The gap between "it works on my machine" and "it works for everyone, always"

Prerequisites: The full React Mastery Series — Parts 1–5

Part 6: The Finale 🎉

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Implement authentication with JWT and session cookies
✅ Add OAuth (Google / GitHub login) in minutes
✅ Set up CI/CD with GitHub Actions to automate your deployments
✅ Catch and monitor errors in production with Sentry
✅ Protect routes and handle auth state globally
✅ Avoid the most common production mistakes React developers make
✅ Understand what "production-ready" actually means in practice

🏁 You Made It Here — Now What?

Five articles in, you can build fast, well-structured, testable React apps. You know your hooks, your state patterns, your performance levers, and your Next.js data flows.

What you haven't done yet is ship something real, break it, watch it burn, and fix it gracefully — that's what production is.

This final part covers the things that separate a side project from a product people actually rely on: authentication that doesn't embarrass you, a CI/CD pipeline that ships your code automatically, and error monitoring that tells you something broke before your users do.

🔐 Authentication: JWT vs Session Cookies

Authentication is one of those topics where developers either overcomplicate it or cut too many corners. Let's get the fundamentals right first.

The Two Main Approaches

JWT (JSON Web Token)
└─ Token stored on client (localStorage or cookie)
└─ Server is stateless — doesn't store sessions
└─ Fast to verify (no DB lookup per request)
└─ Hard to invalidate before expiry (logout is tricky)

Session Cookies
└─ Session ID stored in an httpOnly cookie
└─ Session data lives on the server (DB or cache)
└─ Easy to invalidate (delete the session record)
└─ Requires DB lookup on every authenticated request

Recommendation for most apps: session cookies with httpOnly — more secure by default, easier logout, slightly more setup.

JWT makes sense when: you have multiple services that need to verify auth without sharing a database (microservices, third-party APIs).

Building JWT Auth in Next.js

Install dependencies:

npm install jsonwebtoken bcryptjs
npm install --save-dev @types/jsonwebtoken @types/bcryptjs

Step 1 — User login API route:

// app/api/auth/login/route.ts
import { NextRequest, NextResponse } from 'next/server';
import jwt from 'jsonwebtoken';
import bcrypt from 'bcryptjs';

const JWT_SECRET = process.env.JWT_SECRET!;

export async function POST(request: NextRequest) {
  const { email, password } = await request.json();

  // 1. Find user in database
  const user = await db.users.findUnique({ where: { email } });

  if (!user) {
    return NextResponse.json({ error: 'Invalid credentials' }, { status: 401 });
  }

  // 2. Compare hashed password
  const isValid = await bcrypt.compare(password, user.passwordHash);

  if (!isValid) {
    return NextResponse.json({ error: 'Invalid credentials' }, { status: 401 });
  }

  // 3. Create token (expires in 7 days)
  const token = jwt.sign(
    { userId: user.id, email: user.email },
    JWT_SECRET,
    { expiresIn: '7d' }
  );

  // 4. Set token in httpOnly cookie (safer than localStorage)
  const response = NextResponse.json({ success: true });
  response.cookies.set('auth-token', token, {
    httpOnly: true,   // JS can't read this cookie
    secure: true,     // HTTPS only
    sameSite: 'lax',  // CSRF protection
    maxAge: 60 * 60 * 24 * 7, // 7 days in seconds
  });

  return response;
}

Step 2 — Verify token in middleware:

// middleware.ts (runs before every request)
import { NextRequest, NextResponse } from 'next/server';
import { jwtVerify } from 'jose'; // jose works in Edge runtime; jsonwebtoken doesn't

const JWT_SECRET = new TextEncoder().encode(process.env.JWT_SECRET!);

export async function middleware(request: NextRequest) {
  const token = request.cookies.get('auth-token')?.value;

  // Protect /dashboard and all routes under it
  if (request.nextUrl.pathname.startsWith('/dashboard')) {
    if (!token) {
      return NextResponse.redirect(new URL('/login', request.url));
    }

    try {
      await jwtVerify(token, JWT_SECRET);
      return NextResponse.next(); // Token valid — let the request through
    } catch {
      // Token invalid or expired
      const response = NextResponse.redirect(new URL('/login', request.url));
      response.cookies.delete('auth-token');
      return response;
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*'], // Only run middleware on these routes
};

Step 3 — Logout:

// app/api/auth/logout/route.ts
import { NextResponse } from 'next/server';

export async function POST() {
  const response = NextResponse.json({ success: true });
  response.cookies.delete('auth-token');
  return response;
}

🌐 OAuth: Google & GitHub Login in Minutes

OAuth is the "Sign in with Google" button your users already expect. In Next.js, NextAuth.js (Auth.js v5) handles the entire OAuth dance for you.

npm install next-auth@beta

Configure Auth.js:

// auth.ts (project root)
import NextAuth from 'next-auth';
import Google from 'next-auth/providers/google';
import GitHub from 'next-auth/providers/github';

export const { handlers, auth, signIn, signOut } = NextAuth({
  providers: [
    Google({
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    }),
    GitHub({
      clientId: process.env.GITHUB_CLIENT_ID!,
      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
    }),
  ],
  callbacks: {
    // Add custom data to the session
    session({ session, token }) {
      if (session.user && token.sub) {
        session.user.id = token.sub;
      }
      return session;
    },
  },
});

Mount the handler:

// app/api/auth/[...nextauth]/route.ts
import { handlers } from '@/auth';
export const { GET, POST } = handlers;

Protect a page with the session:

// app/dashboard/page.tsx
import { auth } from '@/auth';
import { redirect } from 'next/navigation';

export default async function DashboardPage() {
  const session = await auth();

  if (!session) {
    redirect('/login'); // Not signed in — send them away
  }

  return (
    <div>
      <h1>Welcome, {session.user?.name}</h1>
      <p>Logged in as {session.user?.email}</p>
    </div>
  );
}

Sign in / sign out buttons:

'use client';
import { signIn, signOut } from 'next-auth/react';

export function AuthButtons() {
  return (
    <div>
      <button onClick={() => signIn('google')}>Sign in with Google</button>
      <button onClick={() => signIn('github')}>Sign in with GitHub</button>
      <button onClick={() => signOut()}>Sign Out</button>
    </div>
  );
}

Add GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET, and NEXTAUTH_SECRET to your .env.local, and you have fully working social login.

🔄 CI/CD with GitHub Actions

Shipping manually is how bugs reach production. A CI/CD pipeline runs your tests, checks your build, and deploys automatically — every single time you push code.

What the Pipeline Does

Developer pushes code to GitHub
         ↓
GitHub Actions triggers automatically
         ↓
Install dependencies
         ↓
Run linter (ESLint)
         ↓
Run type checker (TypeScript)
         ↓
Run test suite (Jest)
         ↓
Build the app
         ↓
If all green → Deploy to Vercel ✅
If any red   → Block deploy, notify developer ❌

Full GitHub Actions Workflow

# .github/workflows/ci.yml

name: CI / CD Pipeline

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

jobs:
  quality:
    name: Lint, Type Check & Test
    runs-on: ubuntu-latest

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

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

      - name: Install dependencies
        run: npm ci

      - name: Run ESLint
        run: npm run lint

      - name: Run TypeScript check
        run: npx tsc --noEmit

      - name: Run tests
        run: npm test -- --coverage --watchAll=false
        env:
          CI: true

      - name: Build app
        run: npm run build
        env:
          NEXT_PUBLIC_API_URL: ${{ secrets.NEXT_PUBLIC_API_URL }}

  deploy:
    name: Deploy to Vercel
    needs: quality          # Only runs if the quality job passes
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' # Only deploy from main branch

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

      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

Add VERCEL_TOKEN, VERCEL_ORG_ID, and VERCEL_PROJECT_ID to your GitHub repository's Secrets (Settings → Secrets and variables → Actions). Get the token from Vercel's dashboard.

Now every pull request runs the full quality check. Only clean, tested, built code reaches production.

🚨 Error Monitoring with Sentry

Tests catch bugs before users see them. Sentry catches the ones that slip through anyway — and tells you exactly where, why, and how often.

Setup

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

The wizard creates sentry.client.config.ts, sentry.server.config.ts, and sentry.edge.config.ts automatically. You just need your DSN from the Sentry dashboard.

sentry.client.config.ts:

import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1,     // Capture 10% of transactions for performance
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0, // Always capture replay when there's an error
  environment: process.env.NODE_ENV,
});

Capturing Errors Manually

import * as Sentry from '@sentry/nextjs';

async function processPayment(orderId: string) {
  try {
    const result = await paymentGateway.charge(orderId);
    return result;
  } catch (error) {
    // Send to Sentry with context
    Sentry.captureException(error, {
      tags: { component: 'checkout', action: 'processPayment' },
      extra: { orderId },
    });
    throw error; // Re-throw — don't silently swallow it
  }
}

Setting User Context

After login, tell Sentry who the user is — errors become instantly attributable:

import * as Sentry from '@sentry/nextjs';

function onLoginSuccess(user: User) {
  Sentry.setUser({
    id: user.id,
    email: user.email,
    username: user.name,
  });
}

function onLogout() {
  Sentry.setUser(null); // Clear on logout
}

Now when an error hits Sentry, you see exactly which user experienced it, what they were doing, and the full stack trace — no guessing.

🗂️ Production Environment Variables

Your app has three environments, and each needs its own config:

# .env.local (development — never commit this)
DATABASE_URL=postgresql://localhost:5432/myapp_dev
NEXT_PUBLIC_API_URL=http://localhost:3000
JWT_SECRET=dev-secret-not-for-production

# Vercel → Project Settings → Environment Variables → Preview
DATABASE_URL=postgresql://host/myapp_staging
NEXT_PUBLIC_API_URL=https://staging.myapp.com
JWT_SECRET=staging-secret-32-chars-minimum

# Vercel → Project Settings → Environment Variables → Production
DATABASE_URL=postgresql://host/myapp_prod
NEXT_PUBLIC_API_URL=https://myapp.com
JWT_SECRET=prod-secret-64-chars-cryptographically-random

Rules to live by:

// ✅ NEXT_PUBLIC_ prefix = visible in the browser (safe for public URLs)
const apiUrl = process.env.NEXT_PUBLIC_API_URL;

// ✅ No prefix = server-only (safe for secrets, DB URLs, API keys)
const dbUrl = process.env.DATABASE_URL;

// ❌ Never put secrets in NEXT_PUBLIC_ variables
// ❌ Never commit .env.local to Git (add it to .gitignore)
// ❌ Never hardcode secrets — even "temporarily"

🧱 Production-Ready Checklist

Before you consider any app production-ready, run through this honestly:

Security

□ All auth routes protected by middleware
□ Passwords hashed with bcrypt (never stored plain)
□ httpOnly cookies used (not localStorage for tokens)
□ Environment variables never committed to Git
□ API routes validate and sanitize all input
□ Rate limiting on login and sensitive endpoints
□ HTTPS enforced (Vercel does this automatically)

Reliability

□ Error Boundaries wrap independent UI sections
□ Sentry (or equivalent) capturing all unhandled errors
□ API routes return meaningful error messages + HTTP codes
□ Loading and error states handled in every data component
□ CI pipeline blocks deploys when tests fail

Performance

□ Images use next/image (WebP, lazy loading, no CLS)
□ Fonts loaded via next/font (no layout shift)
□ Route-based code splitting in place
□ No console.log left in production code
□ Largest Contentful Paint (LCP) < 2.5s

Observability

□ Error monitoring active (Sentry)
□ Performance monitoring configured
□ Structured logging in API routes
□ Alerts set up for error spikes

💣 Production Mistakes Worth Learning From

These are real patterns that get real apps in trouble — most of them avoidable with about 20 minutes of setup.

Mistake 1: Storing tokens in localStorage

// ❌ XSS attack can steal this
localStorage.setItem('token', jwtToken);

// ✅ httpOnly cookie — JavaScript can't touch it
response.cookies.set('auth-token', token, { httpOnly: true, secure: true });

Mistake 2: Not validating API inputs

// ❌ Trusting anything the client sends
export async function POST(req: NextRequest) {
  const { email, role } = await req.json();
  await db.users.create({ data: { email, role } }); // 😱 user just gave themselves 'admin'
}

// ✅ Validate the shape and strip unexpected fields
export async function POST(req: NextRequest) {
  const body = await req.json();
  const email = String(body.email ?? '').trim();

  if (!email || !email.includes('@')) {
    return NextResponse.json({ error: 'Invalid email' }, { status: 400 });
  }

  await db.users.create({ data: { email, role: 'user' } }); // role is hardcoded
}

Mistake 3: Exposing server errors to clients

// ❌ Leaks your stack trace and internals
return NextResponse.json({ error: error.message }, { status: 500 });

// ✅ Log the real error server-side, send a generic message
console.error('[API Error]', error);
Sentry.captureException(error);
return NextResponse.json({ error: 'Something went wrong.' }, { status: 500 });

Mistake 4: No rate limiting on auth routes

// Install: npm install @upstash/ratelimit @upstash/redis
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '1 m'), // 5 attempts per minute
});

export async function POST(request: NextRequest) {
  const ip = request.ip ?? '127.0.0.1';
  const { success } = await ratelimit.limit(ip);

  if (!success) {
    return NextResponse.json({ error: 'Too many attempts.' }, { status: 429 });
  }

  // ... rest of login logic
}

Mistake 5: Forgetting to handle token expiry on the client

// ✅ Intercept 401 responses globally and redirect to login
export async function fetchWithAuth(url: string, options?: RequestInit) {
  const response = await fetch(url, options);

  if (response.status === 401) {
    // Token expired — send user back to login
    window.location.href = '/login';
    return;
  }

  return response;
}

🎓 The Full Journey — What You've Built Over This Series

You started with "What is React?" and you're finishing with production deployments, auth systems, and error monitoring. That's not a small leap. Here's everything you've learned across all six parts:

Part 1 — Foundations
   React, components, hooks, setup, file structure

Part 2 — Advanced Hooks & State
   Custom hooks, useReducer, Context, Redux, Zustand, Jotai

Part 3 — Performance
   React.memo, useMemo, useCallback, code splitting, virtualization

Part 4 — Full-Stack with Next.js
   App Router, Server Components, API routes, deployment

Part 5 — Testing & Debugging
   Jest, React Testing Library, async tests, Error Boundaries

Part 6 — Production
   Auth, OAuth, CI/CD, Sentry, security, production patterns

You now have the full picture. Not just "React developer" — full-stack, production-capable, test-covered React engineering.

🔗 Quick Resources

Auth.js (NextAuth v5): authjs.dev
Sentry for Next.js: docs.sentry.io/platforms/javascript/nextjs
GitHub Actions: docs.github.com/actions
Upstash Rate Limiting: upstash.com/docs/ratelimit
Vercel Environment Variables: vercel.com/docs/environment-variables

💬 You've Reached the End — What's Next for You?

Six articles. A complete React engineering curriculum. What are you building with it?

If you've followed this series from Part 1, I'd genuinely love to hear what you took away most — a concept that finally clicked, a project you shipped, or even something I got wrong. Drop it in the comments.

And if you're hungry for what comes after production React, the natural next steps are: React Native for mobile, Turborepo for monorepos, and tRPC for end-to-end type safety without REST boilerplate.

Go build something real. 🚀

Testing & Debugging React Apps — Write Code You Can Actually Trust

Kushang Tailor — Thu, 18 Jun 2026 04:26:01 +0000

Read Time: ~14 minutes | Ship with confidence — because guessing is not a strategy

Prerequisites: React fundamentals, hooks, state management, Next.js basics (Parts 1–4)

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Understand the three layers of testing and what each one covers
✅ Set up Jest and React Testing Library from scratch
✅ Write unit tests for components, hooks, and utility functions
✅ Write integration tests that test real user flows
✅ Test async behaviour — API calls, loading states, and errors
✅ Debug like a pro with React DevTools and browser tools
✅ Use Error Boundaries to catch crashes gracefully in production

🤔 Why Testing Feels Painful (And Why It Doesn't Have To)

Let's be real — most developers skip testing early on. Not because they don't care about quality, but because they were introduced to testing the wrong way: abstract theory, complicated setup, and tests that take longer to write than the code itself.

Here's the shift in mindset that makes it click:

You're not writing tests for the computer. You're writing tests for Future You.

Future You, at 2 AM, having just changed a utility function, needs to know if something broke without manually clicking through 40 screens. Tests are that safety net.

The other thing nobody tells you: you don't need to test everything. You test the things that would hurt if they broke.

🏗️ The Three Layers of Testing

Think of testing as a pyramid. Wide base, narrow top.

        /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
       /   E2E Tests (few) \     → Cypress, Playwright
      /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
     /  Integration Tests (some) \  → React Testing Library
    /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
   /    Unit Tests (many)         \  → Jest
  /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\

Layer	What It Tests	Speed	Confidence
Unit	One function or component in isolation	Fast (~ms)	Low–Medium
Integration	Multiple parts working together	Medium (~s)	High
E2E	Full app in a real browser	Slow (~min)	Highest

For most React projects, you want lots of unit tests, a solid set of integration tests, and a handful of E2E tests for critical flows like login and checkout. This article focuses on unit and integration — the layer that gives you the best return on time invested.

⚙️ Setup: Jest + React Testing Library

If you created your project with Create React App, Jest is already configured. For Vite or Next.js, here's the setup.

For Next.js

npm install --save-dev jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom @testing-library/user-event

Create jest.config.ts in your project root:

// jest.config.ts
import type { Config } from 'jest';
import nextJest from 'next/jest.js';

const createJestConfig = nextJest({ dir: './' });

const config: Config = {
  testEnvironment: 'jsdom',
  setupFilesAfterFramework: ['<rootDir>/jest.setup.ts'],
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/$1', // Resolve @ path aliases
  },
};

export default createJestConfig(config);

Create jest.setup.ts:

// jest.setup.ts
import '@testing-library/jest-dom';
// This gives you matchers like .toBeInTheDocument(), .toHaveTextContent() etc.

Add the test script to package.json:

{
  "scripts": {
    "test": "jest",
    "test:watch": "jest --watch",
    "test:coverage": "jest --coverage"
  }
}

Run your first test:

npm test

✅ Unit Testing: Components

The golden rule of React Testing Library: test what the user sees, not implementation details.

That means — test for text on screen, buttons, inputs, and form behaviour. Don't test state variables, component internals, or CSS class names.

Testing a Simple Component

// components/Greeting.tsx
interface Props {
  name: string;
  isLoggedIn: boolean;
}

export default function Greeting({ name, isLoggedIn }: Props) {
  if (!isLoggedIn) {
    return <p>Please log in to continue.</p>;
  }
  return <h1>Welcome back, {name}!</h1>;
}

// components/Greeting.test.tsx
import { render, screen } from '@testing-library/react';
import Greeting from './Greeting';

describe('Greeting', () => {
  it('shows a welcome message when the user is logged in', () => {
    render(<Greeting name="Kushang" isLoggedIn={true} />);

    expect(screen.getByText('Welcome back, Kushang!')).toBeInTheDocument();
  });

  it('shows a login prompt when the user is not logged in', () => {
    render(<Greeting name="Kushang" isLoggedIn={false} />);

    expect(screen.getByText('Please log in to continue.')).toBeInTheDocument();
  });

  it('does not show the welcome message when logged out', () => {
    render(<Greeting name="Kushang" isLoggedIn={false} />);

    expect(screen.queryByText(/Welcome back/)).not.toBeInTheDocument();
  });
});

Notice the pattern every test follows — Arrange, Act, Assert:

Arrange: render the component
Act: interact with it (if needed)
Assert: check what's visible

Testing a Button Click

// components/Counter.tsx
import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <button onClick={() => setCount(0)}>Reset</button>
    </div>
  );
}

// components/Counter.test.tsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import Counter from './Counter';

describe('Counter', () => {
  it('starts at zero', () => {
    render(<Counter />);
    expect(screen.getByText('Count: 0')).toBeInTheDocument();
  });

  it('increments the count when the button is clicked', async () => {
    const user = userEvent.setup();
    render(<Counter />);

    await user.click(screen.getByRole('button', { name: 'Increment' }));
    expect(screen.getByText('Count: 1')).toBeInTheDocument();

    await user.click(screen.getByRole('button', { name: 'Increment' }));
    expect(screen.getByText('Count: 2')).toBeInTheDocument();
  });

  it('resets the count to zero', async () => {
    const user = userEvent.setup();
    render(<Counter />);

    await user.click(screen.getByRole('button', { name: 'Increment' }));
    await user.click(screen.getByRole('button', { name: 'Increment' }));
    await user.click(screen.getByRole('button', { name: 'Reset' }));

    expect(screen.getByText('Count: 0')).toBeInTheDocument();
  });
});

userEvent simulates real user interactions — clicking, typing, tabbing. It's more realistic than fireEvent and the recommended choice today.

🔗 Integration Testing: Real User Flows

Integration tests are where the real confidence comes from. Instead of testing one component, you test a complete flow — like filling out and submitting a form.

Testing a Login Form

// components/LoginForm.tsx
import { useState } from 'react';

interface Props {
  onSubmit: (email: string, password: string) => void;
}

export default function LoginForm({ onSubmit }: Props) {
  const [email, setEmail]       = useState('');
  const [password, setPassword] = useState('');
  const [error, setError]       = useState('');

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();

    if (!email || !password) {
      setError('Both fields are required.');
      return;
    }

    onSubmit(email, password);
  };

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="email">Email</label>
      <input
        id="email"
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />

      <label htmlFor="password">Password</label>
      <input
        id="password"
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
      />

      {error && <p role="alert">{error}</p>}

      <button type="submit">Log In</button>
    </form>
  );
}

// components/LoginForm.test.tsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import LoginForm from './LoginForm';

describe('LoginForm', () => {
  it('calls onSubmit with email and password when the form is valid', async () => {
    const user      = userEvent.setup();
    const onSubmit  = jest.fn(); // Mock function — tracks calls
    render(<LoginForm onSubmit={onSubmit} />);

    await user.type(screen.getByLabelText('Email'), 'hello@example.com');
    await user.type(screen.getByLabelText('Password'), 'secret123');
    await user.click(screen.getByRole('button', { name: 'Log In' }));

    expect(onSubmit).toHaveBeenCalledWith('hello@example.com', 'secret123');
    expect(onSubmit).toHaveBeenCalledTimes(1);
  });

  it('shows an error message when fields are empty', async () => {
    const user = userEvent.setup();
    render(<LoginForm onSubmit={jest.fn()} />);

    await user.click(screen.getByRole('button', { name: 'Log In' }));

    expect(screen.getByRole('alert')).toHaveTextContent('Both fields are required.');
  });

  it('does not call onSubmit when fields are empty', async () => {
    const user     = userEvent.setup();
    const onSubmit = jest.fn();
    render(<LoginForm onSubmit={onSubmit} />);

    await user.click(screen.getByRole('button', { name: 'Log In' }));

    expect(onSubmit).not.toHaveBeenCalled();
  });
});

These three tests cover the happy path, the validation error, and the guard against bad calls. That's most of what this form can do — and they take under a minute to run.

⏳ Testing Async Behaviour

Most real components talk to an API. Here's how to test those flows without making actual network requests.

Mocking an API Call

// components/UserProfile.tsx
import { useEffect, useState } from 'react';

interface User {
  id: number;
  name: string;
  email: string;
}

export default function UserProfile({ userId }: { userId: number }) {
  const [user, setUser]       = useState<User | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError]     = useState('');

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then((r) => {
        if (!r.ok) throw new Error('Failed to load user.');
        return r.json();
      })
      .then((data) => { setUser(data); setLoading(false); })
      .catch((err) => { setError(err.message); setLoading(false); });
  }, [userId]);

  if (loading) return <p>Loading profile...</p>;
  if (error)   return <p role="alert">{error}</p>;

  return (
    <div>
      <h2>{user?.name}</h2>
      <p>{user?.email}</p>
    </div>
  );
}

// components/UserProfile.test.tsx
import { render, screen, waitFor } from '@testing-library/react';
import UserProfile from './UserProfile';

// Mock the global fetch API
global.fetch = jest.fn();

const mockUser = { id: 1, name: 'Kushang Tailor', email: 'kushang@example.com' };

describe('UserProfile', () => {
  afterEach(() => jest.clearAllMocks()); // Clean up between tests

  it('shows a loading state first', () => {
    (fetch as jest.Mock).mockResolvedValueOnce({
      ok: true,
      json: async () => mockUser,
    });

    render(<UserProfile userId={1} />);
    expect(screen.getByText('Loading profile...')).toBeInTheDocument();
  });

  it('shows the user name and email after loading', async () => {
    (fetch as jest.Mock).mockResolvedValueOnce({
      ok: true,
      json: async () => mockUser,
    });

    render(<UserProfile userId={1} />);

    await waitFor(() => {
      expect(screen.getByText('Kushang Tailor')).toBeInTheDocument();
      expect(screen.getByText('kushang@example.com')).toBeInTheDocument();
    });
  });

  it('shows an error message when the API fails', async () => {
    (fetch as jest.Mock).mockResolvedValueOnce({ ok: false });

    render(<UserProfile userId={1} />);

    await waitFor(() => {
      expect(screen.getByRole('alert')).toHaveTextContent('Failed to load user.');
    });
  });
});

waitFor keeps polling the assertion until it passes (or times out). It's how you deal with async state updates in tests.

🪝 Testing Custom Hooks

Custom hooks need their own tests because they hold logic that multiple components share. Use renderHook from React Testing Library:

// hooks/useCounter.ts
import { useState } from 'react';

export function useCounter(initial = 0) {
  const [count, setCount] = useState(initial);

  return {
    count,
    increment: () => setCount((c) => c + 1),
    decrement: () => setCount((c) => c - 1),
    reset:     () => setCount(initial),
  };
}

// hooks/useCounter.test.ts
import { renderHook, act } from '@testing-library/react';
import { useCounter } from './useCounter';

describe('useCounter', () => {
  it('starts with the initial value', () => {
    const { result } = renderHook(() => useCounter(10));
    expect(result.current.count).toBe(10);
  });

  it('increments the count', () => {
    const { result } = renderHook(() => useCounter());

    act(() => result.current.increment());

    expect(result.current.count).toBe(1);
  });

  it('decrements the count', () => {
    const { result } = renderHook(() => useCounter(5));

    act(() => result.current.decrement());

    expect(result.current.count).toBe(4);
  });

  it('resets to the initial value', () => {
    const { result } = renderHook(() => useCounter(3));

    act(() => result.current.increment());
    act(() => result.current.increment());
    act(() => result.current.reset());

    expect(result.current.count).toBe(3);
  });
});

act wraps anything that causes state updates. It makes sure React processes all the state changes before your assertion runs.

🔥 Debugging: React DevTools Deep Dive

Testing catches bugs before they reach users. Debugging finds the ones that sneak through anyway.

Components Tab

Open DevTools → React tab → Components. Here's what you can do:

Select any component in the tree → see:
├─ Props (current values)
├─ State (useState values)
├─ Hooks (all hook values in order)
└─ Rendered by (parent chain)

You can also edit props and state live in the panel — no code change needed. Incredibly useful for testing edge cases.

Profiler Tab (Performance Debugging)

Already covered in Part 3, but worth repeating the workflow:

1. Open React DevTools → Profiler tab
2. Click ● Record
3. Interact with the slow part of your app
4. Click ■ Stop
5. Look for wide bars (slow renders) and grey bars (unnecessary renders)

Grey bars mean a component re-rendered but produced identical output — a prime candidate for React.memo.

Highlight Updates

In React DevTools settings, enable "Highlight updates when components render". Every re-render flashes a coloured outline on the component. If things are flashing that shouldn't be, you've found your problem.

🚨 Error Boundaries: Catching Crashes in Production

Here's something try/catch cannot do: catch errors thrown during rendering. Error Boundaries handle exactly that — they're React's safety net for when a component tree crashes.

// components/ErrorBoundary.tsx
import { Component, ReactNode } from 'react';

interface Props {
  children: ReactNode;
  fallback?: ReactNode;
}

interface State {
  hasError: boolean;
  error: Error | null;
}

export class ErrorBoundary extends Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = { hasError: false, error: null };
  }

  static getDerivedStateFromError(error: Error): State {
    return { hasError: true, error };
  }

  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // Send to your error tracking service (Sentry, Datadog, etc.)
    console.error('Caught by ErrorBoundary:', error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return (
        this.props.fallback ?? (
          <div className="error-state">
            <h2>Something went wrong.</h2>
            <p>We're looking into it — try refreshing the page.</p>
            <button onClick={() => this.setState({ hasError: false, error: null })}>
              Try Again
            </button>
          </div>
        )
      );
    }

    return this.props.children;
  }
}

Wrap it around sections that could fail independently:

// app/dashboard/page.tsx
import { ErrorBoundary } from '@/components/ErrorBoundary';
import { SalesChart } from '@/components/SalesChart';
import { RecentOrders } from '@/components/RecentOrders';

export default function DashboardPage() {
  return (
    <div className="dashboard">
      {/* If SalesChart crashes, only this section shows an error */}
      <ErrorBoundary fallback={<p>Chart unavailable — try again later.</p>}>
        <SalesChart />
      </ErrorBoundary>

      {/* RecentOrders is unaffected by SalesChart crashing */}
      <ErrorBoundary fallback={<p>Orders unavailable — try again later.</p>}>
        <RecentOrders />
      </ErrorBoundary>
    </div>
  );
}

The result: one section crashing doesn't take down the entire page. Your users see a graceful fallback instead of a blank white screen.

🧪 Common Testing Queries — Which One to Use

React Testing Library gives you several ways to query the DOM. Here's when to use each:

// Priority 1: Accessible roles (best — mirrors what screen readers see)
screen.getByRole('button', { name: 'Submit' })
screen.getByRole('heading', { name: 'Welcome' })
screen.getByRole('textbox', { name: 'Email' })

// Priority 2: Labels (great for form fields)
screen.getByLabelText('Email Address')

// Priority 3: Placeholder (acceptable for inputs)
screen.getByPlaceholderText('Search...')

// Priority 4: Text content (good for readable text)
screen.getByText('Loading...')

// Priority 5: Test IDs (last resort — add data-testid only if nothing else works)
screen.getByTestId('product-card')

The philosophy: if you're querying by class name or component name, you're testing implementation, not behaviour. A CSS refactor will break your tests for no good reason.

📊 What a Healthy Test Suite Looks Like

Here's a realistic coverage target for a production React app:

Type	Target Coverage	Run Time
Utility functions	90–100%	< 1s
Custom hooks	80–90%	< 5s
Components (unit)	70–80%	< 30s
User flows (integration)	Key flows covered	< 2 min
E2E	Login, checkout, critical paths	< 10 min

100% coverage is a myth worth ignoring. A well-tested login flow, cart checkout, and search filter give you far more confidence than 100% coverage on a heading component.

💡 Debugging Checklist (When Things Go Wrong)

Before spending an hour on a bug, run through this:

□ Check the browser console — is there an error message?
□ Check the Network tab — did the API call succeed? What did it return?
□ Add a console.log right before the broken code
□ Open React DevTools → Components → check the props and state
□ Is the component re-rendering when it shouldn't? (Highlight updates)
□ Is it an async timing issue? (Add a debugger statement in the useEffect)
□ Are you mutating state directly? (Should always use setState)
□ Is a dependency array in useEffect missing something?
□ Did a prop change shape or become undefined?
□ Is the issue only in production? (Check .env variables)

Nine times out of ten, the bug is in the console, the network tab, or a missing dependency array.

🔗 Quick Resources

React Testing Library: testing-library.com/react
Jest Docs: jestjs.io
React DevTools: Chrome Web Store → "React Developer Tools"
Vitest (fast alternative to Jest): vitest.dev
Cypress (E2E): cypress.io
Playwright (E2E): playwright.dev

💬 What's Your Testing Philosophy?

Do you write tests before the code (TDD), after, or only when something breaks? No judgement either way — I'm genuinely curious what workflow actually sticks for people in the real world. Drop it in the comments!

Coming in Part 6:

Authentication flows (JWT, session, OAuth)
Real-world deployment patterns
Error monitoring with Sentry
CI/CD with GitHub Actions
Lessons from production React apps at scale

Happy testing! 🧪

Full-Stack with Next.js — From React Dev to Full-Stack Engineer

Kushang Tailor — Wed, 10 Jun 2026 06:29:33 +0000

Read Time: ~15 minutes | The bridge from React UI library to production full-stack framework

Prerequisites: React fundamentals, hooks, state management (Parts 1–3)

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Understand what Next.js adds on top of React (and why it matters)
✅ Navigate the App Router with file-based routing
✅ Know when to use Server Components vs Client Components
✅ Fetch data on the server without a separate backend
✅ Build API routes that replace a Node/Express server
✅ Optimize images and fonts automatically
✅ Build and deploy a real blog platform to Vercel in under 10 minutes

🤔 What Is Next.js (And Why Does It Exist)?

React is a UI library—it renders components beautifully, but it has no opinion about routing, data fetching, server-side rendering, or deployment. You assemble all of that yourself.

Next.js is the full-stack framework built on React that makes those decisions for you. It's like React + routing + data fetching + a server + a build pipeline, all in one cohesive package.

React alone:
UI rendering ✅ | Routing ❌ | Data fetching ❌ | SSR ❌ | API ❌

Next.js (React + framework):
UI rendering ✅ | Routing ✅ | Data fetching ✅ | SSR ✅ | API ✅

Why the Industry Adopted Next.js So Fast

By 2025, Next.js is used by Vercel, Netflix, TikTok, Twitch, Notion, and GitHub among thousands of production applications. The reasons are practical:

SEO out of the box — pages are server-rendered, so search engines see real content
No Express server needed — API routes live inside the same codebase
Automatic optimizations — images, fonts, and scripts are optimized for free
Deployment in seconds — Vercel hosting knows Next.js deeply

⚖️ Next.js vs The Alternatives

Criteria	Create React App	Vite	Next.js	Remix
Routing	Manual (React Router)	Manual	Built-in	Built-in
SSR / SSG	❌	❌	✅	✅
API Routes	❌	❌	✅	✅
SEO	Poor (CSR only)	Poor (CSR only)	Excellent	Excellent
Image Optimization	Manual	Manual	Automatic	Manual
Learning Curve	Low	Low	Medium	Medium
Bundle Splitting	Manual	Auto	Auto	Auto
Best For	Prototypes	SPAs, tools	Full-stack apps	Form-heavy apps
Vercel Deploy	Manual	Manual	One click	One click

The takeaway: Use Next.js whenever your app needs SEO, a backend, or server-side data. Use Vite for internal dashboards or SPAs where SEO doesn't matter.

🚀 Setup & Project Structure

Create a Next.js App

# Create project (accept all defaults)
npx create-next-app@latest my-blog
cd my-blog
npm run dev

You'll be asked a few questions—say Yes to TypeScript (optional), Yes to Tailwind (optional), and Yes to the App Router (essential for 2025).

Project Structure (App Router)

my-blog/
├── app/                    # ← Heart of your app (App Router)
│   ├── layout.tsx          # Root layout (wraps every page)
│   ├── page.tsx            # Home page → renders at /
│   ├── globals.css         # Global styles
│   ├── about/
│   │   └── page.tsx        # About page → renders at /about
│   └── blog/
│       ├── page.tsx        # Blog list → renders at /blog
│       └── [slug]/
│           └── page.tsx    # Single post → renders at /blog/my-post
├── public/                 # Static assets (images, fonts, etc.)
├── components/             # Shared UI components
├── lib/                    # Utility functions, DB connections
├── next.config.js          # Next.js configuration
└── package.json

The magic: file path = URL path. No router config, no <Route> components. Just create a file and the route exists.

📁 File-Based Routing (App Router)

Page Files

Every page.tsx inside app/ becomes a route:

// app/page.tsx → renders at /
export default function HomePage() {
  return <h1>Welcome Home</h1>;
}

// app/about/page.tsx → renders at /about
export default function AboutPage() {
  return <h1>About Us</h1>;
}

// app/blog/page.tsx → renders at /blog
export default function BlogListPage() {
  return <h1>All Posts</h1>;
}

Dynamic Routes (Parameters in URLs)

// app/blog/[slug]/page.tsx → renders at /blog/any-post-title
interface Props {
  params: { slug: string };
}

export default function PostPage({ params }: Props) {
  return <h1>Post: {params.slug}</h1>;
  // /blog/hello-world → params.slug = "hello-world"
  // /blog/my-react-guide → params.slug = "my-react-guide"
}

Layout Files (Shared UI Across Routes)

// app/layout.tsx → wraps EVERY page in your app
export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        <nav>
          <a href="/">Home</a>
          <a href="/blog">Blog</a>
          <a href="/about">About</a>
        </nav>
        <main>{children}</main>
        <footer>© 2025 My Blog</footer>
      </body>
    </html>
  );
}

// app/blog/layout.tsx → wraps only /blog/* routes
export default function BlogLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="blog-container">
      <aside>
        <h3>Categories</h3>
        {/* Sidebar here */}
      </aside>
      <article>{children}</article>
    </div>
  );
}

Why layouts are powerful: Your nav and footer render once and persist across page navigations—no re-mounting, no flicker.

Special Files at a Glance

Filename	Purpose
`page.tsx`	The visible UI for a route
`layout.tsx`	Wrapper shared across child routes
`loading.tsx`	Auto-shown while page data loads
`error.tsx`	Error boundary for a route
`not-found.tsx`	Custom 404 page
`route.ts`	API endpoint (replaces Express route)

⚡ Server Components vs Client Components

This is the concept that trips up most React developers moving to Next.js.

Server Components (Default in App Router)

In Next.js App Router, every component is a Server Component by default. They run on the server, never in the browser.

// app/blog/page.tsx
// ✅ Server Component (no "use client" directive)
// Runs on the server — can access databases, env vars, file system

async function getBlogPosts() {
  const response = await fetch('https://api.example.com/posts', {
    next: { revalidate: 3600 } // Re-fetch every hour
  });
  return response.json();
}

export default async function BlogPage() {
  const posts = await getBlogPosts(); // Direct async/await — no useEffect!

  return (
    <div>
      <h1>Blog Posts</h1>
      {posts.map((post: Post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.excerpt}</p>
          <a href={`/blog/${post.slug}`}>Read more →</a>
        </article>
      ))}
    </div>
  );
}

What Server Components can do:

✅ async/await directly (no useEffect + useState loading dance)
✅ Access databases and file system directly
✅ Use secret env variables safely
✅ Import heavy libraries without bloating the client bundle
❌ No useState, useEffect, event handlers
❌ No browser APIs (window, document)

Client Components (`"use client"` directive)

Add "use client" at the top when you need interactivity:

"use client"; // ← This one line switches to a Client Component

import { useState } from 'react';

export default function SearchBar({ onSearch }: { onSearch: (q: string) => void }) {
  const [query, setQuery] = useState('');

  return (
    <input
      value={query}
      onChange={(e) => {
        setQuery(e.target.value);
        onSearch(e.target.value);
      }}
      placeholder="Search posts..."
    />
  );
}

Client Components are for:

✅ useState, useEffect, custom hooks
✅ Event handlers (onClick, onChange)
✅ Browser APIs
✅ Third-party libraries needing the DOM
❌ Direct database/file system access
❌ Secret environment variables

The Golden Pattern: Server Shell + Client Islands

// app/blog/page.tsx — Server Component (default)
import SearchBar from '@/components/SearchBar'; // Client Component
import PostList from '@/components/PostList';   // Server Component

async function getPosts() {
  // Runs on server — safe to use secrets, DB, etc.
  const posts = await db.posts.findMany();
  return posts;
}

export default async function BlogPage() {
  const posts = await getPosts(); // Direct DB call — no API needed

  return (
    <div>
      {/* Client island — handles user input */}
      <SearchBar onSearch={(q) => console.log(q)} />

      {/* Server component — rendered on server */}
      <PostList posts={posts} />
    </div>
  );
}

Mental model: Server Components are the shell (fast, SEO-friendly, secure). Client Components are interactive islands inside that shell. Use the minimum number of Client Components necessary.

🌐 Data Fetching in Next.js

Three Patterns You'll Use

1. Static Data (SSG) — Build time, cached forever

// app/about/page.tsx
// Data fetched once at build time — ultra fast

export default async function AboutPage() {
  const team = await fetch('https://api.example.com/team').then(r => r.json());
  // This fetch runs ONCE when you build — result is cached as static HTML

  return (
    <div>
      {team.map((member: Member) => (
        <div key={member.id}>{member.name}</div>
      ))}
    </div>
  );
}

2. Revalidated Data (ISR) — Refreshes every N seconds

// app/blog/page.tsx
// Re-fetches every 60 seconds — fresh but still cached

async function getPosts() {
  const res = await fetch('https://api.example.com/posts', {
    next: { revalidate: 60 } // Refresh every 60 seconds
  });
  return res.json();
}

3. Dynamic Data (SSR) — Every request, always fresh

// app/dashboard/page.tsx
// Runs on every request — real-time data

async function getUserData(userId: string) {
  const res = await fetch(`https://api.example.com/users/${userId}`, {
    cache: 'no-store' // Never cache — always fresh
  });
  return res.json();
}

Fetching Strategy Decision

Is data the same for everyone?
├─ Yes, never changes → Static (no revalidate)
├─ Yes, but updates sometimes → ISR (revalidate: N seconds)
└─ No, user-specific or real-time → Dynamic (cache: 'no-store')

🔌 API Routes: Your Backend Lives Here

Next.js route.ts files replace Express, Fastify, or any separate Node server.

Basic CRUD API

// app/api/posts/route.ts → handles GET /api/posts & POST /api/posts
import { NextRequest, NextResponse } from 'next/server';

// In-memory store (use a real DB in production)
const posts = [
  { id: 1, title: 'Hello Next.js', slug: 'hello-nextjs' },
  { id: 2, title: 'Server Components', slug: 'server-components' },
];

// GET /api/posts
export async function GET() {
  return NextResponse.json(posts);
}

// POST /api/posts
export async function POST(request: NextRequest) {
  const body = await request.json();

  if (!body.title) {
    return NextResponse.json(
      { error: 'Title is required' },
      { status: 400 }
    );
  }

  const newPost = {
    id: posts.length + 1,
    title: body.title,
    slug: body.title.toLowerCase().replace(/\s+/g, '-'),
  };

  posts.push(newPost);
  return NextResponse.json(newPost, { status: 201 });
}

Dynamic API Routes

// app/api/posts/[id]/route.ts → handles /api/posts/1, /api/posts/42, etc.
import { NextRequest, NextResponse } from 'next/server';

interface Params {
  params: { id: string };
}

// GET /api/posts/1
export async function GET(_req: NextRequest, { params }: Params) {
  const post = await db.posts.findUnique({
    where: { id: parseInt(params.id) },
  });

  if (!post) {
    return NextResponse.json({ error: 'Post not found' }, { status: 404 });
  }

  return NextResponse.json(post);
}

// PATCH /api/posts/1
export async function PATCH(request: NextRequest, { params }: Params) {
  const body = await request.json();

  const updated = await db.posts.update({
    where: { id: parseInt(params.id) },
    data: { title: body.title },
  });

  return NextResponse.json(updated);
}

// DELETE /api/posts/1
export async function DELETE(_req: NextRequest, { params }: Params) {
  await db.posts.delete({ where: { id: parseInt(params.id) } });
  return NextResponse.json({ success: true });
}

The result: a full REST API, no separate server, no CORS headaches—everything in one codebase.

🖼️ Image & Font Optimization (Free Performance Wins)

The `<Image>` Component

Never use a plain <img> in Next.js—use next/image instead:

import Image from 'next/image';

// ❌ Plain HTML img — unoptimized
<img src="/hero.jpg" alt="Hero" width={1200} height={600} />

// ✅ Next.js Image — automatic WebP, lazy loading, no layout shift
<Image
  src="/hero.jpg"
  alt="Hero"
  width={1200}
  height={600}
  priority     // Load this image eagerly (above the fold)
/>

// ✅ Fill mode for responsive containers
<div style={{ position: 'relative', height: '300px' }}>
  <Image
    src="/cover.jpg"
    alt="Post cover"
    fill
    style={{ objectFit: 'cover' }}
    sizes="(max-width: 768px) 100vw, 50vw"
  />
</div>

What next/image gives you for free:

Converts to WebP/AVIF automatically (30-50% smaller)
Lazy loads by default (only loads when in viewport)
Prevents Cumulative Layout Shift (CLS)
Generates multiple sizes for different screen widths

Font Optimization

// app/layout.tsx
import { Inter, Fira_Code } from 'next/font/google';

// Fonts are downloaded at build time — no runtime network request
const inter = Inter({
  subsets: ['latin'],
  display: 'swap',      // Show fallback font until loaded
  variable: '--font-inter',
});

const firaCode = Fira_Code({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-fira-code',
});

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en" className={`${inter.variable} ${firaCode.variable}`}>
      <body style={{ fontFamily: 'var(--font-inter)' }}>
        {children}
      </body>
    </html>
  );
}

Why this matters: Google Fonts loaded the old way block rendering and cause layout shift. Next.js downloads fonts at build time—zero runtime latency, zero layout shift.

🏗️ Real-World: Building a Blog Platform

Let's put everything together and build a real blog with posts and an API.

Step 1: Project Setup

npx create-next-app@latest nextjs-blog
cd nextjs-blog
npm install gray-matter    # Parse markdown frontmatter
npm install next-mdx-remote # Render MDX content
npm run dev

Step 2: Post Data (Markdown Files)

<!-- posts/hello-nextjs.md -->
---
title: "Hello Next.js"
date: "2025-06-01"
excerpt: "A quick intro to why Next.js changes everything."
author: "Your Name"
---

# Hello Next.js

This is my first post rendered from markdown...

Step 3: Library to Read Posts

// lib/posts.ts
import fs from 'fs';
import path from 'path';
import matter from 'gray-matter';

const postsDir = path.join(process.cwd(), 'posts');

export function getAllPosts() {
  const slugs = fs.readdirSync(postsDir);

  return slugs
    .map((filename) => {
      const slug = filename.replace(/\.md$/, '');
      const fullPath = path.join(postsDir, filename);
      const fileContents = fs.readFileSync(fullPath, 'utf8');
      const { data } = matter(fileContents);

      return {
        slug,
        title: data.title as string,
        date: data.date as string,
        excerpt: data.excerpt as string,
        author: data.author as string,
      };
    })
    .sort((a, b) => (a.date > b.date ? -1 : 1));
}

export function getPostBySlug(slug: string) {
  const fullPath = path.join(postsDir, `${slug}.md`);
  const fileContents = fs.readFileSync(fullPath, 'utf8');
  const { data, content } = matter(fileContents);

  return {
    slug,
    content,
    title: data.title as string,
    date: data.date as string,
    author: data.author as string,
  };
}

Step 4: Blog List Page (Server Component)

// app/blog/page.tsx
import { getAllPosts } from '@/lib/posts';
import Link from 'next/link';

export const metadata = {
  title: 'Blog | My Next.js Blog',
  description: 'Thoughts on React, Next.js, and web development.',
};

export default function BlogPage() {
  // Direct file system access — no API call, no useEffect
  const posts = getAllPosts();

  return (
    <main>
      <h1>Blog</h1>
      <p>{posts.length} posts published</p>

      <div className="post-grid">
        {posts.map((post) => (
          <article key={post.slug}>
            <time>{new Date(post.date).toLocaleDateString()}</time>
            <h2>
              <Link href={`/blog/${post.slug}`}>{post.title}</Link>
            </h2>
            <p>{post.excerpt}</p>
            <span>{post.author}</span>
          </article>
        ))}
      </div>
    </main>
  );
}

Step 5: Single Post Page (Dynamic Route)

// app/blog/[slug]/page.tsx
import { getPostBySlug, getAllPosts } from '@/lib/posts';
import { notFound } from 'next/navigation';

// Pre-generate all post pages at build time
export async function generateStaticParams() {
  const posts = getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

// Generate dynamic metadata per post
export async function generateMetadata({ params }: { params: { slug: string } }) {
  const post = getPostBySlug(params.slug);
  return {
    title: `${post.title} | My Blog`,
    description: post.title,
  };
}

export default function PostPage({ params }: { params: { slug: string } }) {
  const post = getPostBySlug(params.slug);

  if (!post) notFound(); // Shows app/not-found.tsx automatically

  return (
    <article>
      <header>
        <h1>{post.title}</h1>
        <time>{new Date(post.date).toLocaleDateString()}</time>
        <span>By {post.author}</span>
      </header>

      {/* Render markdown as HTML */}
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

Step 6: API Route for Posts

// app/api/posts/route.ts
import { getAllPosts } from '@/lib/posts';
import { NextResponse } from 'next/server';

// GET /api/posts — returns all posts as JSON
export async function GET() {
  const posts = getAllPosts();
  return NextResponse.json(posts);
}

Step 7: Loading & Error States

// app/blog/loading.tsx — Shows while blog page loads
export default function BlogLoading() {
  return (
    <div>
      {[1, 2, 3].map((i) => (
        <div key={i} className="post-skeleton">
          <div className="skeleton-title" />
          <div className="skeleton-text" />
        </div>
      ))}
    </div>
  );
}

// app/blog/error.tsx — Shows if blog page throws
'use client';

export default function BlogError({ error, reset }: {
  error: Error;
  reset: () => void;
}) {
  return (
    <div>
      <h2>Something went wrong loading the blog</h2>
      <p>{error.message}</p>
      <button onClick={reset}>Try again</button>
    </div>
  );
}

🚀 Deploying to Vercel in Under 10 Minutes

Vercel is the company behind Next.js. Their platform knows Next.js deeply—deployment is as simple as pushing code.

Step 1: Push to GitHub

git init
git add .
git commit -m "Initial blog setup"
git branch -M main
git remote add origin https://github.com/yourusername/my-blog.git
git push -u origin main

Step 2: Connect to Vercel

Go to vercel.com and sign up with GitHub
Click "New Project" → Import your repo
Vercel detects Next.js automatically—click Deploy That's it. Your app is live.

What Vercel Provides Automatically

✅ HTTPS certificate (SSL)
✅ Global CDN (fast worldwide)
✅ Automatic deploys on every git push
✅ Preview URLs for every pull request
✅ Environment variable management
✅ Edge Network for API routes
✅ Analytics dashboard
✅ Serverless functions (your API routes)

Environment Variables

# .env.local (never commit this file)
DATABASE_URL=postgresql://user:pass@host/db
NEXT_PUBLIC_API_URL=https://api.example.com  # NEXT_PUBLIC_ = visible in browser
SECRET_API_KEY=abc123  # No prefix = server-only (secure)

// Accessing env vars
const dbUrl = process.env.DATABASE_URL;           // Server only ✅
const apiUrl = process.env.NEXT_PUBLIC_API_URL;   // Both client + server ✅

Add the same variables in Vercel's dashboard under Project → Settings → Environment Variables.

📊 Performance Wins You Get for Free

When you deploy to Vercel with Next.js:

Optimization	Technique	Gain
Static pages	Pre-rendered HTML	Near-instant load
Dynamic pages	Edge SSR	<100ms TTFB globally
Images	WebP + lazy load	30-50% smaller
Fonts	Build-time download	0ms font latency
JavaScript	Auto code-splitting	Smallest possible bundles
API Routes	Serverless functions	Scales to zero, instant cold start

💡 Final Thoughts: Next.js as a Career Investment

The jump from React developer to Next.js full-stack engineer is one of the highest-ROI moves you can make in 2025.

What changes:

You go from "I build UIs" to "I build and ship entire applications"
You stop needing a separate backend team for simple APIs
Your apps get SEO, performance, and scalability built in The learning order that makes sense:

React Fundamentals (Part 1)
        ↓
Advanced Hooks & State (Part 2)
        ↓
Performance Optimization (Part 3)
        ↓
Next.js Full-Stack ← YOU ARE HERE
        ↓
Testing (Part 5)
        ↓
Production-Grade React (Part 6)

You're not adding a new tool—you're graduating to a platform.

🔗 Quick Resources

Next.js Docs: nextjs.org/docs — The best framework docs in the ecosystem
Next.js Learn: nextjs.org/learn — Official interactive tutorial
Vercel: vercel.com — Deploy Next.js in one click
Prisma: prisma.io — Best ORM for Next.js + database
shadcn/ui: ui.shadcn.com — Component library built for Next.js

💬 What's Your Next.js Story?

Have you made the jump from React to Next.js? Are you still on the fence? What's holding you back? Drop your experience in the comments—especially if you've hit any gotchas with Server Components. That's usually where people get stuck first!

Covered in Part 5:

Unit testing with Jest & React Testing Library
Testing Server Components and API routes
Debugging with React DevTools and browser tools
Error boundaries in production
CI/CD pipeline basics

Happy shipping! 🚀